CRA SBOM requirements: what the Cyber Resilience Act asks for
Updated 2 November 2026 · General information, not legal advice. Quotes are from the official text of the Cyber Resilience Act.
The Cyber Resilience Act makes a software bill of materials (SBOM) a legal requirement for products sold in the EU. It is one line in Annex I, but it underpins everything else: you can't report an exploited vulnerability within 24 hours if you don't know which of your releases contain the affected component.
What the law says
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
‘software bill of materials’ means a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements
The SBOM requirement is part of the vulnerability handling requirements, which apply to products placed on the market from 11 December 2027 and for their whole support period. In practice you need SBOMs earlier: Article 14 reporting already applies since 11 September 2026, including to products already on the market (see the Article 14 guide).
Who sees your SBOM
The CRA does not require you to publish your SBOM. It is part of your technical documentation:
- Annex VII lists, among the information on your vulnerability handling processes, the software bill of materials, and separately says the SBOM is provided "further to a reasoned request from a market surveillance authority" where needed to check compliance.
- If you choose to share it with users, the user information must say where to find it (Annex II).
- Market surveillance authorities may also request SBOMs for EU-wide dependency assessments of specific product categories (Article 13(25)).
Which format
The law asks for a "commonly used and machine-readable format" and lets the Commission specify the format and elements later through implementing acts (Article 13(24)). Until then, the two widely used standards are the safe choice:
- CycloneDX (JSON), maintained by OWASP and standardised as ECMA-424;
- SPDX (JSON), maintained by the Linux Foundation and standardised as ISO/IEC 5962.
Germany's federal cybersecurity agency, the BSI, publishes more detailed guidance on SBOM content in its technical guideline TR-03183-2, which is a useful reference while EU-level specifications are pending.
Top-level dependencies are the minimum, not the goal
The legal floor is your direct dependencies. But exploited vulnerabilities are often in transitive ones: a library pulled in by a library you chose. If your SBOM stops at the top level, you won't see those, and you can't meet the 24-hour reporting window for them. Lockfiles already list the full dependency tree, so include it.
For each component, record at least:
- the name and exact version;
- a package URL (purl) or CPE, so vulnerability databases can match it;
- the supplier and licence where known;
- whether it is a direct or transitive dependency.
One SBOM per release
A single SBOM for "the product" isn't enough. Vulnerability handling runs for the whole support period, which is at least five years in most cases (Article 13(8)), and different versions in the field contain different components. Generate an SBOM as part of every release build and keep it alongside the release, so you can answer "which shipped versions contain this component?" in minutes.
How to produce one
Apps and services with a package manager (npm, pip, Go, Cargo, Composer, Bundler, NuGet and others): generate the SBOM from the lockfile in CI. With the free ShipAttest CLI, for example:
npx @shipattest/cli sbom . -o sbom.cdx.json
Firmware, embedded Linux, containers, C and C++: there is usually no single lockfile, so generate the SBOM from the build system or the finished image. The Yocto Project can produce SPDX for each image it builds, Zephyr can generate SPDX documents from a build, and tools such as Syft read container images and file systems. Most firmware SBOMs need some manual additions for vendored or binary-only components, so review what the tools miss.
An SBOM only helps if someone watches it
An SBOM in a folder doesn't tell you when a component becomes actively exploited. ShipAttest stores the SBOM of every release you upload, from the CLI or the GitHub Action, re-checks each component daily against OSV, CISA KEV and ENISA EUVD, and starts the Article 14 clock when something you ship becomes exploited. It also accepts CycloneDX or SPDX JSON from other tools for firmware and containers. See how it works.