Does the Cyber Resilience Act require an SBOM?
Yes — and the shape of the duty is more precise than "have an SBOM somewhere".
Manufacturers must identify and document the vulnerabilities and components in the product, 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 [1]. That sentence sits inside the vulnerability-handling requirements of Annex I Part II, which every in-scope product must meet regardless of class [2].
What the floor actually is
Three properties are load-bearing.
Machine-readable, commonly used format. In practice that means CycloneDX or SPDX; a spreadsheet of package names is neither [1]. Top-level dependencies at minimum. The floor is your direct dependencies — the packages your manifests name [1]. Going deeper into transitive dependencies is better practice and most tooling produces it for free, but the legal floor is the top level [1]. Part of the technical documentation. The SBOM lives with the Annex VII technical documentation, which is drawn up before placing on the market and kept for at least ten years or the support period, whichever is longer [3] [4].
Note what is not required: publishing the SBOM. The duty is to draw it up and hold it as documentation the authorities can ask for; whether you also publish it to customers is your choice [1].
Why the SBOM is not just a file
The SBOM is the index for two live duties.
First, due diligence on components: where your product integrates a third-party component, including open source, you exercise due diligence on it, and when you find a vulnerability in a component you report it to the person maintaining it [5]. You cannot do either for components you have not enumerated.
Second, vulnerability identification is continuous: the duty is to identify and document vulnerabilities in the product, which in practice means checking the components you listed against advisories as they are published [1]. A stale SBOM makes that check silently wrong.
So treat the SBOM as generated output from your lockfiles on every release, not as a document written once. Your package-lock.json, go.sum, Cargo.lock or requirements.txt already contains the truth; the SBOM is a format conversion of it.
When this bites
The Annex I requirements, the SBOM among them, become enforceable with full application on 11 December 2027 [6] [2]. There are no harmonised standards cited yet that would let you presume conformity, so the practical path today is meeting the requirement directly and documenting that you did [7].
Check where you stand
The checker tells you whether your product is in scope and generates the duty list — SBOM included — each with its citation. A CycloneDX or SPDX file from your existing lockfile takes minutes, not weeks.
What to do next
Run your own product through the checker — it takes under a minute and gives you a dated, citable result you can send to a customer.
Sources
- Manufacturers identify and document vulnerabilities and components, 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), Art. 13(8), (24) — EUR-Lex ↩
- Annex I Part II — vulnerability handling requirements (checklist items II.1–II.8). Annex I Part II — EUR-Lex ↩
- Technical documentation contents (Annex VII). Annex VII, Art. 31 — EUR-Lex ↩
- Technical documentation (Annex VII) is drawn up before placing on the market and kept, with the EU declaration of conformity, for at least ten years after placing on the market or the support period, whichever is longer. Art. 13(12)–(13), Art. 31 — EUR-Lex ↩
- Where a product contains an integrated third-party component (including open source), the manufacturer exercises due diligence and reports vulnerabilities found in components to the person maintaining them. Art. 13(5)–(6) — EUR-Lex ↩
- The Regulation applies in full from 11 December 2027. Art. 71(2) — EUR-Lex ↩
- No harmonised standards for the CRA have been cited in the Official Journal as of the facts date; the Commission’s standardisation request M/606 covers 41 standards, with the first deliverables expected in Q3 2026. Commission / CEN-CENELEC — EUR-Lex ↩
Related
- What goes in the CRA technical file?
A technical file in the Annex VII structure — product description, design and vulnerability-handling documentation, risk assessment, SBOM, test reports — drawn up before market placement and kept for ten years or the support period.
- What must I do by 11 December 2027?
Everything else. From full application a product placed on the EU market needs a completed technical file, an EU declaration of conformity you sign, CE marking, a stated support period and a software bill of materials.
- Where does the CE marking go on a software product?
Software gets CE marked on the declaration of conformity or on the website accompanying the product — not in the app. The marking is the last step of a process, not a badge you add.
- Does the CRA require a coordinated vulnerability disclosure policy?
Yes. Every manufacturer must have a coordinated vulnerability disclosure policy in place, a contact address for reports, a single point of contact for users, and a practice of publishing fixed vulnerabilities.
CEMarque encodes Regulation (EU) 2024/2847 and the European Commission's published guidance as of 10 September 2026 (Facts v2026.09.4). It is not legal advice. Verify obligations for your product with qualified counsel where the stakes require it.