If you sell hardware or firmware into the EU, the SBOM is the part of Cyber Resilience Act preparation that sounds most like an engineering project and is most often described wrongly. The common version — that from 2026 you will have to publish a complete dependency tree alongside every product — is not what Regulation (EU) 2024/2847 requires on any of those three counts. It is worth reading the actual wording before you scope the work, because the real obligation is narrower and the real deadline is later.
What the Regulation actually asks for
The operative sentence is Annex I, Part II, point (1). Manufacturers shall “identify and document vulnerabilities and components contained in products with digital elements, 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.”
Three things follow from that sentence, and each one cuts against the usual summary.
- The verb is “drawing up”, not publishing. The duty is to produce and hold the record.
- The depth floor is top-level dependencies. “At the very least” makes that a minimum rather than a target, but it does mean a direct dependency list is compliant on its face. The full transitive tree is not what the text requires.
- It must be machine-readable and in a commonly used format. A PDF appendix or a spreadsheet a human maintains by hand does not satisfy this.
Article 3(39) defines the term itself: a software bill of materials is “a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements.” Note “software elements” — for a hardware product, the object of the SBOM is the software it contains, not a parts list of the physical device.
The disclosure question
This is the point most worth knowing, and it is easy to miss because it lives in a different annex. Annex II lists the information that must accompany a product. Point 9 reads: “If the manufacturer decides to make available the software bill of materials to the user, information on where the software bill of materials can be accessed.”
That is a conditional. It does not create a duty to give users the SBOM; it says that if you choose to, you have to tell them where to find it. Nothing else in the Regulation requires publication to customers. So a manufacturer can comply with the CRA while keeping its SBOM internal — which matters, because SBOMs disclose supplier relationships and version detail that most companies would not otherwise put in a datasheet.
The exception is upward, not outward. Article 13(25) allows market surveillance authorities to request SBOMs from manufacturers in specified product categories, so that the administrative cooperation group can assess Union-level dependence on particular software components — free and open-source components especially. That is a request you answer with the record you were already required to hold. It is a further reason the record needs to be real and current rather than reconstructible in principle.
Nobody has told you the format yet
Article 13(24) lets the Commission specify the format and elements of the Annex I SBOM by implementing act, taking European and international standards into account. Until such an act is adopted, “a commonly used and machine-readable format” is the whole of the requirement — which in practice points at the established machine-readable SBOM formats rather than anything CRA-specific.
Nor did the Commission use its first opportunity to say more. The guidance published on 27 July 2026 — C(2026) 5252, eighty-four pages, sixty-seven worked examples — covers scope, open-source software, substantial modification, support periods, risk assessment and the reporting duty. It does not contain the phrase “bill of materials” anywhere, and the Commission’s own implementation timeline lists no implementing act on the Article 13(24) format. Read the silence as what it is: the format question is still open, and it is open on purpose until the standards work lands.
The planning consequence is worth stating plainly: build the SBOM so it can be regenerated, not so it can be filed. A one-off document produced by hand this year will be the wrong shape when the implementing act lands and stale the first time you ship a firmware update. A generated artefact re-cut from your build is cheap to re-emit in another format.
When it actually bites
The SBOM requirement sits in Annex I, and Annex I runs on the Regulation’s general application date. Article 71(2) sets that at 11 December 2027. Only Article 14 — the reporting obligations — applies from 11 September 2026, with Chapter IV on conformity assessment bodies from 11 June 2026.
So, read strictly, the SBOM is a 2027 obligation and not a 2026 one. We are not going to pretend otherwise to move a deadline forward. But the practical case for having it in 2026 does not depend on the legal one. From 11 September 2026 you owe an early warning within 24 hours of becoming aware of an actively exploited vulnerability — including for products you shipped years ago. When the vulnerability is in a component rather than in your own code, the entire question in that first 24 hours is which of our products contain this, and in what versions. A company that can answer that from a generated SBOM answers it in an afternoon. A company that cannot spends the day reading build files.
That is the honest sequencing: the SBOM is due in 2027, and useful from 2026 because the reporting clock starts first.
What this means if you are small
Microenterprises and small enterprises get a narrow carve-out on penalties — Article 64(10)(a) disapplies fines for missing the 24-hour deadlines specifically. It does not touch the SBOM. The Annex I requirements apply to you in full, and non-compliance with Annex I sits in Article 64(2)’s top fine tier. We cover exactly what that carve-out does and does not cover separately, including the size thresholds it turns on.
The reassuring part for a small team is the depth floor. Top-level dependencies, in a machine-readable format, generated from the build you already have, is a substantially smaller job than the compliance-vendor framing suggests — and it is the thing that makes the 24-hour report answerable.
The SBOM is also named individually in Annex VII as part of the technical file, which is the document that carries most of the real cost of compliance. For what that file contains and why most small manufacturers never pay a notified body to look at it, see what CRA compliance actually costs a small maker.
Where PartsProof fits
The readiness pack produces the SBOM as a generated, machine-readable artefact alongside the coordinated disclosure policy and the reporting runbooks, so the 24-hour path exists before it is needed rather than being invented during an incident. $349 for the Readiness Pack, $649 for Readiness Plus with SBOM and reporting runbooks, $899 with a retainer. See what the pack contains or get in touch.
Every quotation and date above was verified on 29 July 2026 against the text of Regulation (EU) 2024/2847 as published in the Official Journal of the European Union. The point about the Commission guidance was checked on 1 August 2026 against the annex to C(2026) 5252 itself. Nothing here is legal advice.