What the Regulation asks of an SBOM
One sentence of the Cyber Resilience Act creates the obligation, and it asks for less than most vendors assume. A manufacturer must identify and document the components in a 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.Annex I Part II(1)
The four things it actually requires
- A bill of materials
- A list of the components inside the product, with versions. Not a dependency policy, not a licence report, not a scan result.
- Machine-readable, in a common format
- CycloneDX or SPDX. The Regulation names no format, but it asks for a commonly used machine-readable one, and in practice those are the two.
- Top-level dependencies, at minimum
- The components you chose. Everything they in turn pull in is more than the floor — useful, and what most tools emit anyway, but not what the text demands.
- Per product, kept current
- It describes something you ship. A bill of materials for a build that is no longer in the field describes nothing you are being asked about.
“Top-level dependencies” is the part people get wrong
A top-level dependency is one your product declares for itself: the entries in your package.json, go.mod or pom.xml, and the base image you build on. A transitive dependency is one those pulled in without you asking. The text sets the floor at the first of those, not the second.
That floor is worth knowing because it is the difference between “we cannot comply yet” and “we already can”. It is not, however, a reason to stop there. The duty the SBOM exists to serve is the reporting duty, and an exploited vulnerability will more often sit in something you never chose. A generated bill of materials includes the full graph at no extra cost, so the practical advice is to record everything and treat the top level as the legal minimum rather than the target.
Why the minimum is not the useful answer
When an advisory lands, the question is “which of the versions we still support contain this component?” A top-level-only bill of materials can answer that for the libraries you named and for nothing underneath them — and underneath them is where most of the catalogue lives.
Who is entitled to see it
Not the public. The Regulation does not require a manufacturer to publish its bill of materials, and publishing a full component map of a shipped product has costs of its own. It belongs in the technical documentation kept for the product, which is what a market surveillance authority may ask for.Annex VII(2)(b)
When it has to exist
The bill of materials sits with the essential requirements that apply in full from 11 December 2027, not with the reporting duty that has applied since 11 September 2026. But the reporting duty is close to unworkable without one — you cannot say whether a vulnerability affects your product if you cannot say which products contain the component — so in practice it is the first thing to have rather than the last. Every date in the Regulation.
Getting one
If you build in a pipeline you are one command away from a compliant file. The generation guide covers the tool, the formats and how to make it part of every release; the free check tells you whether anything in the file you just produced is being exploited right now.
A match against an exploited-vulnerability catalogue is a reason to assess whether your product is affected. It is not by itself a reportable event, and what starts the 24-hour clock is a decision a person makes.
This produces evidence, timelines and drafts. It is not legal advice, and you remain the party responsible for reporting.