Annex I, Part II ยท Regulation (EU) 2024/2847

Does the CRA require a software bill of materials (SBOM)?

Verified against the Official Journal text on

Yes. As part of vulnerability handling, manufacturers must identify and document the vulnerabilities and components in their products, 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. The SBOM belongs inside your technical documentation. There is no general duty to publish it: user information only says where to find it if you choose to make it available, and market surveillance authorities can request it. CycloneDX and SPDX are common formats in practice, not named by the regulation.

Basis: Annex I Part II (1), Annex VII (2)(b), Annex II (9)

Judgment call: The scope of the SBOM ("at the very least the top-level dependencies") is a floor, not a ceiling; the Commission may specify the format and elements by implementing act (Art. 13(24)).

The actual requirement Annex I Part II (1), Art. 13(8)

The SBOM duty lives in the vulnerability handling requirements of Annex I, Part II. Point (1) requires manufacturers to identify and document the vulnerabilities and components contained in their products, "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". These requirements are made binding on manufacturers through Article 13(8).

Two things are worth reading precisely. The format must be commonly used and machine-readable. And the coverage floor is the top-level dependencies "at the very least", which means deeper is allowed and often sensible, but the minimum obligation is the top level.

Where the SBOM lives: technical documentation Annex VII (2)(b), Art. 31, Art. 13(24)

The SBOM is not a standalone deliverable floating on its own. Annex VII, which lists the content of the technical documentation, requires the specifications of the vulnerability handling processes to include the software bill of materials, alongside the coordinated vulnerability disclosure policy and the secure-update approach. So the SBOM is one element of the evidence file behind your conformity.

The Commission may, by implementing act, specify the format and elements of the SBOM referred to in Annex I, Part II, point (1). Until and unless it does, the operative standard is simply "commonly used and machine-readable", which is where the common tooling formats come in as practice.

No general duty to publish it Annex II (9), Annex VII (8), Art. 13(25)

This is the point most often overstated. The CRA does not impose a general obligation to publish your SBOM to the world. In the information and instructions to the user (Annex II), the SBOM appears only conditionally: if the manufacturer decides to make the SBOM available to the user, then the user information must say where it can be accessed. The trigger is your own decision to make it available.

Separately, market surveillance authorities can require the SBOM on a reasoned request where it is necessary to check compliance, and ADCO may request SBOMs for a Union-wide dependency assessment. Those are targeted disclosures to authorities, not publication to the public.

Format in practice: CycloneDX and SPDX Annex I Part II (1), Art. 13(24)

Because the regulation says "commonly used and machine-readable" rather than naming a standard, the practical answer is to use one of the formats the industry already treats as standard. CycloneDX and SPDX are the two widely adopted machine-readable SBOM formats, and tooling such as syft can generate them in a CI pipeline. Treat this as good practice that satisfies the wording, not as a legal requirement to use either one specifically.

What you must do

  • Draw up an SBOM in a commonly used, machine-readable format covering at least the top-level dependencies, as part of identifying and documenting components and vulnerabilities. (Annex I Part II (1), Art. 13(8))
  • Include the SBOM in the technical documentation, within the vulnerability handling process description. (Annex VII (2)(b))
  • If you choose to make the SBOM available to users, tell them where to access it; provide it to market surveillance authorities on reasoned request. (Annex II (9), Annex VII (8), Art. 13(25))

Frequently asked

Does the CRA actually name CycloneDX or SPDX?

No. The text requires a "commonly used and machine-readable format" and lets the Commission specify the format later by implementing act. CycloneDX and SPDX are the common formats in practice, which is why they satisfy the wording, but neither is named in the regulation. (Annex I Part II (1), Art. 13(24))

Do I have to publish my SBOM publicly?

There is no general publication duty. You must tell users where to access the SBOM only if you choose to make it available to them, and you must provide it to market surveillance authorities on a reasoned request. Neither of those is publication to the general public. (Annex II (9), Annex VII (8))

How deep must the SBOM go?

The floor is the top-level dependencies of the product, "at the very least". You can and often should go deeper, but the minimum legal obligation is coverage of the top-level dependencies in a machine-readable format. (Annex I Part II (1))

Who can ask to see my full SBOM?

Market surveillance authorities can require it on a reasoned request where necessary to check compliance, and ADCO may request SBOMs from a product category for a Union-wide dependency assessment. These go to authorities, not to the public. (Annex VII (8), Art. 13(25))

An SBOM only matters if you are in scope

The free Vexwatch Scope Checker confirms whether the CRA applies to your product and whether you carry the manufacturer duties, including vulnerability handling and the SBOM, before you invest in tooling.

Check your scope, free See the Blueprint

This page is general information about Regulation (EU) 2024/2847, the EU Cyber Resilience Act. It is compliance tooling, not legal advice, and creates no client relationship. It may not reflect your specific circumstances or the most recent regulatory guidance. Verify conclusions against the regulation or qualified counsel before relying on them.