The EU Cyber Resilience Act (CRA) makes the software bill of materials a legal requirement for anyone placing products with digital elements on the EU market. That includes connected devices, industrial equipment, embedded systems and software, whether the manufacturer is based in Europe, the US or elsewhere. This guide explains what the CRA actually asks for, what it does not, and how to build an SBOM process that survives years of product releases.
What the CRA says about SBOMs
The requirement sits in Annex I, Part II of the regulation (Regulation (EU) 2024/2847), the vulnerability handling requirements. Manufacturers must “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 details in that sentence matter more than they look:
- Commonly used and machine-readable: a spreadsheet or a PDF is not enough. In practice this means CycloneDX or SPDX.
- At the very least the top-level dependencies: the legal minimum is the direct dependencies. Going deeper is good practice, not a CRA obligation.
- Part of vulnerability handling: the SBOM is not a standalone deliverable. It exists so that you can find out quickly which products and versions a new vulnerability affects.
CRA SBOM requirements at a glance
| Requirement | What it means in practice |
|---|---|
| Machine-readable format | CycloneDX or SPDX, generated by tooling, not written by hand. |
| Top-level dependencies as a minimum | Direct dependencies are mandatory. Transitive dependencies are strongly recommended for useful vulnerability matching. |
| Part of the technical documentation | The SBOM sits in your technical file and must be provided to market surveillance authorities on reasoned request. |
| No obligation to publish | You decide whether to share it with customers. If you do, the user information must say where to find it. |
| Kept over time | Technical documentation is kept for 10 years after the product is placed on the market, or for the support period if longer. |
| One SBOM per version | Each release needs the SBOM that matches what was actually shipped. |
The European Commission can specify the SBOM format and its mandatory elements through implementing acts. Until then, Germany’s BSI technical guideline TR-03183-2 is the most detailed public reference in Europe for formats, required fields and dependency depth.
When do the CRA SBOM rules apply?
- 10 December 2024: the CRA entered into force.
- 11 September 2026: reporting obligations apply. Actively exploited vulnerabilities must be reported within 24 hours. You cannot meet that deadline without knowing which products contain the affected component.
- 11 December 2027: all essential requirements apply, including the SBOM as part of vulnerability handling and technical documentation.
Products placed on the market before December 2027 are not exempt in practice: the reporting obligation already covers them, and an SBOM is the fastest way to answer “are we affected?”.
How the CRA compares with US SBOM requirements
In the US, SBOM expectations come from Executive Order 14028 and federal procurement, not from a product law. The NTIA “minimum elements” (supplier, component name, version, unique identifier, dependency relationship, SBOM author and timestamp) are still the common baseline, and CISA proposed an updated version in 2025. A product shipped on both markets can use the same SBOM: the CRA adds the obligation to keep it in the technical documentation and to tie it to vulnerability handling over the support period.
SPDX vs CycloneDX: which format for the CRA?
Both formats are commonly used and machine-readable, so both meet the CRA wording. The choice depends on what you need the SBOM to do next.
| CycloneDX | SPDX | |
|---|---|---|
| Maintained by | OWASP (standardized as ECMA-424) | Linux Foundation (ISO/IEC 5962:2021) |
| Original focus | Security and supply chain risk | License compliance and open source provenance |
| Vulnerability data | Native support for VEX and vulnerability information | Handled through SPDX 3.0 security profile or a separate VEX document |
| Hardware and firmware | Supports hardware, firmware and services components | Software-centric, extended in SPDX 3.0 |
| Typical tooling | cdxgen, Syft, Trivy, CycloneDX CLI | Syft, SPDX tools, Yocto (built-in SPDX output) |
If vulnerability handling is the main driver, CycloneDX is usually the shorter path. If your build already produces SPDX (Yocto does natively) or license compliance is a priority, keep SPDX. Converting between the two is possible, but pick one format as your reference to avoid two diverging inventories.
Generating SBOMs for embedded and connected products
Most SBOM guides assume a cloud application with a package manager. Manufacturers of devices face harder cases:
- C and C++ firmware without a package manager: components are often vendored or copied into the source tree. Build-system integration or binary analysis is needed to see them.
- Embedded Linux: Yocto can generate SPDX for every image at build time. Use that output rather than scanning the image afterwards.
- Third-party binaries and SDKs: ask suppliers for their SBOM and merge it into yours. Your SBOM is only as complete as the least documented supplier.
- Legacy products: products released before the CRA often have undeclared dependencies. Budget two to three times more effort for them.
Whatever the product, generate the SBOM in the build pipeline, at every release, and store it next to the release artifacts. An SBOM produced once at launch is out of date at the next patch.
From SBOM to vulnerability handling
An SBOM on its own does not reduce risk. It becomes useful when it feeds the rest of the process:
- Match components against vulnerability sources (NVD, OSV, vendor advisories) continuously, for every product version still supported.
- Assess exploitability in the actual product. A component being present does not mean the vulnerability can be exploited.
- Communicate the result, for example with a VEX statement telling customers whether they are affected.
- Keep the history: which SBOM, which version, which decision and when. That is what an auditor or a market surveillance authority will ask for.
Where to start
- List the products in scope and the versions still under support, with their build systems and languages.
- Run a pilot on one product: generate the SBOM, check that direct and transitive dependencies are complete, fix false positives.
- Automate it in CI so every release produces and stores its SBOM.
- Roll out to all products, connect the SBOMs to vulnerability monitoring, and document the process for your technical file.
CRA SBOM FAQ
Does the CRA require transitive dependencies in the SBOM?
No. The legal minimum is the top-level dependencies. Including transitive dependencies is still recommended, because most vulnerabilities sit deeper in the dependency tree.
Do I have to publish my SBOM?
No. The SBOM must be part of your technical documentation and available to market surveillance authorities on request. Sharing it with customers is your decision.
Which SBOM format does the CRA require?
None by name. It must be commonly used and machine-readable. CycloneDX and SPDX both qualify. Implementing acts may specify the format later.
Does an SBOM make a product CRA compliant?
No. The SBOM is one element of the vulnerability handling requirements. Compliance depends on the whole process: risk assessment, vulnerability handling, updates, reporting and documentation over the support period.