SBOM Minimum Elements: What Changed in CISA 2026

On July 29, 2026, CISA and 17 partner agencies published the 2026 Minimum Elements for a Software Bill of Materials, version 2.1. It does not sit alongside the 2021 NTIA baseline. In CISA's own words, it updates and replaces it. The minimum set of data fields goes from seven to seventeen, and the practices that surround them are rewritten.

This post maps every element of the 2021 original to what the 2026 document does with it, using CISA's Appendix B as the source rather than a summary of a summary.

The short version

• Seventeen data fields, up from seven. Ten of them are entirely new.
• This is not a US only document. It is co-sealed by CISA and 17 partner agencies across 14 countries, including BSI in Germany, ANSSI in France, ACN in Italy, METI and the NCO in Japan, KISA and the NIS/NCSC in Korea, CERT-In in India, and national cyber centres in Canada, Australia, New Zealand, the Netherlands, Czechia, Poland, and Slovakia.
• Hash, license, tool identity, and generation context are now required, not recommended.
• Access Control is gone as a standalone element, absorbed into Distribution and Delivery.
• SWID tags are dropped from the named data formats. SPDX and CycloneDX are the two that remain.
• Coverage replaces Depth, and the document states there is no minimum depth.

How we got here

The version history in the document itself is the clearest way to see the arc:

• 1.0, July 12, 2021. The NTIA minimum elements. Seven data fields and a set of practices, the first real consensus on what an SBOM must contain.
• 2.0, August 22, 2025. A draft published for public comment. Widely read, never final.
• 2.1, July 29, 2026. The final version, revised in response to comments on the 2025 draft.

If you built anything against the 2025 draft, check the names. Several of them moved between the draft and the final. What the draft called Software Producer is Component Producer in the final. What it called Software Identifiers is Component Identifiers. A single hash element became two, Component Hash Algorithm and Component Hash Value. Most elements picked up an explicit SBOM or Component prefix so it is always obvious whether a field describes the document or the software.

Sitting between the two is the CISA Framing Document, Third Edition of September 3, 2024, which introduced the idea of minimum, recommended, and aspirational maturity levels. Much of what it called recommended is what the 2026 document now calls required.

The seventeen fields

The 2026 document splits the data fields into two groups. SBOM Metadata describes the document, and Component Data describes the software.

SBOM Metadata, nine fields: SBOM Author, SBOM Author Signature, SBOM Data Format Name, SBOM Data Format Version, SBOM Generation Context, SBOM Timestamp, SBOM Tool Name, SBOM Tool Version, SBOM Version.

Component Data, eight fields: Component Dependency Relationship, Component Hash Algorithm, Component Hash Value, Component Identifiers, Component License, Component Name, Component Producer, Component Version.

The ten new elements

Seven of the ten describe the SBOM document itself. That is the real theme of this update: the 2026 elements care about who made this SBOM, with what, when in the build, and can you prove it was not tampered with, not just what is inside the software.

• SBOM Author Signature. A digital signature attributable to the SBOM author, giving recipients assurance about the integrity and authenticity of the data.
• SBOM Data Format Name. The name of the data format used to represent the SBOM data, declared inside the data itself.
• SBOM Data Format Version. The version of that data format, so tools know what they are reading.
• SBOM Generation Context. The lifecycle phase at which the SBOM was generated, because the data available pre-build, at build, and post-build is not the same.
• SBOM Tool Name. The tool the SBOM author used to generate or amend the SBOM.
• SBOM Tool Version. The version of that tool.
• SBOM Version. A version identifier for the SBOM document itself, since one component can have several SBOMs that improve over time.
• Component Hash Algorithm. The cryptographic algorithm used to produce the hash.
• Component Hash Value. The hash output for an executable component artifact.
• Component License. The identifiers for the licenses the component is available under.

The practices matter as much as the fields

The document is explicit that how an organization engages with SBOM data is as important as the data. Six practices carry requirements worth reading closely:

• Coverage. An SBOM should include all components that make up the target software, including transitive dependencies, with no minimum depth. Where a component appears multiple times with different metadata, each instance is listed separately. The test CISA gives is a good one: a recipient should be able to conclude that a newly reported vulnerability does not affect them because the SBOM does not list the component.
• Machine-Processable Data. SPDX and CycloneDX are named as the two widely used formats. Organizations should accept any widely used, interoperable, machine-processable format, but should not accept new SBOMs generated in deprecated versions of a format.
• Explicitly Identifying Unknown Information. A blank field is not acceptable. The author states whether the information is unknown to them or deliberately withheld, and must provide a route for recipients to ask about redacted security related information.
• Frequency. Every software version or update gets an SBOM, including builds that only integrate updated dependencies. New facts about existing components mean a revised SBOM.
• Accommodation of Updates to SBOM Data. Authors correct errors promptly, and organizations may factor a supplier's error rate into risk management decisions.
• Distribution and Delivery. SBOMs should be available promptly to those who need them. Access controls may restrict unauthorized parties but should not stop authorized parties from sharing, or stop an organization from feeding SBOM data into its security tooling.

Why this one travels further than 2021

The 2021 minimum elements were a US document that the rest of the world referenced. The 2026 version is co-sealed by agencies in 14 countries, and it points directly at the regulation and guidance already in force in those markets. The document itself cites the EU Cyber Resilience Act, which requires manufacturers of products with digital elements to provide an SBOM as part of their technical documentation, alongside BSI TR-03183-2 in Germany, METI's SBOM guidance in Japan, and CERT-In's bill of materials guidelines in India.

For a vendor selling into more than one region, that convergence is the practical headline. One well formed SBOM, carrying the same seventeen fields, now answers to a much larger share of the regimes you are likely to face. We track those regimes and what each one asks for in the Cybeats regulation index.

What to do about it

• Audit your generated SBOMs against the seventeen fields. Most generators emit component name, version, and identifiers well. Hashes, licenses, generation context, and tool identity are where gaps usually appear.
• Check your identifiers. At least one common software identifier per component is the expectation, and accurate purls are what make later vulnerability correlation work at all.
• Decide who signs. SBOM Author Signature is new and it needs an owner, a key, and a process before it needs a tool.
• Stop treating an SBOM as a one time artifact. Frequency and Accommodation of Updates both assume SBOMs get reissued. A file sitting in a repository from last year's release does not meet either.

That last point is where most programs actually struggle. Generating an SBOM is largely solved. Keeping a growing set of them accurate, enriched, versioned, and continuously checked against new vulnerabilities is the work. That is what SBOM Studio is built for.

References

• 2026 Minimum Elements for a Software Bill of Materials (SBOM), v2.1, CISA and 17 partner agencies, July 29, 2026. Current.
• Framing Software Component Transparency, Third Edition, CISA, September 3, 2024.
• The Minimum Elements For a Software Bill of Materials, NTIA, July 12, 2021. Superseded by the 2026 document.
• 2025 CISA Draft Minimum Elements, August 22, 2025. Superseded by the final 2026 version.