EU CRA SBOM Requirements: The Software Bill of Materials Obligation Explained
The EU Cyber Resilience Act makes a software bill of materials a legal expectation for products with digital elements sold in the EU. Here is what the SBOM clause asks for and how to meet it.
- The CRA (Regulation (EU) 2024/2847) entered into force on 10 December 2024; reporting duties apply from 11 September 2026 and the main obligations from 11 December 2027.
- Annex I requires manufacturers to identify and document components and vulnerabilities, including an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies.
- CycloneDX and SPDX both satisfy the machine-readable requirement; the harder part is keeping the SBOM accurate across every release.
- Treat the SBOM as living evidence tied to vulnerability handling, not a one-off document.
Why the CRA matters for your SBOM
The EU Cyber Resilience Act, Regulation (EU) 2024/2847, sets horizontal cybersecurity requirements for products with digital elements placed on the EU market, from connected devices to standalone software [1]. It entered into force on 10 December 2024. Reporting of actively exploited vulnerabilities and severe incidents applies from 11 September 2026, and the main essential requirements and CE marking apply from 11 December 2027 [1]. Any manufacturer selling into the EU, wherever they are based, is in scope.
What the SBOM clause actually requires
The SBOM obligation sits in Annex I. As part of vulnerability handling, manufacturers must identify and document the components and vulnerabilities in a product, including by drawing up a software bill of materials in a commonly used, machine-readable format that covers at the very least the top-level dependencies of the product [1]. Three points follow from the wording:
- Machine-readable format. A PDF list is not enough. CycloneDX [2] and SPDX [3] are the recognised choices.
- Top-level dependencies at minimum. That is the floor, not the ceiling. Deeper, transitive coverage is where most real risk hides.
- Kept current. The SBOM supports ongoing vulnerability handling, so it must track every release, not a single launch build.
How an SBOM supports the wider CRA duties
The SBOM is the backbone of several CRA essential requirements: handling vulnerabilities without delay, providing security updates, and being able to tell users which product versions are affected by a new CVE. Without an accurate, per-release SBOM, a manufacturer cannot answer the first question a regulator or customer asks after a disclosure: are we affected, and where?
Mapping SBOM data to CRA expectations
| CRA expectation | What the SBOM provides |
|---|---|
| Component identification (Annex I) | Every package and version, keyed by PURL, in CycloneDX or SPDX |
| Vulnerability handling | Components correlated with CVEs, severity and fix status |
| Security updates | Version-to-version drift showing what changed and what was patched |
| Affected-version reporting | Per-release BOMs so you can scope a disclosure precisely |
How IntelliXBOM helps
IntelliXBOM generates and ingests SBOMs in CycloneDX and SPDX, resolves dependencies beyond the top level, correlates them with vulnerability, licence and end-of-life data, and keeps a dated record of every scan so you can show an auditor the SBOM for any release. Its framework scoring checks your BOMs against regulatory profiles and lists the exact fields to enrich. The platform maps evidence to requirements; it does not certify CRA compliance, which remains the manufacturer's responsibility.
Frequently asked questions
Does the CRA require an SBOM by law?
Yes. Annex I of Regulation (EU) 2024/2847 requires manufacturers to document components and vulnerabilities, including a software bill of materials in a commonly used, machine-readable format covering at least top-level dependencies. The essential requirements apply from 11 December 2027.
Which SBOM format should I use for the CRA?
The regulation says 'commonly used and machine-readable' rather than naming a format. CycloneDX and SPDX both qualify; CycloneDX tends to carry richer vulnerability and dependency data.
Is covering only top-level dependencies enough?
It meets the legal minimum, but it leaves transitive components, where most vulnerabilities live, undocumented. Deeper coverage is strongly recommended and makes vulnerability handling far easier.
Does the CRA apply to open-source software?
It introduces a lighter regime for open-source. Commercial activity around open source can bring obligations, and 'open-source software stewards' have their own tailored duties. Check your role under the regulation.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act)EUR-Lexeur-lex.europa.eu/eli/reg/2024/2847/oj
- CycloneDX Bill of Materials standardOWASP CycloneDXcyclonedx.org/
- SPDX specification (ISO/IEC 5962)Linux Foundationspdx.dev/
- EU Agency for Cybersecurity (ENISA)ENISAwww.enisa.europa.eu/
- The Minimum Elements For a Software Bill of Materials (SBOM)US NTIAwww.ntia.gov/report/2021/minimum-elements-software-bill-materials-sbom
Sources checked in September 2026. Regulations and guidance change; always refer to the issuing body’s current publication. This content is for general information and is not legal advice.