What the CRA actually requires of your SBOM
Short answer. The regulation's actual requirement is narrower than the tooling market suggests.
- What: a software bill of materials in a commonly used machine-readable format.
- How deep: “at the very least the top-level dependencies”. Direct dependencies clear the text.
- Which format: the regulation does not say. The implementing act that would say has not been adopted.
- Who gets it: it goes in your technical file, and to a market surveillance authority on reasoned request. Giving it to customers is optional.
There is a whole category of product being sold to manufacturers on the strength of this obligation — repository integrations, CI pipeline scanners, continuous transitive dependency graphs. Some of it is genuinely useful engineering. Very little of it is what the CRA asks for, and it is worth knowing the difference before you buy, because the gap between the statutory floor and the sales pitch is large.
- What the regulation says
- “At the very least the top-level dependencies”
- The format question, and the act that has not arrived
- Who is entitled to your SBOM — three different answers
- BSI TR-03183-2: useful, detailed, and not law
- The hash disagreement, and why it matters
- The clause nobody mentions: Union-wide dependency assessments
- What to actually do
What the regulation says
The SBOM duty lives in Annex I, Part II, point 1 — the vulnerability-handling half of the essential requirements. It requires the manufacturer to identify and document the vulnerabilities and 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.
Three phrases in that sentence carry the whole obligation, and each one is narrower than it is usually reported:
| Phrase | What it does |
|---|---|
| “including by drawing up” | The SBOM is one means of satisfying a broader duty to identify and document components and vulnerabilities. It is not a free-standing deliverable with its own separate rules. |
| “commonly used machine-readable format” | No format is named. A PDF or a spreadsheet is not machine-readable in this sense; a CycloneDX or SPDX document plainly is. |
| “at the very least the top-level dependencies” | A floor, expressed as a minimum. Deeper is allowed. Deeper is not required. |
“At the very least the top-level dependencies”
This is the phrase worth understanding properly, because it is the difference between a form you fill in and a build-system integration you maintain forever.
Your top-level or direct dependencies are the components you chose — the ones named in
your package.json, requirements.txt, go.mod, Cargo.toml,
pom.xml, or the third-party libraries and modules you deliberately linked. Your
transitive dependencies are everything those in turn pull in, which in a modern application
runs to hundreds or thousands of packages.
The regulation's floor is the first set. A document listing the components you chose, with versions, in CycloneDX or SPDX, satisfies the text as drafted.
1. “At the very least” is a minimum, and minima attract scrutiny. If a vulnerability in a deep transitive dependency is exploited in your product, the fact that your SBOM met the floor will not be the interesting question — the interesting question will be your vulnerability-handling process under the rest of Annex I Part II, which requires you to address and remediate vulnerabilities without delay. Meeting the SBOM floor is not the same as managing your dependency risk, and the regulation asks you to do both.
2. Generating transitive dependencies is often trivially cheap. Most package managers emit a full tree with one command, and most SBOM tools do it by default. Where that is true, the deeper SBOM is the better engineering choice regardless of what the floor says, and this page is not an argument for producing less than you easily can.
3. Harmonised standards may set the bar higher in practice. When the standards underpinning the CRA arrive, the way to demonstrate conformity will be to follow them, and they may specify more than the annex's floor. Treat today's minimum as today's minimum.
What the floor does tell you is this: the SBOM is not the hard part of CRA compliance, and you should not let it become the part you spend your budget on. The technical documentation, the risk assessment and the vulnerability-handling process are all harder and all matter more.
The format question, and the act that has not arrived
Article 13 empowers the Commission to specify the format and elements of the software bill of materials by implementing act, taking into account existing standards and best practices.
So the regulation anticipated that “a commonly used machine-readable format” was too vague to stand, and reserved the power to fix it. As of this page's last check, no such act had been adopted. Searches of the EU's own legislative database returned the parent Regulation, its consolidated text and the separate classification implementing regulation — and no SBOM-format instrument.
Two practical consequences:
- Right now you choose the format, and there are two sensible choices. CycloneDX and SPDX are both widely used, both machine-readable, both emitted by standard tooling. Either is defensible under the text as it stands.
- This is a live maintenance trigger. When the implementing act lands it can specify both a format and a field list, and an SBOM you generated before it may not satisfy it. If you are retaining documents for ten years, the question is not just whether your SBOM is compliant today but whether you will notice when the answer changes.
Who is entitled to your SBOM — three different answers
This is where most manufacturers are told something wrong. There are three separate duties and only two of them are unconditional.
| Who | Duty | Conditional? |
|---|---|---|
| Your own technical file | The SBOM is named in Annex VII point 2(b) as part of the documentation of design, development and vulnerability handling | No |
| A market surveillance authority | Annex VII point 8 requires the SBOM further to a reasoned request from a market surveillance authority | No — but only on request, not proactively |
| Your customers and users | Annex II point 9 applies “if the manufacturer decides to make available the software bill of materials to the user” — in which case you must say where and how it can be accessed | Yes. Publishing is your choice |
So “the CRA makes you publish your SBOM” is wrong, and it is a claim you will see made confidently. Annex II point 9 is drafted as a conditional: if you decide to make it available, then you have to tell users where it is. The decision is yours.
That matters commercially. An SBOM is a map of your supply chain and, read adversarially, a list of attack surfaces. There are good reasons to publish one — enterprise customers increasingly ask, and it is a credible signal — and good reasons not to. The point is that it is a business decision the regulation leaves to you, not an obligation.
BSI TR-03183-2: useful, detailed, and not law
Because the implementing act has not arrived, a vacuum opened, and Germany's Federal Office for Information Security filled it. BSI TR-03183-2, Software Bill of Materials, is a technical guideline that specifies formats, versions and fields in the detail the regulation lacks.
What it specifies, on the points where independent summaries agree:
- Formats: CycloneDX version 1.6 or later, or SPDX version 3.0.1 or later.
- Serialisation: JSON or XML.
- Component-level fields: component creator, component name, component version, filename, dependencies, distribution licences, hash, and executable, archive and structured properties.
- Document-level fields: the creator of the SBOM, and a timestamp for when it was compiled.
It is a good specification and it is a reasonable thing to build to. But be clear about what it is:
It is a national guideline. Published by a German federal authority, not by the Commission, and it does not become the EU-wide requirement by being the most detailed document available.
It says itself that it is temporary. Published summaries consistently report a supersession clause to the effect that the guideline will be replaced as its content is covered by the corresponding European standardisation deliverables. It is scaffolding, and it is designed to come down.
Following it is a defensible engineering choice, not a compliance conclusion. If you build to it, say in your technical documentation that you did and why. That is a much stronger position than either ignoring it or citing it as though it were binding.
The hash disagreement, and why it matters
Here is a concrete illustration of why you should not treat a secondary summary as a specification.
On the question of which hash algorithm TR-03183-2 requires for each component, four independently operated published sources give three different answers: two state SHA-512 as a mandatory field; one presents SHA-512 as an example of a cryptographic checksum, with “e.g.” in front of it; and one states SHA-256.
That is not a trivial discrepancy, because the two readings produce opposite behaviour in any tool that validates your SBOM:
- If SHA-512 is mandatory, an SBOM with SHA-256 hashes should fail validation, and a tool that passes it is telling you something false.
- If SHA-512 is illustrative, a tool that rejects SHA-256 is telling a compliant manufacturer their compliant SBOM is non-compliant — inside a document they will retain for ten years.
The difference between those two readings is one dropped “e.g.” in a summary. It is invisible unless you put four sources side by side, which is exactly why summaries of technical specifications should not be treated as the specification.
The defensible position, and the one this site takes: the Regulation specifies no algorithm at all. Include a hash for every component, record which algorithm you used and why, and treat a tool that hard-fails your SBOM on algorithm choice alone as making a claim it cannot support. If the algorithm genuinely matters to you, read TR-03183-2 itself rather than anyone's summary of it — including this one.
The clause nobody mentions: Union-wide dependency assessments
One more provision worth knowing, because it changes how you should think about who reads your SBOM. Article 13 contemplates that the administrative cooperation group for market surveillance may carry out Union-wide assessments of the dependencies of categories of products with digital elements, and may request SBOMs for that purpose.
The practical reading: your SBOM is not only evidence in an investigation of you. It can be requested as an input to a market-wide analysis of which components the European product base collectively depends on — the kind of exercise that happens after an incident in a widely used library. That is a sensible policy instrument, and it means “nobody will ever ask for it” is a weaker assumption than it looks.
What to actually do
- Generate an SBOM per release, per product, with your existing tooling. CycloneDX or SPDX, JSON or XML. Almost every build system has a generator; you do not need to buy one.
- Include top-level dependencies at minimum, and go transitive if it is free — which it usually is.
- Store it with the version of the product it describes, dated, and never overwrite it. This is the part people get wrong. An SBOM is only evidence if you can tell which release it belonged to, and the technical documentation is retained for at least ten years.
- Decide deliberately whether to publish it, and if you do, record where — because Annex II point 9 then requires you to tell users how to access it.
- Write down which specification you followed, in your technical documentation, with the version. If it was TR-03183-2 v2.1.0, say so.
- Put a watch on the implementing act. When the Commission specifies the format and elements, that is the day your existing SBOMs need re-examining.
An honest note on confidence. The “at the very least the top-level dependencies” clause and the conditional wording of Annex II point 9 were each confirmed against two independent reproductions of the annexes. The BSI format and serialisation requirements agreed across four independent sources. The component field list is three-sourced, and the hash algorithm is genuinely unresolved, as set out above. BSI TR-03183-2 itself has not been read for this page — every statement about its contents comes from third-party summaries, which is precisely the weakness the hash section describes, and the guideline is a free download from BSI if you need certainty. The absence of an SBOM-format implementing act is an unsuccessful search, not a verified negative. Nothing here is legal advice.
The SBOM is the easy part. The file around it is the work
Conformance House takes your SBOM as an upload — CycloneDX or SPDX, JSON or XML — and builds it into the technical documentation, the declaration of conformity and the user information, versioned and dated so you can always tell which SBOM belonged to which release.
Not sure the regulation applies to your product at all? Take the two-minute check first.