CRA SBOM requirements explained
What the Cyber Resilience Act actually requires for SBOMs. The Annex I Part II wording, what machine-readable means in practice, whether the SBOM must be public, and how it feeds vulnerability handling.
Yes, the CRA requires an SBOM. Annex I Part II of Regulation (EU) 2024/2847 requires manufacturers to identify and document the vulnerabilities and components in their product, including a Software Bill of Materials in a commonly used, machine-readable format covering at least the top-level dependencies. The SBOM lives in your technical documentation, available to authorities on request, and it does not have to be public.
That single sentence in the regulation carries a lot of practical weight, because the SBOM is the foundation the CRA's vulnerability-handling requirements stand on. This post unpacks what the requirement says, what it does not say, and how to meet it without turning it into a documentation project. For the CRA's full scope and dates, in force since 10 December 2024, reporting obligations from 11 September 2026, full requirements from 11 December 2027, see our Cyber Resilience Act framework page.
What does Annex I Part II actually require?
The vulnerability-handling requirements in Annex I Part II open with the component obligation: manufacturers must identify and document vulnerabilities and components contained 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 of the product. Three phrases in that wording do the work.
| Phrase in the requirement | What it means in practice |
|---|---|
| "Commonly used format" | An established SBOM standard, in practice CycloneDX or SPDX, not a home-grown schema |
| "Machine-readable" | Structured JSON or XML that tooling can parse and diff, not a spreadsheet or PDF |
| "At the very least the top-level dependencies" | The floor is your direct dependencies; going deeper into transitive dependencies is better practice and often what your tooling produces anyway |
Note what is absent: no named format, no requirement to publish, no prescribed depth beyond the top-level floor. The regulation sets the outcome and leaves the mechanics to you and, eventually, to harmonised standards that are still being finalised.
Does the SBOM have to be public?
No, and this surprises teams who assume SBOM means disclosure. The SBOM is part of the technical documentation for the product, the file you must keep and be able to hand to a notified body during conformity assessment or to a market surveillance authority on request. What goes into that file, and how the SBOM sits inside it, is covered in CRA technical documentation under Annex VII. Separately, your commercial buyers may ask for the SBOM in procurement, and being able to produce a current one on request is quietly becoming a deal-stage advantage, but that is a market expectation, not a CRA publication duty.
Which format should I use, CycloneDX or SPDX?
The CRA does not choose for you; it asks for a commonly used, machine-readable format, and CycloneDX and SPDX are the two that clear that bar. CycloneDX tends to fit security-first pipelines and embedded toolchains, SPDX has deep roots in license compliance and the Linux Foundation ecosystem, and both serialise to JSON that vulnerability tooling can consume. We wrote a full decision matrix for embedded teams in CycloneDX vs SPDX, and a hands-on walkthrough of generating an SBOM from a real firmware project in ESP-IDF SBOM hands-on. If you have no constraint pulling you either way, pick the one your build tooling generates natively and move on; the value is in having a current SBOM, not in the format debate.
What does "machine-readable" mean in practice?
It means a structured document that software can parse, validate, and compare without a human in the loop: CycloneDX JSON, SPDX JSON, or their XML equivalents. A dependency list in a spreadsheet, a README, or a PDF fails the test even if the content is identical, because nothing can automatically match it against a vulnerability feed. The practical consequence is that SBOM generation belongs in your build pipeline. If producing the SBOM is a manual step, it will drift from what you actually ship, and a stale SBOM fails at the exact moment it is needed, when you have to answer "are we affected?" quickly.
How does the SBOM connect to vulnerability handling?
Directly; it is the input to almost everything else in Annex I Part II. Vulnerability monitoring only works if there is a component inventory to monitor against: a new CVE lands, your tooling matches it to the affected component and version in the SBOM, and you know within minutes whether any shipped product contains it. That same lookup is what makes the CRA's reporting obligation workable. From 11 September 2026, an actively exploited vulnerability must be reported within 24 hours of awareness, and you cannot make that determination fleet-wide without a current SBOM per product version. The reporting mechanics are covered in CRA vulnerability reporting under Article 14. An SBOM that exists only as a compliance artefact is a missed opportunity; wired into monitoring, it is the thing that answers the 3 a.m. question.
Does an SBOM cover hardware and third-party components too?
The SBOM requirement is about software components, but the wider Annex I Part II duty to identify and document components does not care where a component came from. Open-source packages, commercial libraries, vendored SDKs from your silicon supplier: if it ships in the product, it belongs in the inventory. How the CRA treats the open-source pieces specifically is covered in how the CRA treats open source software, and the vendor side in CRA supply chain requirements.
Frequently asked questions
Does the Cyber Resilience Act require an SBOM? Yes. Annex I Part II of Regulation (EU) 2024/2847 requires manufacturers to identify and document the vulnerabilities and components in their product, including by drawing up a Software Bill of Materials in a commonly used, machine-readable format covering at least the top-level dependencies.
Does the CRA SBOM have to be public? No. The SBOM is part of the technical documentation, which you must be able to hand to a notified body or a market surveillance authority on request. Nothing in the requirement forces you to publish it to customers or the general public, though some buyers will ask for it in procurement.
Which SBOM format does the CRA require, CycloneDX or SPDX? The regulation does not name a format. It requires a commonly used, machine-readable format, and CycloneDX and SPDX are the two established candidates that satisfy that. Either works for CRA purposes; the choice comes down to your toolchain and what your buyers ask for.
What does machine-readable mean for an SBOM? A structured data format, JSON or XML in practice, that software can parse without a human interpreting it. A spreadsheet of dependencies or a PDF listing does not qualify. Machine-readable is what lets vulnerability monitoring match new CVEs against your components automatically.
Do I need an SBOM for every product version? In practice yes. The SBOM documents the components of the product you place on the market, so each shipping firmware or software version needs an SBOM that reflects it. That is why SBOM generation belongs in the build pipeline rather than being a one-time document.
Last reviewed: July 7, 2026.
Where Scadable fits
Scadable is the compliance engine that makes the SBOM a living input instead of a document: it builds and maintains the SBOM for every product version you ship, matches it continuously against live exploitation data, fixes what is actively exploited, files the report, and keeps your technical documentation certified and current. Run the free two minute CRA readiness check to see which obligations apply to your product, or book a walkthrough.