The Cybersecurity and Infrastructure Security Agency has issued a new baseline for software bills of materials, replacing the 2021 minimum-elements framework developed by the National Telecommunications and Information Administration. Published jointly with the National Security Agency, the Federal Bureau of Investigation and international cyber agencies, the 2026 guidance is intended to make SBOMs more useful for automated vulnerability management, procurement reviews and software supply-chain risk analysis. CISA said the final document incorporates more than 90 comments submitted during the public consultation on a 2025 draft.

The update arrives after five years of rapid growth in SBOM generation and consumption. In 2021, the policy objective was to establish a workable foundation: identify a software component, record its version and supplier, describe its dependency relationships and make the inventory available in a machine-readable form. The 2026 framework assumes a more mature market in which software-composition-analysis tools, artifact scanners, package identifiers and security-advisory formats can support richer and more automated workflows. The practical effect is a higher data-quality threshold for software producers and a more specific checklist for enterprise buyers.

CISA added 10 minimum data elements: SBOM Author Signature, SBOM Data Format Name, SBOM Data Format Version, SBOM Generation Context, SBOM Tool Name, SBOM Tool Version, SBOM Version, Component Hash Value, Component Hash Algorithm and Component License. Together, the additions provide more information about who created an SBOM, how it was generated, which technical format and tool were used, whether the document has changed, and how a recipient can validate or identify the underlying software artifact.

The component-hash requirements are among the most consequential changes for engineering and security teams. A hash value can link an SBOM record to a specific executable artifact, while the accompanying algorithm field explains how that value was produced. CISA says the algorithm should use a recognized textual name and should be approved by a relevant authority, such as the National Institute of Standards and Technology. When an SBOM author lacks access to the executable artifact, the value should be marked as unknown rather than omitted or inferred. That explicit treatment of unavailable information is designed to reduce ambiguity during automated analysis.

The new license field broadens the baseline beyond vulnerability management. SBOM authors are expected to identify the license or licenses under which each component is available, preferably using machine-processable identifiers such as those maintained through the SPDX license list. Proprietary terms should also be indicated, and unknown license information should be stated as unknown. For software companies, the field creates a closer link between security inventories and open-source governance, copyright compliance, support eligibility and acquisition due diligence.

The requirement to identify unknown information is significant because incomplete SBOM records have often been difficult to distinguish from generation errors. Under the revised approach, a missing value should not silently disappear from the document when the author cannot determine it. An explicit unknown marker enables automated systems to flag the information gap, apply a risk policy or request clarification from the supplier. It also gives software buyers a clearer basis for comparing the completeness of inventories generated by different vendors or scanning tools.

Several new metadata fields focus on reproducibility and accountability. The SBOM Tool Name and Tool Version fields identify the product and release used to generate or amend the inventory. Generation Context records the lifecycle stage and information available when the SBOM was produced, allowing a recipient to distinguish, for example, an inventory generated from source code before a build from one created through binary analysis after compilation. SBOM Version provides a separate identifier for changes to the document itself, rather than changes to the software component, while the timestamp records the most recent update.

The author-signature element introduces a minimum integrity signal. A digital signature attributable to the SBOM author can help a recipient determine that the claimed signatory signed the record and that the data was not altered after the signature was produced. CISA is careful not to equate a valid signature with a complete or accurate inventory. The document says broader validation of coverage, correctness and completeness requires process-based assurance measures beyond the minimum elements. Even so, the signature field gives procurement and security platforms a standardized point at which to verify provenance.

The revised baseline also changes the terminology and scope of several existing elements. “Author of SBOM Data” becomes “SBOM Author,” “Supplier Name” becomes “Component Producer,” and “Version of the Component” becomes “Component Version.” The distinctions are operationally important. The author is the entity that generated the inventory; the producer is the organization that created or developed the component. Those may be the same company, but they can differ when a customer, integrator, distributor or security provider generates an SBOM for software produced elsewhere.

Component identifiers now carry a stronger automation expectation. CISA says an SBOM should contain at least one software identifier and should include all available identifiers when multiple schemes apply. The guidance points to Common Platform Enumeration and Package URL as commonly used identifiers, while also allowing universally unique identifiers, commit hashes and intrinsic schemes such as OmniBOR and Software Hash Identifier. More consistent identifiers can improve matching between SBOM records, vulnerability databases, package repositories and internal asset inventories, reducing the manual reconciliation that has limited the operational value of some early SBOM programs.

The earlier “Depth” concept has been replaced with “Coverage,” reflecting a wider view of what an inventory should include. Rather than focusing mainly on how far down a dependency chain an SBOM goes, coverage addresses both vertical depth and horizontal breadth across components. The guidance permits organizations to enumerate subcomponents in one large SBOM or link to separate SBOMs for individual dependencies. In either case, recipients need enough visibility to understand the relevant component graph and apply risk-management decisions to the software they operate.

