What the CRA requires of the SBOM
The text
Annex I, Part II, point 1 — Manufacturers of products with digital elements shall identify and document vulnerabilities and components contained in those products, including by drawing up a software bill of materials in a commonly used and machine-readable format covering at the very least the top-level dependencies of the products.
Reading it
“commonly used format”
In practice two formats meet the criterion: CycloneDX and SPDX. Both are standardised, widely tooled and interoperable.
A spreadsheet, a list in a document, or a platform’s proprietary export are not commonly used formats within the meaning of the requirement.
“machine-readable”
JSON, XML, YAML, tag-value. A PDF is not machine-readable, even when it contains a table. The criterion is not human legibility but the ability of a program to extract structured data without heuristics.
“at the very least the top-level dependencies”
This is a legal floor, not a target.
Top-level dependencies are the ones you declare explicitly. Transitive dependencies — those your dependencies drag in — are typically ten to a hundred times more numerous, and most supply chain incidents travel through them.
An SBOM limited to the top level satisfies the letter of the requirement and misses its point. The position to hold is full depth, with an explicit distinction between direct and transitive — see Quality and completeness.
Must the SBOM be published?
No. The Regulation does not require publishing the SBOM. It requires it to be in the technical documentation, held at the disposal of market surveillance authorities.
Communicating it to customers is a commercial and contractual decision, covered in Distribution and confidentiality.
Annex II does, however, provide that the information to the user state, where applicable, where the SBOM can be obtained — which presupposes that the question has been settled.
What the Commission may still specify
The Regulation empowers the Commission to specify, by implementing act, the format and elements of the software bill of materials. Such an act would set a common baseline and reduce today’s uncertainty about the level of detail expected.
Consequence for the choice adopteds. Producing a rich SBOM today — full depth, licences, hashes, relationships — is the robust position: a later implementing act will never ask for less than what the standard formats already allow you to express.
The chain to remember
SBOM → technical documentation (Annex VII) → EU declaration of conformity (Annex V) → CE marking → the right to sell in the Union.
That is the phrasing to use on the Legal side. It turns the SBOM from an engineering topic into a market access prerequisite.
What necessarily accompanies the SBOM
Annex I, Part II, point 1 does not stand alone. An SBOM without points 2 to 8 demonstrates nothing: the vulnerabilities identified must also be handled, advisories published, a CVD policy maintained and fixes distributed. See Vulnerability handling.