On 29 July, CISA published version 2.1 of the Minimum Elements for a Software Bill of Materials, replacing the 2021 NTIA baseline. Seventeen partner agencies signed it, seven of them EU national cybersecurity agencies. It is not Union law and it says so. It still means that an SBOM built to satisfy the Cyber Resilience Act now fails a document that seven EU authorities put their names to, and it fails for a structural reason rather than a sloppy one.
What the CRA asks for
Annex I Part II(1) requires the manufacturer to identify and document the components in the product, including by drawing up an SBOM covering at the very least the top-level dependencies. That is the floor, and read literally it is satisfied by a single flat list of what your product directly depends on.
What replaced Depth
The 2021 baseline had an element called Depth, which was widely read as permission to stop at the first tier. The 2026 elements delete it. In its place is Coverage, which asks for all components including transitive dependencies and states explicitly that there is no minimum depth.
Around that change, the field count went from seven to seventeen, split into nine fields describing the SBOM document and eight describing each component, with six practices covering generation, maintenance and delivery. Supplier Name became Component Producer. The document cites Regulation (EU) 2024/2847 by name and points at BSI TR-03183-2 as related guidance, so nobody has to guess whether the authors had the CRA in view.
So the floor fails, by construction
Put the two side by side. The CRA floor is a flat list of direct dependencies. Coverage wants the whole graph and refuses to name a stopping point. A manufacturer who read Annex I carefully, did exactly what it says and stopped, now holds a document that fails the new baseline on its first element.
That is worth separating from ordinary non-compliance. Nothing was skipped and no tool misbehaved. The two texts want different artifacts. And the seven EU agencies whose names are on the document that says top-level-only is insufficient are ANSSI, BSI, ACN, NASK, NBU, NCSC-NL and NÚKIB, with DG CONNECT contributing. Those are the agencies your customers' procurement teams read. The legal minimum and the expected deliverable have come apart.
It fails the other way too
The obvious next move is to treat the stricter document as the target and stop thinking about it. That does not work either, because the disagreement is not a simple ranking.
BSI TR-03183-2 section 4 sets format version floors of CycloneDX 1.6 and SPDX 3.0.1. The 2026 elements set none at all, asking only that deprecated versions be avoided. So a CycloneDX 1.5 document passes the 2026 minimum elements and fails the BSI guidance that German procurement actually cites. Neither framework is a superset of the other.
Two things a document cannot prove about itself
Some fields are unreachable by format rather than by effort, and any assessment that scores them as missing is lying to you.
SPDX has no in-document signature, because SPDX signatures are detached, and it has no document-version field. Those are properties of the format, so scoring an SPDX file as fourteen out of seventeen misrepresents it. The right denominator is what the format can express. CycloneDX has the mirror-image problem. It has no reserved marker for unknown information, so it can never satisfy the Explicitly Identifying Unknown Information element, while SPDX satisfies it through NOASSERTION and NONE.
Coverage deserves its own warning. A parser reads the graph the document declares. It cannot see the half of the tree that was silently left out, so a complete SBOM and a truncated one look identical from the outside. Coverage reports the shape of what was declared and is never a clean pass. Anyone selling you a green tick on completeness is selling you a tick on the file rather than on the product.
Where a checker should refuse to fail you
Two of the 2026 elements are traps if read mechanically.
The document asks for hash algorithms named with IANA Hash Function Textual Names. CycloneDX emits SHA-512 and SPDX emits SHA512, and neither string matches the IANA register. A checker that enforces this literally fails every real SBOM in existence on a naming technicality, which tells you nothing about the software.
The other one runs the opposite way and should be enforced. The 2026 elements deliberately separate SBOM Author from SBOM Tool Name. A generator listed in the tools block is not an author. Accepting a tool as the author, which is a reasonable shortcut under BSI TR-03183-2, quietly erases the accountable party the new elements were written to surface.
Why one score is the wrong answer
The temptation is to fold both frameworks into a single conformance percentage. Resist it. Every case above is one where the two documents want different things, and averaging them produces a number that is wrong in a direction you cannot recover. A CycloneDX 1.5 file with a full dependency graph would score respectably and hide the fact that it fails outright for a German buyer.
Our own SBOM validator reports the two as separate panels and labels the 2026 result as international guidance rather than EU law, with a test that fails the build if that label ever drifts into implying presumption of conformity. The disagreement between the panels is the output. The panels themselves are just how you get to it.
What to generate
- The full dependency graph, transitive included, rather than the Annex I floor
- A format version at or above CycloneDX 1.6 or SPDX 3.0.1, which satisfies both documents
- Explicit unknown markers where you genuinely do not know, which means SPDX if that element matters to your buyers
- A named human or organisation as SBOM Author, with the generator recorded separately as the tool
- Two assessments, read apart, with the conflicts surfaced rather than averaged
The other two publications that week
ENISA's Secure by Design and Default Playbook landed on 30 July. Twenty-two short playbooks on GitHub under CC BY 4.0, written with SMEs in mind, and good material. It also maps onto Annex I Part I closely enough to look like a compliance checklist, which it is not, since only a standard cited in the Official Journal confers presumption of conformity and none has been cited. Three Annex I requirements go untouched across all 22, namely placing a product on the market with no known exploitable vulnerabilities, data minimisation, and limiting an incident's impact on the availability of other devices.
ENISA also formalised its Single Reporting Platform guidance on 31 July, as a factsheet plus registration and submission user guides. Worth reading if you have not set up EU Login accounts yet. Worth being clear about what is in it, though, because the headline everyone reached for was the confirmation that no submission API will be provided, and ENISA has been saying that publicly for well over a month. We wrote it into our own pricing and product copy in mid-June. The documents are new. The facts in them mostly are not.
Check an SBOM against both baselines at cvdportal.com/tools/sbom-validator, or read the CRA article by article at cvdportal.com/cra/articles.