CISA also replaced the 2021 “Automation Support” element with a broader “Machine-Processable Data” practice. The agency identifies SPDX and CycloneDX as the two formats currently used widely across the software ecosystem and says organizations should accept widely used, interoperable and machine-processable formats. Software Identification tags, or SWID tags, were removed from the listed SBOM formats because they have not achieved comparable use as an SBOM exchange format. The guidance also warns buyers against accepting newly generated inventories in deprecated versions of otherwise supported formats.

The document does not require every minimum element to correspond to a separate field in a particular technical specification. A single implemented field may satisfy more than one element, while SPDX, CycloneDX and other formats may use terminology that differs from CISA’s labels. That flexibility is intended to preserve interoperability rather than create another competing data format. It also places responsibility on tool providers to demonstrate how their outputs map to the federal baseline and whether the selected format version can express each required element without relying on unstructured notes.

For product teams, the frequency requirements reinforce the idea that an SBOM is a maintained operational record rather than a one-time compliance attachment. Each software version or update should have an associated SBOM. A new build or release that changes components or dependencies should trigger a new inventory, while newly discovered component information or corrections should lead to a revised SBOM. That expectation will put additional emphasis on integrating SBOM generation into continuous-integration and release pipelines instead of relying on periodic manual exports.

The update removes “Access Control” as a stand-alone minimum element and incorporates relevant access considerations into distribution and delivery practices. CISA says advances in SBOM sharing since 2021 made a separate access-control category unnecessary. The framework still recognizes that SBOMs may contain sensitive security or proprietary information and allows redaction in some circumstances, but it cautions that recipients may treat an inventory as incomplete if essential component data is withheld. Authors should also maintain a process for answering questions about security-related redactions.

The guidance applies to all software, explicitly including open-source software, artificial-intelligence software and software delivered as a service. That broad scope gives vendors and customers a common starting point, but it does not resolve every transparency problem in modern cloud and AI systems. SaaS products can change continuously, and responsibility may be divided between the developer and the operator. AI systems may also rely on models, datasets, training pipelines and model cards that are not fully represented by conventional software-component fields.

CISA therefore identifies cloud software, AI software, SBOM validation and correlation with security advisories as areas for further work. For AI, the agency points to separate guidance published with Group of Seven partners in May 2026 rather than adding AI-specific fields to the general baseline. For cloud services, it discusses the potential value of automated snapshots and other mechanisms that can convey changing software composition without imposing an impractical document burden on providers and customers.

Correlation with security advisories is central to the commercial value of the new baseline. SBOM data becomes more actionable when it can be matched with vulnerability and exploitability information through mechanisms such as the Vulnerability Exploitability eXchange and the Common Security Advisory Framework. A customer receiving an alert about a newly disclosed flaw can use component identifiers, versions, hashes and dependency relationships to determine whether affected code is present, while VEX information can indicate whether the vulnerable component is actually exploitable in a specific product configuration.

For software vendors, the immediate task is to compare current SBOM outputs with the 2026 field set and review whether build systems can reliably populate the added metadata. Tooling suppliers will face demand for stronger support for signatures, hashes, license identifiers, document versioning and lifecycle context. Enterprise procurement teams, meanwhile, can update contract language and intake controls to request the revised minimum elements, while allowing suppliers a transition period where legacy generation pipelines cannot yet produce every field.

The higher baseline could also intensify competition among software-composition-analysis, application-security and third-party-risk platforms. Customers will increasingly expect tools not merely to generate a component list, but to normalize identifiers, validate signatures, identify unsupported algorithms, track inventory versions and connect SBOM data with vulnerability and licensing systems. Vendors that cannot preserve the added metadata as inventories move between development pipelines, repositories and risk platforms may struggle to support the end-to-end automation that CISA is seeking.

The framework is voluntary guidance and does not itself create new legal or regulatory obligations. CISA says the minimum elements refine how organizations should generate and request SBOMs, while precise encoding, storage and data-management practices remain outside the document’s scope. Its influence is nevertheless likely to extend through government purchasing, critical-infrastructure procurement, customer security questionnaires and vendor-risk programs, where CISA baselines are frequently incorporated into contractual expectations or control frameworks.

The international authorship also matters for technology companies that sell across multiple jurisdictions. The document includes U.S. agencies and cyber authorities from Australia, Canada, the Czech Republic, France, Germany, India, Italy, Japan, South Korea, the Netherlands, New Zealand, Poland and Slovakia. The shared baseline does not replace local rules, including the European Union’s Cyber Resilience Act, but it may reduce fragmentation by giving software producers a common core of fields that can be mapped into regional requirements and industry-specific profiles.

The 2026 update ultimately shifts the SBOM conversation from basic inventory creation toward operational trust and usability. A list of component names and versions remains necessary, but CISA is now asking for enough context to identify the artifact, understand the generating process, track changes, evaluate licensing and verify who issued the record. Organizations that treat those fields as part of the release and security lifecycle, rather than as static paperwork, will be better positioned to use SBOMs for faster vulnerability response, more informed procurement and more scalable software supply-chain oversight.