Guide · updated 17 October 2026

CRA SBOM requirements: what the regulation actually asks for

The Cyber Resilience Act makes a software bill of materials (SBOM) mandatory for products with digital elements. The text is shorter than most vendor articles suggest. Here's what it says, what it leaves open, and why the SBOM matters for reporting today.

What the text requires

Annex I, Part II, point 1 of Regulation (EU) 2024/2847 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.

Four things follow from that sentence:

• It's mandatory for every product with digital elements in scope, not just "important" or "critical" ones.
• Machine-readable, commonly used format. The regulation doesn't name one. In practice that means CycloneDX or SPDX.
• At least top-level dependencies. That's the floor. "Top-level" isn't defined in the regulation; most teams read it as the components you directly include. Going deeper (transitive dependencies) makes the SBOM far more useful for vulnerability matching.
• It's part of vulnerability handling, not a one-off document: it should be kept current as you release new versions.

Who gets to see it

The SBOM belongs in your technical documentation (Annex VII). You must provide it to market surveillance authorities on a reasoned request. The CRA does not require you to publish it or give it to customers, although some customers will ask for it in contracts, and the Commission can specify the format and elements further through implementing acts.

When it applies

See the full CRA timeline.

Why your SBOM matters before 2027

When a vulnerability in a widely used library is exploited in the wild, every manufacturer shipping that library has the same question: are we affected, and in which products and versions? If any of your affected products is being exploited, the early warning to ENISA is due within 24 hours. Without an SBOM, answering means grepping build trees and asking engineers who may have left. With one, it's a query.

That's also why our setup starts with a product and version register: SBOMs tell you what's inside each build; the register tells you which builds shipped where.

A practical SBOM setup for a small maker

1. Pick one format (CycloneDX is common for firmware and embedded work; SPDX is widespread for licence compliance). Don't maintain both by hand.
2. Generate, don't write. Produce the SBOM in your build pipeline for each release. For embedded Linux, Yocto and Buildroot can emit SBOMs; for RTOS and bare-metal projects you may need to declare vendored libraries manually.
3. Store it per release, next to the firmware image and version number, so you can answer "what was in 2.3.1?" years later. The CRA's support period is generally at least five years.
4. Match it against vulnerability feeds regularly (OSV, NVD, vendor advisories), and record your assessment of each match, including "not affected" and why.
5. Include binary blobs and SDKs from chip vendors. They're often the riskiest components and the least documented.

What's still unclear

• The exact meaning of "top-level dependencies" for firmware with vendored code.
• Minimum elements and format details, which may come through Commission implementing acts and harmonised standards.
• How market surveillance authorities will assess SBOM quality in practice.

None of these change the practical advice: generate a machine-readable SBOM per release, keep it current, and use it.

Sources: Regulation (EU) 2024/2847, Annex I Part II and Annex VII. Not legal advice.