A CRA SBOM is a compliance artifact tied to component and vulnerability management. It should be versioned with the product, machine readable and sufficient to show at least top-level dependencies. It also needs to connect to the technical documentation and vulnerability-handling process rather than being generated once and then left stale.
The CRA Defines Software Bill of Materials
Article 3 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. The definition makes clear that an SBOM is more than a list of package names because supply-chain relationships between components are part of the concept.
Annex I Makes SBOM Creation an Explicit Requirement
Annex I Part II point 1 requires manufacturers to identify and document vulnerabilities and components contained in the product, including by drawing up an SBOM. The requirement sits within the CRA vulnerability-handling requirements, which means the SBOM should support the manufacturer's ability to detect, assess and remediate component vulnerabilities.
The SBOM Must Be Commonly Used and Machine Readable
The CRA requires the SBOM to use a commonly used and machine-readable format. The Regulation does not itself name one mandatory format in Annex I. Article 13(24) gives the Commission power to specify SBOM format and elements by implementing act, so manufacturers should monitor future implementing rules.
Top-Level Dependencies Are the Express Minimum
Annex I says the SBOM must cover at least the top-level dependencies of the product. Manufacturers should distinguish this legal minimum from the deeper dependency information they may need for effective vulnerability management. A vulnerability several layers down the dependency graph can still affect the finished product.
The SBOM Should Be Versioned With Product Releases
A useful CRA SBOM should be associated with the product release to which it applies. Dependencies change over time, and an unversioned inventory can make it difficult to determine which supported product versions contain a vulnerable package. Release-linked SBOMs support impact analysis and remediation decisions.
Annex VII Connects the SBOM to Technical Documentation
Annex VII requires information and specifications about vulnerability-handling processes, including the SBOM. It also requires architecture information explaining how software components build on or feed into each other and integrate into the overall processing. The SBOM should therefore be managed as part of the technical evidence set, not as a separate compliance export with no lifecycle owner.
Public Disclosure Is Not the Same as Drawing Up the SBOM
The CRA requires manufacturers to draw up the SBOM, but Annex II says that if the manufacturer decides to make the SBOM available to the user, the user information must explain where it can be accessed. This wording does not create a general requirement to publish the full SBOM to every user.
Market Surveillance Authorities Can Request SBOM Information
Annex VII provides for the SBOM to be supplied, where applicable, following a reasoned request from a market surveillance authority where it is necessary to check compliance with Annex I. Article 13 also allows SBOM requests for specified Union-wide dependency assessments. Manufacturers therefore need an SBOM they can retrieve and explain to authorities.
An SBOM Is Not a Substitute for Vulnerability Management
An SBOM records components and their relationships, but it does not by itself establish whether a vulnerability is exploitable, whether a component is actually reachable in the product or what remediation is appropriate. Manufacturers need to connect SBOM data to vulnerability intelligence, product context, risk assessment, remediation and security-update workflows.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.