On 29 July 2026, CISA published version 2.1 of the Minimum Elements for a Software Bill of Materials. It updates and replaces the document the National Telecommunications and Information Administration published in July 2021, which has been the de facto reference for what an SBOM has to contain.
The co-author list is the reason EU manufacturers should read it. Alongside NSA and FBI sit seventeen partner agencies, seven of them EU national cybersecurity authorities: ANSSI, BSI, ACN, NASK, NBU, NCSC-NL and NÚKIB. DG CONNECT contributed. The document cites Regulation (EU) 2024/2847 directly, and it cites BSI TR-03183-2 as related guidance.
Before going further, the necessary caveat, and it is the Commission's own. Not all elements of this document reflect Union law. It is not EU law, it imposes nothing on an EU manufacturer, and by its own terms it "does not create new requirements". What it does is reset what a customer, a procurement team or a national authority is likely to ask for.
The headline delta
Seven data fields became seventeen. Ten are new, four are major updates, and the practices layer was reorganised.
The 2021 set was: Supplier Name, Component Name, Version of the Component, Other Unique Identifiers, Dependency Relationship, Author of SBOM Data, and Timestamp.
The 2026 set splits into SBOM metadata and component data.
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 Producer, Component Dependency Relationship, Component Hash Value, Component Hash Algorithm, Component Identifiers, Component License, Component Name, Component Version.
Six elements sit under practices and processes: Accommodation of Updates to SBOM Data, Coverage, Distribution and Delivery, Explicitly Identifying Unknown Information, Frequency, and Machine-Processable Data.
The four changes that actually bite
Supplier Name became Component Producer. The old term proved ambiguous in practice, particularly around distributors. A distributor is not the entity that created the component, and conflating the two broke the field's purpose as a contact point for security concerns. Only one organisation should be named per component. Where provenance genuinely cannot be established, the SBOM author is now expected to say so explicitly rather than leave the field empty.
Depth became Coverage, and the floor was removed. This is the big one. The 2021 Depth element required only top-level dependencies, a limit that reflected what tooling could do in 2021 rather than what security decisions need. Coverage requires information for all components that make up the target software, including transitive dependencies, and states plainly that there is no minimum depth.
The document explains why in terms of the use case. From a vulnerability management perspective, a recipient should be able to conclude that a newly reported vulnerability does not affect them because the component is absent from the SBOM. That inference only holds if the SBOM is complete. A top-level-only SBOM cannot support it.
Known Unknowns became Explicitly Identifying Unknown Information. The author must now distinguish between data they do not have and data they are choosing to withhold, and must have a process for recipients to ask about redacted security-relevant information. Organisations may treat an SBOM as incomplete where essential component data is withheld.
SWID tags were dropped. The accepted formats are SPDX and CycloneDX, described as the two widely used by the ecosystem. Deprecated versions of either should not be used for new software.
Two smaller changes are worth noting. Access Control was removed as a standalone element and folded into Distribution and Delivery. Automation Support became Machine-Processable Data and moved into the practices layer.
The scope also widened. The minimum elements now explicitly cover open source, AI software and SaaS, with a note that AI and cloud software may warrant additional elements beyond the minimum.
Where this collides with the CRA
Here is the part that matters for an EU manufacturer, and it is not obvious from either document alone.
CRA Annex I Part II(1) requires the manufacturer to identify and document the components contained in the product, "including by drawing up a software bill of materials in a commonly used machine-readable format covering at the very least the top-level dependencies of the product".
At the very least the top-level dependencies. That is the CRA floor, and it is exactly the definition that CISA has just abandoned as inadequate.
So an SBOM that satisfies CRA Annex I Part II(1) at its minimum fails the 2026 Coverage element by construction. Not by oversight, not through poor tooling, but because the two documents draw the line in different places. A manufacturer who builds to the CRA minimum and then hands that file to a customer citing the 2026 elements will be told it is incomplete, and the customer will be right by their own reference.
This is not a conflict a manufacturer has to resolve today. The CRA is the binding instrument and its floor is the one enforceable in the EU. But the direction of travel is unmistakable, seven EU national authorities signed the document that says top-level-only is not enough, and procurement language tends to follow the more demanding reference rather than the legal minimum.
And where it collides with BSI TR-03183-2
There is a second divergence, running the opposite way.
BSI TR-03183-2 sets format-version floors. CycloneDX 1.6 or SPDX 3.0.1, as a minimum, in section 4. The 2026 minimum elements set no version floor at all. They accept SPDX and CycloneDX as formats and say only that deprecated versions should be avoided.
The consequence is concrete. A CycloneDX 1.5 document can satisfy the CISA 2026 format expectation and fail the BSI minimum on version alone. Conversely, a document with a rich two-level dependency graph in CycloneDX 1.6 can clear BSI's version bar while still falling short on fields BSI never asked for, such as the SBOM author signature or the generation context.
There is no single SBOM verdict. There are framework-specific verdicts, and they disagree. Any tool that blends them into one score is hiding the information you actually need.
That is why our SBOM validator reports against each framework separately rather than producing a combined number. Paste a document and you see where each one lands, including the cases where the two disagree about the same file.
What to do with this
If you are an EU manufacturer, nothing in this document changes your legal obligation. Annex I Part II(1) is what you must meet, and the technical file is where you evidence it.
Three things are worth doing anyway.
Check whether your SBOM generation actually captures transitive dependencies or stops at the top level. Many pipelines stop, because the 2021 baseline said that was sufficient. If yours does, you now know what a customer citing the 2026 elements will say about it.
Check whether your component records carry licences and hashes. Both are new required fields, both are usually available at build time, and both are cheap to start emitting now compared with backfilling later.
Check what your tooling puts in the author field. The 2026 elements separate the SBOM Author from the SBOM Tool Name deliberately, because a tool is not an accountable entity. If your generator writes only its own name, no one can tell who stands behind the data.
The full document is published on the CISA website.