SBOM requirements in the CRA

The Cyber Resilience Act (CRA) makes the SBOM a legal requirement for manufacturers of products with digital elements. The requirement applies from 11 December 2027. Cyber Resilience Act (CRA) gives an overview of the regulation as a whole.

What the regulation saysCopy Anchor Link

The requirement is in Annex I, Part II, point 1. Manufacturers shall:

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

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.

Four things follow from the text:

• An SBOM is mandatory. Every product in scope needs one.
• The format must be commonly used and machine-readable. The regulation names no format. CycloneDX and SPDX are the two in general use.
• Top-level dependencies are the minimum. The SBOM must cover at least the components the product depends on directly.
• The SBOM is part of vulnerability handling. It sits in the same point as the duty to identify and document vulnerabilities, which is the purpose it serves.

Who gets to see the SBOMCopy Anchor Link

Manufacturers do not have to publish the SBOM. It is part of the technical documentation (Annex VII), and a market surveillance authority can ask for it with a reasoned request when it needs the SBOM to check compliance.

A manufacturer may choose to make the SBOM available to users. In that case the user information must say where it can be accessed (Annex II).

Customers can still ask for an SBOM in a contract. That is a matter between supplier and customer, and it is common in public procurement.

What the regulation leaves openCopy Anchor Link

The CRA does not specify which data fields an SBOM must contain. The Commission may adopt implementing acts that specify the format and elements of the SBOM (Article 13(24)).

Until then, two documents are the usual reference points:

• BSI TR-03183-2. The German Federal Office for Information Security has published a technical guideline that specifies the content and format of an SBOM for CRA purposes.
• SBOM Minimum Elements. The baseline from NTIA in the United States. CISA published a draft update in 2025.

Is top-level enough?Copy Anchor Link

Top-level dependencies are the legal minimum. In practice they rarely cover the other obligations.

Manufacturers must handle vulnerabilities in the product including its components (Article 13(8)), and must report an actively exploited vulnerability within 24 hours of becoming aware of it. A vulnerability in a transitive dependency affects the product just as much as one in a direct dependency. Log4j was included in many products as a transitive dependency, through other libraries. An SBOM that stops at the top level cannot answer whether a product is affected.

A complete SBOM generated in the build, with transitive dependencies, is therefore the practical choice. Different types of SBOMs explains the difference between SBOMs created from source, at build time and from a running system.

Related obligations where the SBOM is usedCopy Anchor Link

• Due diligence on third-party components (Article 13(5)). Manufacturers must make sure that components from third parties do not compromise the security of the product. This includes open source. An SBOM from the supplier shows what a delivered component contains.
• Reporting upstream (Article 13(6)). A manufacturer that finds a vulnerability in a component must report it to whoever maintains the component.
• Support period. Vulnerabilities must be handled for at least five years. The SBOM for each released version has to be kept for as long as that version is supported.
• Information to users. Fixed vulnerabilities must be disclosed, with information that lets users identify the affected product. VEX is a format for stating whether a product is affected by a specific vulnerability.

Preparing before December 2027Copy Anchor Link

1. Generate an SBOM in every build, in CycloneDX or SPDX, and store it with the release. How to create an SBOM lists tools.
2. Check the quality of the SBOM: component names, versions, unique identifiers and dependency relationships. Why SBOM quality matters describes common gaps.
3. Monitor the SBOM of every supported release against new vulnerabilities, not only the latest release.
4. Ask suppliers for SBOMs for the components and products you build on, and agree on how they are delivered.
5. Decide who may receive your SBOMs and how: authorities on request, and customers if you choose to share.

ToolsCopy Anchor Link

Any tool that handles CycloneDX or SPDX can be used. Two from Bytesafe, which runs this site:

• SBOM Observer stores the SBOM for each release and monitors it against vulnerability data.
• Trust Repository collects SBOMs, VEX and support dates from suppliers and publishes your own to customers.

VideoCopy Anchor Link

A conversation between Anthony Harrison and Olle E. Johansson from SBOM Europe, published in January 2026, on what type of SBOM the CRA requires (in English, 20 minutes).