An SBOM is not CRA compliance

Insights · cetome.com

An SBOM is not CRA compliance

Dr Cédric LÉVY-BENCHETONCEO and founder, cetome

13 September 2026 · Cyber Resilience Act · 6 min read

The software bill of materials has become the symbol of Cyber Resilience Act readiness. Procurement teams are rewriting contracts to demand one from every supplier, and most compliance tools on the market start by asking you to upload one. The message manufacturers hear is simple: get an SBOM and you are on your way.

The SBOM is a legal requirement and a useful one. It is also one of the smaller parts of CRA compliance, and treating it as the centre of the programme creates risks that are easy to miss.

Three claims to set aside first

Much of the confusion starts with three statements that circulate widely and do not match the text of the regulation.

“You need a complete SBOM.” The CRA requires an SBOM covering at the very least the top-level dependencies of the product. That is the legal minimum, and it is a low one. We recommend going deeper wherever it is practical, because transitive dependencies are where many vulnerabilities sit. A complete SBOM is not required, however, and for most products it is probably not achievable.

“You must report the CVEs in your products to ENISA.” Reporting under Article 14 covers actively exploited vulnerabilities and severe incidents, not every vulnerability found in a component. The second half of the misconception is more dangerous: the obligation is triggered by becoming aware of active exploitation, not by the existence of a CVE identifier. A manufacturer that waits for a CVE to be assigned before reporting is already late.

“Products must be released without vulnerabilities.” The requirement is that products are made available without known exploitable vulnerabilities. A product can ship with a component that has a known vulnerability, provided the manufacturer’s analysis shows it is not exploitable in that product and the remaining risk to users is acceptable. That analysis has to exist and be documented, which is the real work.

Each of these misreadings pushes manufacturers towards the same mistake: treating a list of components and CVEs as the substance of compliance.

What the CRA asks for

An SBOM is an inventory of the software components in a product, usually expressed in a machine-readable format such as CycloneDX or SPDX. The CRA’s vulnerability handling requirements oblige manufacturers to identify and document the components in their products, including by drawing up an SBOM. It forms part of the technical documentation and does not have to be published.

That is the extent of the obligation: an inventory. The regulation does not say how to build it, how to structure it, or how to use it. The assumption that an SBOM manages vulnerabilities, or supports reporting to the authorities, comes from the market rather than from the text.

An inventory is not a process

The logic behind the SBOM is the old asset management principle that you cannot protect what you cannot see. Knowing your components is the first step. Three further steps are where the work lies.

From component to vulnerability. Matching components against vulnerability databases depends on those databases being accurate and current. They are maintained largely by hand, enrichment lags are common, and for some components the delay runs to months or longer.

From vulnerability to exploitability. The test, as noted above, is exploitability. A scanner fed with an SBOM will typically return hundreds or thousands of matches and cannot say which are exploitable in your product. That answer requires knowledge of the code, the configuration and the architecture, or actual testing. VEX statements are meant to carry this information, but for many components they do not exist.

From exploitability to reporting. Article 14 concerns actively exploited vulnerabilities and severe incidents, with an early warning due within 24 hours. An SBOM says nothing about active exploitation. That awareness comes from threat intelligence, coordinated disclosure, customer reports and incident detection.

A manufacturer whose only vulnerability input is an SBOM matched against public databases is relying on a source that lags reality. The CRA expects vulnerabilities to be addressed without delay, and a process built on delayed inputs cannot credibly meet that standard.

What we see in practice

Working with large manufacturers and their supply chains, we see the same patterns repeatedly.

• No common method. Some build the SBOM from source, some from binaries, some by consolidating suppliers SBOMs. The results differ for the same product, and a single product often has several SBOMs that do not reconcile.
• Flat structures. Many SBOMs, including those from established manufacturers, list components without their dependency relationships. Without that structure, it is impossible to tell where a vulnerable component sits or what depends on it.
• Altered identifiers. Some suppliers rename or renumber the open source components they ship. Automated matching then fails silently, and the vulnerability never appears.
• One-way transparency. Manufacturers readily demand SBOMs from their suppliers and rarely agree to share their own with customers.
• Box-ticking. The SBOM clause lands in the contract, a file is delivered, and nobody checks whether it is usable.

None of this is bad faith. It is what happens when a regulation names an artefact without defining how it should be produced, and an industry rushes to deliver the artefact.

Where the effort should go first

The CRA is built on risk. Manufacturers must carry out a cyber security risk assessment and apply the essential requirements in light of it. That assessment determines what the product needs, which in turn determines the design decisions, the evidence and the vulnerability handling process. It is the foundation for everything else, the SBOM included.

The question we ask new clients is therefore not whether they have an SBOM. It is whether they have a repeatable risk assessment methodology that product teams can apply without a security specialist in the room. Most do not, and that gap matters far more than the format of a JSON file.

A sensible order of work:

Summary

If you want to know where your portfolio stands, evaluate your products with CRAted, see how we approach CRA readiness or talk to us.