CRA and SBOMs: what the Act requires and what it does not

The legal statements below were checked on 21 October 2026 against the Official Journal text of Regulation (EU) 2024/2847 and its corrigenda; none of the corrigenda changes the English text of the provisions cited here. This page is information, not legal advice.

An SBOM file is a start. What does it actually tell you?

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" (Annex I, Part II, point 1). Article 13(8) requires vulnerabilities to be handled in accordance with Annex I, Part II when the product is placed on the market and for the support period.

The Act defines a software bill of materials as "a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements" (Article 3(39)). An SBOM is therefore more than a list of library names. The definition includes the supply chain relationships between components.

A file full of component names can look reassuring. But what must the manufacturer produce, and where does it belong in the technical documentation? Who may need access? Those are separate questions, with different legal references.

The reading used in this guide is that a useful inventory does not, by itself, show that every cybersecurity requirement in Annex I has been met. Article 31(1) asks the technical documentation to cover all of them.

A format requirement, without a named format

The Act does set characteristics of the SBOM format: it must be commonly used and machine-readable (Annex I, Part II, point 1). So saying there is "no format requirement" would be inaccurate.

The Regulation does not name a mandatory SBOM standard, schema or schema version. It does not say that any particular named format satisfies every CRA requirement. Nor should the absence of a named format be read as permission to use a document that cannot be processed by machines.

Article 13(24) allows the Commission to specify the format and elements of the SBOM by implementing acts, taking into account European or international standards and best practices. The legal review for this guide found no such implementing act in the Official Journal on 21 October 2026. Check again before selecting a format.

For the working process, choose a format your engineering tools can generate and your security team can inspect. Export a file and try it in the tools that will receive it. Record missing fields and unsupported relationships. A successful export does not tell you what was left out.

What "at the very least the top-level dependencies" means

The statutory wording sets a minimum: "at the very least the top-level dependencies" (Annex I, Part II, point 1). That point should not be rewritten as an express requirement to list every indirect dependency at unlimited depth.

That minimum is also not an exemption from the other vulnerability-handling duties. Annex I, Part II, points 2 to 8 cover remediation, testing, disclosure of fixed vulnerabilities, coordinated vulnerability disclosure, information sharing and the distribution of updates.

For a practical starting point, take the components directly included by the product. Then look at the gaps. Is embedded software covered? What about bundled components, generated artefacts and third-party packages? Record why each component is included or excluded. Go beyond the minimum where it helps the team investigate the actual product risks.

Use a concrete product or build identifier in your internal records. Keep the input, generation date and known coverage limits with the file. These are workflow recommendations, not a claim that the Act mandates this exact set of SBOM fields.

The SBOM in the technical documentation

Before placing the product on the market, manufacturers must draw up the technical documentation referred to in Article 31 and carry out the chosen conformity assessment procedure (Article 13(12)). Article 31(1) requires that documentation to contain all relevant data or details of the means used to ensure compliance of the product and the manufacturer's processes with Annex I. At least the elements set out in Annex VII must be included.

Annex VII, point 2(b) expressly lists the SBOM. The technical documentation must contain the "necessary information and specifications of the vulnerability handling processes put in place by the manufacturer, including the software bill of materials", together with the coordinated vulnerability disclosure policy, evidence of a contact address for reporting vulnerabilities and a description of the technical solutions for the secure distribution of updates.

Annex VII, point 8 separately mentions the SBOM "where applicable" in connection with a reasoned request from a market surveillance authority (see below). Annex VII does not prescribe a file layout. The technical documentation must be kept at the disposal of market surveillance authorities for at least 10 years after the product is placed on the market or for the support period, whichever is longer (Article 13(13)).

Make the inventory traceable from the documentation. Describe how it is generated and reviewed, and how the team uses it during vulnerability handling. That is a workflow recommendation. A file sitting in a folder is hard to use if nobody can tell which product it describes.

No general public publication obligation

The legal review for this guide found no provision requiring the SBOM to be published for everyone to download. Annex II, point 9 covers the case where "the manufacturer decides to make available the software bill of materials to the user": the user information must then say where it can be accessed.

Do not confuse this with a separate duty. Once a security update is available, manufacturers must share and publicly disclose information about fixed vulnerabilities, subject to a possible delay in duly justified cases (Annex I, Part II, point 4).

Public availability and access by an authority are different matters:

• Upon a reasoned request, manufacturers must give a market surveillance authority all the information and documentation necessary to demonstrate conformity with Annex I (Article 13(22)).
• Annex VII, point 8 refers to the SBOM "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".
• For a Union-wide dependency assessment decided by ADCO, market surveillance authorities may request manufacturers of specific product categories to provide the relevant SBOMs (Article 13(25)).

Keeping an SBOM private does not remove these authority-facing duties. Equally, publishing it does not replace the wider technical documentation or vulnerability-handling requirements.

Common myths

Use the inventory when a vulnerability notice arrives

The useful question is what the inventory lets the team investigate. As a workflow recommendation, treat the SBOM as an input to that investigation. When a vulnerability notice arrives, identify the relevant component. Compare it with the shipped product inventory. Check whether the affected component is present and whether the reported issue applies to its use in that product. Record the evidence and the decision.

A component match gives the team something to check. It is too early for a final conclusion. Record what is known and what remains uncertain. Give the next action an owner, and keep the assessment connected to any correction, mitigation and user communication. This is a suggested workflow; the legal tests still have to be applied.

An SBOM does not itself determine whether Article 14 reporting is triggered. Article 14 covers actively exploited vulnerabilities (Article 14(1); Article 3(42)) and severe incidents having an impact on the security of the product (Article 14(3), (5)), each with its own deadlines. See the Article 14 reporting guide and the software bill of materials glossary entry.

Sources

• Regulation (EU) 2024/2847 (opens in a new tab), Official Journal text (Publications Office): Article 3(39), (42); Article 13(8), (12), (13), (22), (24), (25); Article 14(1), (3), (5); Article 31(1); Annex I, Part II, points 1 to 8; Annex II, point 9; Annex VII, points 2(b) and 8.
• Corrigendum OJ L 2025/90555 (opens in a new tab) of 2 July 2025: in the English text it corrects only Article 64(10); it does not change the provisions cited above. The same holds for OJ L 2024/90780 (title) and OJ L 2025/90828 (Article 67).
• European Commission: Cyber Resilience Act — Reporting obligations (opens in a new tab) (read 21 October 2026): background for the separate reporting assessment.

For the separate timing question, use the crAcken reporting deadline calculator.