Guide

SBOM under the Cyber Resilience Act

Reviewed September 2026 against Regulation (EU) 2024/2847, OJ L, 20.11.2024.

Short answer: the CRA makes a software bill of materials a legal duty for manufacturers. It must be machine-readable, in a commonly used format, and cover at the very least the top-level dependencies. It lives in the technical documentation. You do not have to publish it, and a market surveillance authority can ask for it on a reasoned request.

SBOM definition: what the regulation actually says

The CRA defines the term itself, so the SBOM meaning here is not the industry’s loose one. A software bill of materials is a formal record of components and their supply chain relationships.

“a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements”

Two words in that definition do the work. Formal record rules out a prose list in a README. Supply chain relationships rules out a flat inventory of package names: the file has to say how components relate to each other, which is what a dependency graph is.

CRA SBOM: the obligation and where it sits

The duty is the first point of Annex I, Part II, the vulnerability handling requirements. It is phrased as one way of discharging a wider duty to identify and document the components a product contains.

“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 constraints follow from that one sentence.

The obligation attaches to the vulnerability handling requirements, so it runs for the support period rather than only at the moment of placing on the market. A product whose components change needs an SBOM that changes with it.

SBOM formats: SPDX, CycloneDX and the implementing act

The CRA does not name SPDX or CycloneDX. It leaves the format open and gives the Commission a power to close it later, by implementing act rather than delegated act.

“The Commission may, by means of implementing acts taking into account European or international standards and best practices, specify the format and elements of the software bill of materials referred to in Part II, point (1), of Annex I.”

Note the wording: the Commission may, and the act would take European or international standards and best practices into account. The Commission has used its CRA implementing powers elsewhere, for the Annex III and IV technical descriptions in Implementing Regulation (EU) 2025/2392, but no implementing act on the SBOM format had been adopted when this page was reviewed in September 2026. Until one is, two formats meet the “commonly used and machine-readable” test in practice:

Either satisfies the two properties the regulation actually states. Choosing between them is an engineering decision, not a compliance one, and nothing in the CRA prefers one. If an implementing act lands, it will do so with a transitional period, and a project already producing one of these two will have a conversion path rather than a rebuild.

SBOM software and tools

An SBOM is generated, not written. The practical question is where in your pipeline it is produced, because that decides what it can see.

Open-source generators in common use include Syft, the CycloneDX and SPDX toolchains published for individual language ecosystems, and Microsoft’s sbom-tool, which produces SPDX. An SBOM viewer, whether a desktop tool or a web one, is a convenience for reading the file. It is not a compliance artifact, and the regulation says nothing about one.

Cybiq does not sell an SBOM generator and does not recommend a specific vendor. What the regulation requires of the file is short enough to state, which is what this page does.

What must be in it, and an SBOM example

The regulation states one mandatory element, the top-level dependencies, and one mandatory property, a commonly used machine-readable format. Everything else is what the format you pick asks for, and what your own vulnerability handling needs in order to work.

In practice a usable entry carries the component name, its version, a unique identifier such as a package URL, its supplier, its licence and its relationship to the component that depends on it. The identifier matters most: a name and a version with no coordinate cannot be matched against a vulnerability feed, which defeats the purpose the SBOM serves in Annex I, Part II.

A minimal SBOM example is therefore not a short file. It is a complete one for a small product: every direct dependency, each with a resolvable identifier, generated by the build rather than maintained by hand, and regenerated on every release.

Who must produce an SBOM, and who sees it

The duty falls on the manufacturer. Importers and distributors have no SBOM duty of their own, though an importer or distributor that puts its own name on a product becomes the manufacturer and inherits it. Open-source software stewards sit under a lighter regime.

The file belongs in the technical documentation, alongside the coordinated vulnerability disclosure policy and the rest of the vulnerability handling evidence.

“necessary information and specifications of the vulnerability handling processes put in place by the manufacturer, including the software bill of materials”

Users do not have a right to it. Annex II, the information and instructions to the user, only asks where the file can be found if the manufacturer decides to supply it at all.

“If the manufacturer decides to make available the software bill of materials to the user, information on where the software bill of materials can be accessed.”

That conditional settles a point the CRA is often misread on: the SBOM is a documentation duty, not a publication duty. Publishing one is a choice.

How the SBOM is checked

The check is not routine. Annex VII lists the SBOM as something produced to a market surveillance authority on a reasoned request, and only where the authority needs it to verify the essential requirements.

“where applicable, the software bill of materials, further to a reasoned request from a market surveillance authority provided that it is necessary in order for that authority to be able to check compliance with the essential cybersecurity requirements set out in Annex I.”

Two things follow. The file has to exist and be current before anyone asks, because a reasoned request comes with a deadline and not with time to build a pipeline. And the technical documentation as a whole has to be kept up to date throughout the support period.

“The technical documentation shall be drawn up before the product with digital elements is placed on the market and shall be continuously updated, where appropriate, at least during the support period.”

Missing or inadequate vulnerability handling, which is where the SBOM duty sits, falls in the highest penalty bracket rather than the administrative one.

“administrative fines of up to EUR 15 000 000 or, if the offender is an undertaking, up to 2,5 % of the its total worldwide annual turnover for the preceding financial year, whichever is higher.”

When the SBOM duty starts to bite

The SBOM sits in Annex I, so it arrives with full application on 11 December 2027, not with the reporting duty that has applied since 11 September 2026. That is still the shorter runway of the two for most teams, because a reporting duty needs a process and an SBOM needs a build pipeline that reliably emits one for every release.

“This Regulation shall apply from 11 December 2027. However, Article 14 shall apply from 11 September 2026 and Chapter IV (Articles 35 to 51) shall apply from 11 June 2026.”

The full sequence of dates is on the CRA timeline.

Find out whether any of this binds you. Run the free Cybiq check: five or six questions, a definitive verdict on scope, your conformity route and the obligations that attach to your role, each anchored word-for-word in the Official Journal. For the wider picture, read what the Cyber Resilience Act is. For the defined terms used here, see the glossary.