Reference · By Chris · 20 May 2026 · 8 min read
Last reviewed 20 May 2026
CRA SBOM requirements: what the EU Cyber Resilience Act demands
A plain-English guide to the EU CRA SBOM requirements: where the regulation mandates a software bill of materials, what fields and format it expects, who must produce one, and how deep your dependency tree has to go.
If you are searching for the “CRA SBOM requirements”, you have probably already heard that the EU Cyber Resilience Act effectively makes a software bill of materials mandatory. This page is the reference for what the regulation actually asks for: where the obligation lives, what an SBOM must contain, the accepted formats, who has to produce one, and how far down the dependency tree you need to go.
If you instead want the hands-on version with copy-paste commands, read the companion piece, CRA SBOM: how to generate one in 15 minutes. This page covers the rules; that one covers the doing.
Does the CRA actually require an SBOM?
Short answer: not in those exact words, but in practice yes.
The CRA never contains the sentence “you must publish an SBOM”. The obligation is built up from two places in the regulation:
- Annex I, Part II (vulnerability handling requirements) requires manufacturers to “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”.
- Annex VII (technical documentation) requires the technical documentation to describe the product, including the components, which in practice means the SBOM is part of the file a notified body or market surveillance authority can request.
So the SBOM is not a “nice to have”. It is the artefact that makes the vulnerability-handling obligation auditable, and it sits inside the technical documentation every manufacturer must keep.
What the SBOM must contain
The CRA points to “a commonly used and machine-readable format” rather than spelling out every field, but the accepted formats (see below) and ENISA’s guidance converge on a minimum set. For each component, expect to record:
| Field | Why it matters |
|---|---|
| Component name | Identifies the package |
| Version | Pinned version, not a range; vulnerability matching depends on it |
| Supplier / author | Who produced the component |
| Unique identifier (purl or CPE) | Machine-matchable to vulnerability databases |
| Dependency relationship | Which component depends on which |
| Licence | Needed for legal and supply-chain review |
| Hash / checksum (recommended) | Integrity verification |
The single most important field in practice is the package URL (purl) or CPE. Without a machine-readable identifier, your SBOM cannot be automatically cross-referenced against the CVE feeds, and the whole point of the document is lost.
How deep does the dependency tree have to go?
This is the most common point of confusion. The Annex I text sets the floor at “at the very least the top-level dependencies”.
That word “least” matters. Top-level dependencies are the legal minimum, but they are rarely enough to be useful:
- A modern application’s risk lives in its transitive dependencies (the dependencies of your dependencies), which is exactly where incidents like Log4Shell and the xz backdoor surfaced.
- ENISA’s guidance and market expectation are moving toward full transitive SBOMs.
- Notified bodies assessing Class I and Class II products will expect more than a top-level list.
Practical recommendation: produce a full transitive SBOM if your tooling allows (most generators do when a lockfile is present), and treat “top-level only” as a fallback for cases where transitive resolution genuinely is not possible.
Accepted formats: CycloneDX and SPDX
The regulation does not name a format, but “commonly used and machine-readable” is universally read as the two industry-standard formats:
| Format | Steward | Notes |
|---|---|---|
| CycloneDX | OWASP | Security-first; native VEX support; common default for CRA work |
| SPDX | Linux Foundation | Licence-first heritage; ISO/IEC 5962 standard; common in US federal supply chains |
Either satisfies the CRA. Pick one and be consistent. If you already produce SPDX for another programme, keep it; if you are starting fresh and care most about vulnerability tracking, CycloneDX is the usual choice. A human-readable PDF is not sufficient on its own, because it is not machine-readable.
Who has to produce an SBOM?
The obligation falls on the manufacturer of a product with digital elements placed on the EU market. That includes:
- Commercial software vendors (desktop, mobile, SaaS distributed as a product)
- Hardware makers shipping firmware or bundled software
- Anyone who substantially modifies a product and places it on the market under their own name
Lighter or different treatment applies to:
- Open-source stewards have a lighter vulnerability-handling role; the full manufacturer SBOM obligations bite when OSS is commercially bundled. See open source and the CRA.
- Pre-2027 products may be grandfathered until a substantial modification, though vulnerability reporting still applies. See Article 69 grandfathering.
Do you have to publish the SBOM?
Not publicly, in most cases. The CRA requires the SBOM to exist and to be available to authorities on request as part of the technical documentation. It does not require you to post it on your website for the world to download.
That said, the trend is toward greater availability:
- Customers, especially NIS2-regulated ones, increasingly demand SBOMs in procurement.
- ENISA guidance points toward making the SBOM accessible to authorities through the manufacturer portal as that infrastructure matures.
A reasonable posture: generate it on every release, archive it with your release artefacts, include it in the technical documentation, and be ready to hand it to a notified body or market surveillance authority on request.
When do the SBOM requirements apply?
The SBOM sits inside the vulnerability-handling and technical-documentation obligations, which apply in full from 11 December 2027. But two earlier pressures mean you should not wait:
- Vulnerability reporting under Article 14 begins 11 September 2026, and you cannot report on components you have not enumerated.
- Procurement demand from NIS2-regulated customers is already arriving, well ahead of the CRA’s own dates.
For the full set of dates, see the EU CRA timeline.
Requirements checklist
Use this as a quick self-audit:
- An SBOM exists for each product with digital elements you place on the EU market
- It is in a machine-readable format (CycloneDX or SPDX), not just a PDF
- Every component has a name, version, and a purl or CPE identifier
- Dependency relationships are captured (ideally full transitive, not just top-level)
- It is regenerated on every release
- It is stored inside the technical documentation and retained for 10 years
- It feeds a vulnerability scanner so you can meet Article 14 reporting
Next steps
- Ready to produce one? Follow the CRA SBOM tutorial for per-language commands.
- Need the wider compliance picture? See the CRA compliance guide.
- Want to know your product class first? Try the mobile app classifier.