Regulations

SBOM under the CRA — what the regulation actually requires

What the CRA says about SBOMs: top-level dependencies as the minimum, a machine-readable format, CycloneDX and SPDX, and who can request one.

Michał Jaśniewski October 24, 2026 7 min read

The CRA requires an SBOM — but less than the market narrative suggests, and more than most teams assume. Annex I Part II point 1 requires the manufacturer to identify and document vulnerabilities and components contained in the product, 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”. The regulation does not name CycloneDX or SPDX, does not require the SBOM to be published and does not require it to be handed to customers. It requires you to have one, keep it current over time, and provide it on a reasoned request from a market surveillance authority.

Three places the SBOM appears in the regulation

What makes it confusing is that the obligation is spread across the text.

Annex I Part II point 1 — the source of the obligation. The SBOM is the means of meeting a broader requirement: identifying and documenting the product’s components and vulnerabilities.

Annex VII points 2 and 8 — the SBOM is part of the technical documentation: in point 2 as part of the specification of the vulnerability handling processes, and in point 8 as a separate item provided on a reasoned request from a market surveillance authority.

Article 13(24) and (25) — the future, and oversight. Paragraph 24 empowers the Commission to specify the format and elements of the SBOM by implementing act. Paragraph 25 allows ADCO to decide to carry out a Union-level dependency assessment for selected categories of products; market surveillance authorities can then request SBOMs from manufacturers and pass anonymised and aggregated information to ADCO, which reports it to the NIS Cooperation Group.

Article 13(25) gives you a practical comfort: the SBOM goes to authorities, not into public circulation, and travels further only in anonymised, aggregated form. The concern about exposing your technology stack to competitors is addressed by the mechanism itself.

"At the very least the top-level dependencies" — what it means

This is the most overestimated part. The regulatory minimum is the product’s direct dependencies, not the full transitive tree.

For a Node.js application, that means the packages listed in package.json, not the 1,800 packages in package-lock.json. For a container image — the base image and the installed packages, not every system library individually.

But the regulatory minimum is not the same as the useful minimum. If the SBOM is meant to do anything beyond being shown to an authority — for example, answering “are we affected by the flaw in library X?” — you need the transitive tree, because that is exactly where the vulnerabilities exploited in practice tend to sit.

So the business case for a deeper SBOM is different from compliance: it shortens the time it takes to answer a customer query and to respond to your own security event. The Article 14 clocks (24 hours for the early warning notification) only work when you know which products and versions contain the vulnerable component.

Format: the regulation is silent, the market is not

The CRA requires a “commonly used and machine-readable format”. It does not name a standard. Until the Commission uses Article 13(24), the choice is the manufacturer’s.

Two formats have the status of international standards:

The practical difference for a software manufacturer: CycloneDX grew out of security needs (it has native models for vulnerabilities, VEX and dependency relationships), while SPDX grew out of licence management and open-source legal compliance. Most toolchains generate both, so an either/or choice is rarely a real constraint.

An operational recommendation, not a legal one: generate in one canonical format, store versioned artifacts per release, and treat conversion as an output step performed on the recipient’s request.

An SBOM is not a document — it is a build artifact

The most common implementation mistake: an SBOM generated once, by hand, for a version that is no longer sold.

Annex VII point 1 requires the documentation to state the software versions affecting compliance, and Article 31(2) requires the documentation to be kept up to date at least throughout the support period. So an SBOM has to exist per supported product version, not per product.

That settles where it belongs in the process: generated in the pipeline, in the same step that builds the release artifact, and written to an immutable registry. An SBOM produced after the fact from a scan of the production environment describes the state of the deployment, not the state of the release — and does not answer the question of what the manufacturer actually placed on the market.

A second conclusion: it pays to bind the SBOM to the artifact signature. Annex I Part II point 7 requires secure distribution of updates, and Annex VII point 2 requires the technical solution that achieves this to be documented. A signed artifact with its SBOM attached covers both requirements with a single mechanism (see also artifact signing with Cosign).

Third-party components: the obligation goes beyond the list

An SBOM is a list. The CRA requires you to act on it.

Article 13(5) — the manufacturer exercises due diligence when integrating components sourced from third parties, so that they do not compromise the cybersecurity of the product. The obligation explicitly covers free and open-source software components that are not made available on the market in the course of a commercial activity.

Article 13(6) — when the manufacturer identifies a vulnerability in an integrated component (open source included), it reports it to the person or entity manufacturing or maintaining that component, and addresses and remediates it in line with Annex I Part II. Where the manufacturer has developed a fix, it shares the relevant code or documentation with that person or entity — where appropriate, in a machine-readable format.

Article 13(7) — systematically documenting relevant cybersecurity aspects, proportionate to the risks, including known vulnerabilities and relevant information from third parties, and updating the risk assessment where applicable.

Taken together, an SBOM without a vulnerability triage process does not serve the purpose of Annex I Part II. Merely having a list of components is not “identifying and documenting vulnerabilities”.

What the CRA does not require

The negative list saves budget and time:

Separating these four points from the actual requirements is a concrete saving — it narrows the implementation to what the regulation really imposes and reduces the risk of disclosing information the CRA does not oblige you to disclose.

What it means for a software manufacturer

Three decisions to make before 11 December 2027, when the documentation obligations and CE marking start to apply:

The side effect is usually commercial: the same artifact answers the questions in enterprise customers’ security questionnaires that block contracts today, long before the CRA gets to require anything.

Sources

For information only, not legal advice. This article covers the technical and process layer of the obligations under Regulation (EU) 2024/2847; full compliance also requires organizational and legal work on your side and does not replace legal advice or a formal conformity assessment. Current as of October 2026.

CRASBOMSupply Chain Security