IN SHORT
Manufacturers must draw up a software bill of materials (SBOM) as part of their vulnerability handling: in a commonly used and machine-readable format, covering at least the top-level dependencies of the product (Annex I, Part II, point 1). The SBOM belongs to the technical documentation and must be provided to a market surveillance authority on a reasoned request (Annex VII, point 8). The text does not oblige manufacturers to publish it: recital 77 states that they should not be obliged to make the SBOM public Recital 77
. The Commission may specify its format and elements by implementing acts (Article 13(24)).
What an SBOM is in the CRA
The Regulation 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, point (39)
.
Recital 77 explains the purpose: identifying and documenting components facilitates vulnerability analysis, helps manufacturers and users track newly emerged vulnerabilities, and supports manufacturers in ensuring their products do not contain vulnerable third-party components (Recital 77).
What the text requires
What the text requires
Among the vulnerability handling requirements, 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
.
Four elements are therefore fixed by the text:
- Who: the manufacturer.
- Format: commonly used and machine-readable.
- Minimum depth: at the very least the top-level dependencies.
- Purpose: it is part of identifying and documenting components and vulnerabilities, i.e. of the vulnerability handling process that applies for the whole support period (Article 13(8), first subparagraph).
Where the SBOM sits in the documentation
What the text requires
The technical documentation must include information on the vulnerability handling processes, including the software bill of materials Annex VII, point 2(b)
, the coordinated vulnerability disclosure policy, evidence of the contact address for reporting vulnerabilities and the technical solutions for secure distribution of updates (Annex VII, point 2(b)).
Annex VII also lists, where applicable, the software bill of materials further to a reasoned request from a market surveillance authority, provided that it is necessary for that authority to check compliance with the essential requirements (Annex VII, point 8).
More broadly, manufacturers must provide market surveillance authorities, on a reasoned request, with all the information and documentation necessary to demonstrate conformity (Article 13(22)), and keep the technical documentation for at least ten years after placing on the market or for the support period, whichever is longer (Article 13(13)).
Dependency assessments
The administrative cooperation group of market surveillance authorities (ADCO) may decide to conduct a Union-wide dependency assessment for specific categories of products, in particular on free and open-source components. For that purpose, market surveillance authorities may request manufacturers of those categories to provide the relevant SBOMs; ADCO then receives only anonymised and aggregated information (Article 13(25)).
What the text does not require
Our interpretation
- Publication. No provision requires the SBOM to be made public, and recital 77 says manufacturers should not be obliged to do so. Where a manufacturer decides to make the SBOM available to the user, the information and instructions to the user must say where it can be accessed (Annex II, point 9). In our reading, sharing it with users is therefore a choice, not an obligation.
- A specific format. The text requires a "commonly used and machine-readable format" but does not name one. The Commission may specify the format and elements by implementing acts, taking into account European or international standards and best practices (Article 13(24)).
- Full transitive depth. The minimum is the top-level dependencies. Going deeper is not excluded and may be useful for vulnerability tracking, but the text sets top-level dependencies as the floor.
Uncertain / awaiting guidance
We have not verified whether implementing acts under Article 13(24) on the format and elements of the SBOM have been adopted. If they exist, they may set requirements beyond this page. The meaning of "top-level dependencies" for products combining firmware, applications and remote data processing is also not detailed in the text.
Formats in practice
Good practice (recommendation, not a legal requirement)
Widely used machine-readable SBOM formats include SPDX and CycloneDX. Choosing one of them is a practical way to meet "commonly used and machine-readable", but neither is named in the Regulation, and an implementing act could later specify requirements. Generate the SBOM automatically from the build, version it with each release, and link it to your vulnerability monitoring so that new advisories can be matched against components. These are recommendations, not legal requirements.
Fictional example — Vela Robotics
Vela Robotics (fictional) makes a warehouse robot with Linux-based firmware and a companion app. For each firmware release, its build pipeline produces a machine-readable SBOM listing at least the top-level packages and libraries, stored in the technical documentation with the release. When a market surveillance authority sends a reasoned request, Vela provides the SBOM for the version concerned. Vela decides not to publish the SBOM; its user instructions therefore say nothing about where to access it. When a vulnerability is announced in a library, Vela searches its SBOMs to find affected releases and handles the issue under Annex I, Part II.
What to do next
Check that your build process can produce a machine-readable SBOM covering at least top-level dependencies for every release, and that it is stored with the technical documentation for the required period.