At a glance
- Annex I Part II(1): SBOM in a commonly used and machine-readable format covering at the very least the top-level dependencies.
- The obligation applies from 11 December 2027. For the reporting obligation in force since 11 September 2026, however, the SBOM is the most important tool.
- The SBOM does not have to be made public. Market surveillance can request it upon a reasoned request.
- An EU implementing act on the format has not yet been adopted. BSI TR-03183-2, a technical guideline from the BSI (Germany’s Federal Office for Information Security), names CycloneDX from 1.6 and SPDX from 3.0.1.
- An SBOM for each product and firmware version makes sense, including the suppliers’ SBOMs.
What the CRA requires
Art. 3(39) defines the 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”.
Annex I Part II(1) requires manufacturers to identify and document vulnerabilities and components contained in their products, 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”. This requirement applies together with the rest of the CRA from 11 December 2027.
Who gets to see the SBOM
- The public: Manufacturers do not have to make the SBOM public (Recital 77). If they make it available to users, they state in the user information where it can be accessed (Annex II(9)).
- Market surveillance: The SBOM is part of the technical documentation. The authority can request it upon a reasoned request if it needs it to check compliance with the requirements of Annex I (Annex VII(8)). In Germany, the BSI will take on this task.
- Dependency assessment: For an EU-wide assessment of dependencies, authorities can ask manufacturers of certain product categories to provide their SBOM (Art. 13(25)).
- Customers: Large buyers increasingly require SBOMs and evidence by contract, independently of the obligation towards authorities.
Formats and minimum content
The Commission can specify the format and elements of the SBOM by implementing act (Art. 13(24)). As of early November 2026, no such act has been adopted. Under EU law, therefore, only “commonly used and machine-readable” applies.
Guidance comes from the BSI Technical Guideline TR-03183-2 (version 2.1.0 of August 2025). It refers to the CRA and requires:
| Item | BSI TR-03183-2 | CRA Annex I |
|---|---|---|
| Format | CycloneDX from version 1.6 or SPDX from version 3.0.1 | commonly used and machine-readable |
| Depth | recursive, up to and including the first component outside your own scope of delivery | at least top-level dependencies |
| Legal nature | national technical guideline, not a legal act | directly applicable regulation |
If you build SBOMs today, CycloneDX or SPDX in a current version with a depth following the BSI guideline is a safe choice. Whether market surveillance or harmonised standards will later adopt the guideline is open.
Stop counting deadlines by hand
Fixradar matches your SBOMs every day, detects actively exploited vulnerabilities and prepares the early warning, notification and final report for the ENISA platform.
Why the SBOM already matters for the reporting obligation
When a vulnerability appears in the catalogue of exploited vulnerabilities, every manufacturer faces the same question: is the affected component in one of my products, in which version, in which firmware version, and at which customers? Without an SBOM, the answer takes days. The early warning has to be out within 24 hours.
That is why building SBOMs pays off before 2027. The SBOM is also the basis for informing users under Art. 14(8) and for VEX statements, with which a manufacturer explains why a vulnerability is not exploitable in its product.
Practice in mechanical engineering
- One SBOM per firmware version: Machines stay in the field for decades. What matters is which version is running at the customer’s site, in addition to the current one.
- Involve suppliers: Controllers, panels and gateways often come from suppliers. Their SBOMs belong in yours, ideally through a fixed request process.
- Generate instead of typing: Build systems such as Yocto generate SBOMs and check reports automatically; tools for CycloneDX and SPDX exist for the common languages.
- Match daily: An SBOM is only as good as the matching against new vulnerabilities. New entries in KEV and EUVD appear every day.
- File the evidence: Which vulnerability was assessed when, with what result? You need this for authorities, customers and your own liability.
Frequently asked questions
From when is the SBOM mandatory under the CRA?
Together with the requirements of Annex I from 11 December 2027. For the reporting obligation, which has applied since 11 September 2026, it is already the most important tool today.
Do I have to publish my SBOM?
No. It is part of the technical documentation. The market surveillance authority can request it upon a reasoned request.
Which format should I use, CycloneDX or SPDX?
Both are commonly used and machine-readable. BSI TR-03183-2 names CycloneDX from version 1.6 and SPDX from version 3.0.1.
Are the top-level dependencies enough?
For the CRA minimum standard, yes. The BSI guideline requires more depth. For a fast assessment of exploited vulnerabilities, a deeper SBOM is considerably more helpful.
Sources
- Regulation (EU) 2024/2847 (Cyber Resilience Act), EUR-Lex
- BSI TR-03183-2: Software Bill of Materials (SBOM), version 2.1.0 (20 August 2025)
- European Commission: Guidance on the application of Regulation (EU) 2024/2847, C(2026) 5252 (27 July 2026)
- BSI: CRA Implementation Act adopted (16 October 2026) (in German)
As of: November 2026. This page reflects the general legal position and is not legal advice for individual cases.