This week, CISA (the U.S. federal government’s Cybersecurity and Infrastructure Security Agency) released the 2026 Minimum Elements for a Software Bill of Materials (SBOM). The publication was a collaboration with the NSA, the FBI, and 15 international cybersecurity agencies.
The 2026 SBOM minimum elements guidance was the first comprehensive revision to the federal SBOM baseline since its initial publication in 2021. And, as you might expect given the maturation of SBOM initiatives across the globe, it materially raises the bar for what a "complete" SBOM contains.
In this blog, we’ll break down the biggest changes (and there are many) from the original NTIA minimums, including 10 new required elements and a number of updates to existing ones.
A Quick History of the NTIA Minimum Elements
When NTIA published The Minimum Elements for a Software Bill of Materials in July 2021, it did so in response to a provision in U.S. government Executive Order (14028); the provision required federal agencies to define what a usable SBOM actually needed to contain. The result was a publication that outlined seven required data fields (supplier name, component name, version, other unique identifiers, dependency relationship, author, and timestamp), automation guidelines, and a handful of practices around depth, frequency, and delivery.
That document turned out to be enormously influential. It became the reference point for OMB attestation memos, for FDA medical device guidance, for SBOM tooling, and for SBOM compliance requirements around the world.
Of course, five years is an eternity in software development, so the time was right for a significant update. CISA published a draft revision of its updated minimum elements for public comment in August 2025, and the 2026 guidance is the finalized result.
Some of the biggest changes include:
- The required data set roughly doubled, and the data fields are now split into two clear categories: SBOM Metadata (data about the SBOM document itself) and Component Data (data about the software).
- There are 10 net-new elements
- Existing elements were updated and clarified
The New Required Data Fields
The 2026 guidance introduces 10 new required data fields on top of the elements carried over from 2021. Here is the full list, grouped into the aforementioned “SBOM Metadata” and “Component Data” categories.
New SBOM Metadata Elements
- SBOM Author Signature: a digital signature attributable to the SBOM author.
- SBOM Data Format Name: the name of the data format used to represent the SBOM (e.g., SPDX, CycloneDX).
- SBOM Data Format Version: the version of that data format.
- SBOM Generation Context: the software lifecycle phase and data available when the SBOM was generated.
- SBOM Tool Name: the name of the tool used to generate or amend the SBOM.
- SBOM Tool Version: the version of that tool.
- SBOM Version: an identifier marking a change from a previous version of the SBOM (or that it's the first).
We’ll briefly explore some of the particularly notable additions below; for complete definitions and context, we recommend viewing CISA’s entire publication.
SBOM Author Signature
SBOMs are now required to include a digital signature attributable to the SBOM author, giving recipients assurance that the SBOM came from who it claims to and hasn't been altered in transit. The guidance points to approved signature standards (NIST DSS, ISO/IEC 14888-4:2024, ENISA's Agreed Cryptographic Mechanisms) and tells implementers to lean on existing software-signing infrastructure and key management.
SBOM Generation Context
Generation Context records where in the build lifecycle the SBOM was produced; this piece of information tells the SBOM consumer a great deal about completeness:
- Before build (source): generated from repository and manifest data. Good for intent, but may miss what actually ships.
- Build: generated as the releasable artifact is assembled. Generally the highest-fidelity option.
- After build (binary analysis): reverse-engineered from the finished binary. Useful when you don't control the build, but subject to the limits of static analysis.
New Component Data Elements
- Component Hash Value: the output of applying a cryptographic hash algorithm to an executable component artifact.
- Component Hash Algorithm: the algorithm used to compute that hash value.
- Component License: the identifier(s) for the license(s) under which the component is available.
The addition of License as a required element brings to mind the early days of the SBOM movement, where open source license compliance was a vital use case. License is now required, and it belongs in a machine-processable form wherever possible, ideally as SPDX license identifiers. Proprietary conditions should be flagged, and a URL fallback where no identifier exists should be provided.
Updates and Clarifications to Existing Elements
Beyond the new fields, the 2026 guidance revises elements carried over from 2021. The document flags eight major updates. We’ll explore each major update below, again, grouped by category.
SBOM Metadata
1. SBOM Author
The previously named “Author of SBOM Data” field is now the “SBOM Author” field. The element captures the entity producing the SBOM, rather than the name of a tool used to create the SBOM. It’s also distinct from the “Component Producer” field.
Component Data Elements
1. Component Producer
The previously named "Supplier Name" field is now the “Component Producer” field. This change was made in response to confusion over whether the data field referred to the component distributor or original producer. The change to “Component Producer” clears up this ambiguity. Additionally, if there's no clear producer, the SBOM author must explicitly mark the component as being of unknown provenance.
2. Component Version
The previously named “Version of the Component” field is now the “Component Version” field. In addition to the name change, CISA clarified how SBOM authors should handle scenarios where the component producer doesn’t specify the version. In this scenario where the producer doesn't supply a version, the SBOM author should mark it unknown.
3. Component Identifiers
The previously named “Other Unique Identifiers” field is now the “Component Identifiers” field. Identifiers like PURL and CPE (essentially standardized naming conventions for specific versions of specific software components) play a vital role in enabling SBOM-related automation. SBOM tools rely on identifiers to perform a number of important tasks, including vulnerability enrichment. Aside from the field’s name change, the 2026 minimum elements update requires at least one machine-processable identifier per component.
Practices and Processes
1. Coverage
Although the 2021 minimum elements publication did recommend that SBOMs include all direct and transitive dependencies, it only required the inclusion of “top-level” dependencies with “enough detail to seek out the transitive dependencies recursively.” The 2026 version has a significant change in this regard. It states: “An SBOM should include information for all components that make up the target software, including transitive dependencies. There is no minimum depth.”
The idea is that if a vulnerable component isn't listed, a consumer should be able to safely conclude they aren't affected; this is only possible if coverage is comprehensive. Notably, the guidance allows for the linking of SBOMs for subcomponents, as long as the recipient can access all the linked documents.
2. Explicitly Identifying Unknown Information
The initial version of the minimum elements included the obligation to communicate “Known Unknowns” (as it related to cases where the full dependency graph is not enumerated) in the SBOM. The 2026 version clarifies the requirement and creates a distinction between two different situations: information that is genuinely unknown to the author versus information that is known but deliberately withheld (such as for security reasons). SBOM authors must have a process for recipients to ask about redacted data, and organizations may treat an SBOM as incomplete if essential component data is withheld.
3. Accommodation of Updates to SBOM Data
In 2021, the guidance on this topic (labeled “Accomodation of Mistakes”) had an explicit acknowledgement for errors. This made sense given challenges related to tooling and data quality. In 2026, the expectation is SBOM data is presumed accurate, and changes are mostly about keeping information current rather than fixing errors.
4. Machine-Processable Data
Notably (and appropriately), CISA no longer mentions SWID tags as an SBOM format, leaving only SPDX and CycloneDX. (Both now also ratified as Ecma standards, ECMA-424 and adjacent). SBOM consumers should “accept any widely used, interoperable, and machine-processable SBOM format” (which, in practice, means CycloneDX or SPDX), but avoid deprecated ones.
Minor Updates
Several elements got smaller clarifications rather than overhauls:
- SBOM Timestamp: must now adhere to RFC 9557 for interoperability.
- Component Name: now allows multiple entries to capture alternate names.
- Component Dependency Relationship: clarified to mean one component necessary for the operation of another
- Distribution and Delivery: simplified and clarified.
- Frequency: rewritten with current terminology; intent unchanged (a new SBOM per build or release).
One structural change rounds it out: the standalone Access Control element was removed, with those considerations moved into Distribution and Delivery.
The Impact of CISA’s 2026 SBOM Minimum Elements
The 2026 Minimum Elements represent a clear vision that SBOMs graduate from checking a box to serving as a real security and risk management tool. This is evident in the themes we see across new required elements and updates to existing elements: SBOM data is expected to be more specific, authenticated, machine-processable, and trustworthy.
It’s certainly true that open questions remain following the document’s publication, such as the trickle-down effect on the FDA’s SBOM requirements and other global SBOM requirements. However, regardless of your use case, our view is that SBOM producers should start talking about the additional tools and capabilities they’ll need to meet the elevated standards set out in CISA’s publication.
In the coming weeks, FOSSA will have deeper analysis on the new minimum elements and their downstream impact. For now, feel free to reach out to our team if you’d like additional perspectives on the document, or if you’d like to demo our SBOM management solution.