What does the CRA say about the SBOM, verbatim?
Annex I, Part II sets out the vulnerability handling requirements. Point 1 requires manufacturers to identify and document vulnerabilities and components contained in their products, and names the SBOM for this. Article 3(39) defines it as a formal record containing details and supply chain relationships of components included in the software elements of a product with digital elements.
Recital 77 gives the purpose: “In order to facilitate vulnerability analysis, manufacturers should identify and document components contained in the products with digital elements, including by drawing up an SBOM.” The bill of materials is the tool that tells you which new vulnerability hits which device.
curl -sL -H "Accept: application/xhtml+xml" -H "Accept-Language: eng" \
http:/Output
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 productsWhat does this mean for my SBOM?
| Question | What the Regulation says |
|---|---|
| From when? | From 11 December 2027 (Art. 71(2)). The reporting obligations under Art. 14 have applied since 11 September 2026. |
| For which products? | For every product with digital elements in scope (Art. 2(1)), whether default, class I, class II or critical. The class changes only the procedure, not Annex I. |
| Which format? | A commonly used and machine-readable format. The Commission may specify the format and elements by implementing acts (Art. 13(24)). As of 23 October 2026 it has adopted none. In practice that means CycloneDX and SPDX. |
| How deep? | At the very least the top-level dependencies, meaning everything your product includes directly: RTOS, TLS library, HAL, network stack. |
| Where does it go? | In the technical documentation, with the vulnerability handling processes (Annex VII, point 2(b)). |
| Who gets it? | The market surveillance authority, on a reasoned request (Annex VII, point 8). If the administrative cooperation group (ADCO) decides on a Union wide assessment of the dependence on software components, market surveillance authorities may request the SBOMs of the product categories concerned (Art. 13(25)). You do not have to publish it (Recital 77). |
| And users? | There is no obligation to hand it over. If you make the SBOM available to users, the user information says where it can be accessed (Annex II, point 9). |
| How long to keep it? | With the technical documentation, for at least 10 years after the product is placed on the market or for the support period, whichever is longer (Art. 13(13)). |
| What is the penalty? | For infringements of Annex I, up to EUR 15 million or 2.5 % of worldwide annual turnover, whichever is higher (Art. 64(2)). |
Which duties in Annex I, Part II build on the SBOM?
The bill of materials is the first of eight vulnerability handling requirements. The other seven assume you know what is in the product. Shortened from the legal text:
| Point | Requirement, shortened |
|---|---|
| 2 | Address and remediate vulnerabilities without delay, including by providing security updates, where technically feasible separately from functionality updates. |
| 3 | Apply effective and regular tests and reviews of the security of the product. |
| 4 | Once a security update is available, publicly disclose information about the fixed vulnerabilities, with the affected product, impact, severity and remediation. |
| 5 | Put in place and enforce a policy on coordinated vulnerability disclosure. |
| 6 | Facilitate the sharing of information about vulnerabilities in the product and in the third-party components it contains, including with a contact address. |
| 7 | Distribute updates securely, for security updates automatically where applicable. |
| 8 | Disseminate available security updates without delay and, unless otherwise agreed with a business user, free of charge, with advisory messages for users. |
Must the SBOM name components from suppliers?
For bought-in and open source building blocks, Art. 13 sets two obligations. Manufacturers “shall exercise due diligence when integrating components sourced from third parties so that those components do not compromise the cybersecurity of the product with digital elements” (paragraph 5). When they identify a vulnerability in an integrated component, they report it to the person or entity manufacturing or maintaining the component and remediate it under Annex I, Part II (paragraph 6).
Both assume a bill of materials that names the component with its version. A supplier SBOM does not replace it: it describes what the supplier ships, your SBOM describes what is in your build.
Where do the components for the SBOM come from?
The SBOM is meant to describe what is in the product. For firmware, that is the build that goes onto the device. A list taken from the source code, or a supplier's SBOM, can name libraries the linker did not take over and leave out others that it did.
An example from a public package: the SBOM that ST ships with the STM32CubeF4 v1.28.3 package names none of the five libraries the package ships under Middlewares/Third_Party, among them FreeRTOS and mbedTLS. Whoever links them writes them into their own SBOM.
- 1
Pin down the build
the file that goes onto the device, with version and hash. For microcontrollers the ELF or AXF of the release build, for Linux the shipped image.
- 2
Record the components
every directly included library with name, version and, where one exists, an identifier such as purl or CPE.
- 3
Name the gaps
a component without an evidenced version stays in the SBOM, and the field stays blank.
- 4
Generate it again for each release
every shipped firmware version gets its own SBOM.
What has the Commission adopted on the SBOM so far?
As of 23 October 2026, the Commission has adopted three acts on the basis of the CRA: Delegated Regulation (EU) 2025/1535 (exclusion of L-category vehicles under Regulation (EU) No 168/2013), Implementing Regulation (EU) 2025/2392 (technical description of important and critical products) and Delegated Regulation (EU) 2026/881 (delaying the dissemination of notifications). The fourth line is a resolution of the European Parliament.
None of these acts sets the format or elements of the SBOM. Until the Commission does so, the wording of Annex I, Part II, point 1 is all there is.
curl -s -G https:/Output
"celex","date"
"32025R1535",2025-07-29
"32025R2392",2025-11-28
"32026R0881",2025-12-11
"52026IP0022",2026-01-22Can this run automatically?
LegacyMind reads the components from the file you ship: from Linux images, from ELF and AXF builds for microcontrollers and from supplier SBOMs. Every component with an evidenced version is matched against the vulnerability sources. You export the SBOM as CycloneDX 1.6 or as SPDX 2.3 and 3.0.1 JSON.
Questions
Does every product need an SBOM?
Every product with digital elements in scope of the CRA that is placed on the market from 11 December 2027, whatever its product class. Products covered by their own legal acts are excluded, for example medical devices and in vitro diagnostic medical devices (Art. 2(2)).
Does the SBOM have to be published?
No. Recital 77 says explicitly: “Manufacturers should not be obliged to make the SBOM public.” The market surveillance authority can ask for it on a reasoned request.
Do I have to give the SBOM to my customers?
The Regulation does not require it. If you hand it over, the user information says where it can be accessed (Annex II, point 9).
Are the top-level dependencies enough?
That is the minimum the Regulation sets. Technical Guideline TR-03183-2 of Germany's BSI asks for more, for example every component the linker used.
Does the Commission prescribe an SBOM format?
Not yet. It may specify the format and elements by implementing act (Art. 13(24)). As of 23 October 2026 none has been adopted.
Does the obligation apply to products already on the market?
A product placed on the market before 11 December 2027 is subject to the requirements only if it undergoes a substantial modification after that date (Art. 69(2)). The reporting obligations under Art. 14 apply to all products in scope, including those already on the market (Art. 69(3)).