SBOM Requirements: 6 Proven Steps to CRA Compliance

An SBOM is now a legal artefact in the European Union, not an engineering nicety. The Cyber Resilience Act asks for one in four separate places, and only one of them is the requirement everybody quotes.

The part most manufacturers miss is that it lives permanently inside the technical documentation. It is not a document you produce when someone asks.

Where the CRA asks for an SBOM

Annex I, Part II, point (1) is the well-known one. 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 phrases in that sentence do real work.

• “Vulnerabilities and components”. The SBOM supports the obligation; it does not discharge it. Identifying vulnerabilities in components is a separate limb.
• “Commonly used and machine-readable”. That is the only formal constraint on format in the Regulation as it stands.
• “At the very least the top-level dependencies”. A floor, phrased so that nobody could mistake it for a target.

The SBOM is part of your technical documentation

This is the requirement that changes how you build the thing. Annex VII, point 2(b) requires the technical documentation to contain the necessary information and specifications of the vulnerability handling processes, including the software bill of materials, the coordinated vulnerability disclosure policy, evidence of the provision of a contact address for reporting vulnerabilities, and a description of the technical solutions chosen for the secure distribution of updates.

So the SBOM is not an output you generate on demand. It sits in the technical file alongside the architecture description, and the technical file has to be kept current for the whole support period. A build pipeline that can produce an SBOM today but cannot reproduce the one for a release shipped two years ago does not meet this.

An authority can ask for your SBOM with no suspicion at all

Article 13(25) is the provision almost nobody plans for. To assess the dependence of Member States and the Union on software components — in particular free and open-source components — the administrative cooperation group may decide to conduct a Union-wide dependency assessment for specific categories of product. For that purpose, market surveillance authorities may request manufacturers to provide the relevant software bills of materials.

Read that carefully. The trigger is not a complaint, an incident or a concern about your product. It is a policy exercise about European software dependency, and your SBOM is the input. The authorities then pass anonymised, aggregated dependency information up to the cooperation group.

The practical consequence is availability. You need to be able to produce an SBOM, in machine-readable form, for any release still within its support period, without a reconstruction project.

Giving the SBOM to customers is optional

Annex II, point (9) settles a question that comes up in every procurement conversation: if the manufacturer decides to make available the software bill of materials to the user, information on where it can be accessed must appear in the information and instructions to the user.

If. The CRA does not require you to publish it. It requires that, having decided to publish, you tell users where to find it.

That makes SBOM publication a commercial decision rather than a compliance one — but the decision itself should be recorded either way, because it is the kind of thing an assessor asks about and a sales team answers inconsistently.

What an SBOM actually is under the Regulation

Article 3(39) defines it as a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements.

“Supply chain relationships” is the operative phrase. A flat inventory of component names and versions is a parts list. The definition expects the relationships between them — which is what makes a transitive dependency traceable when a vulnerability lands in something three levels down.

On format: Article 13(24) lets the Commission specify the format and elements of the SBOM by implementing act, taking European and international standards into account. No such implementing act has been adopted as at 16 August 2026, so “commonly used and machine-readable” remains the whole test — and the widely adopted machine-readable SBOM formats satisfy it.

How deep should the SBOM go

Top-level only is defensible and weak. Most component vulnerabilities that will actually reach you arrive through transitive dependencies, and Part II point (1) requires you to identify vulnerabilities in components regardless of how deep your SBOM declares itself to go. Stopping at the first level does not narrow the obligation — it just removes the evidence you would need to answer it quickly.

Treat depth as a resourcing decision taken deliberately and written down, not as a default inherited from whatever your build tool emits.

How the SBOM connects to the rest of the CRA

Where to start with your SBOM

1. Generate one per release artefact, automatically, as part of the build — not per product, and not by hand.
2. Pick a commonly used machine-readable format and record why you consider it commonly used.
3. Decide your depth beyond top-level dependencies, and write the reasoning down.
4. Retain SBOMs for the support period of every release, and prove you can retrieve an old one.
5. Put it in the technical documentation, with the coordinated vulnerability disclosure policy and the contact address.
6. Decide whether to publish, and if you do, add the access location to the user information under Annex II point (9).

This guide reflects Regulation (EU) 2024/2847 as published on EUR-Lex, read at 16 August 2026. The Commission may specify SBOM format and elements by implementing act — check whether one has been adopted before fixing your format.

The EU CRA Toolkit provides 74 editable templates covering the SBOM procedure, the vulnerability handling processes, the technical documentation structure and the reporting records the Regulation expects.