SBOM under the CRA. The list is the easy part.
Since 11.09.2026, manufacturers report actively exploited vulnerabilities within 24 hours. That only works if you know what is inside your product. This is exactly why the Cyber Resilience Act requires a software bill of materials.
Early warning to ENISA and the CSIRT, mandatory since 11.09.2026
Full application, from then the SBOM requirement in Annex I applies
or 2.5 % of worldwide annual turnover: fine ceiling for breaches of Annex I, Art. 13 and 14
What the CRA says, word for word
Annex I Part II point 1 of Regulation (EU) 2024/2847: 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 SBOM is part of the technical documentation. Market surveillance authorities can request it. The Regulation contains no obligation to publish it.
Who is in scope, and who is not
The duty sits with manufacturers of products with digital elements: hardware with firmware, installable software, apps, components. If you integrate third-party components, you must exercise due diligence, explicitly including free and open-source software (Art. 13(5)).
Pure SaaS is generally outside the CRA, unless it is a remote data processing solution without which a product cannot perform its function. Operators and users have no CRA duty of their own, but feel it through procurement and the NIS2 supply chain. Check scope against the specific product, not the company profile.
Format: what you can rely on today
The Commission may specify the format and elements of the SBOM by implementing act (Art. 13(24)). Until then, BSI TR-03183-2 is the German technical reference. Version 2.1.0 of 20.08.2025 requires CycloneDX 1.6 or later, or SPDX 3.0.1 or later.
The Technical Guideline is not law. If you build to it today, a later EU format will most likely mean adjusting, not starting over.
SBOM, SCA, experts: who does what
The SBOM is the inventory: which component in which version ships in the release. Software composition analysis (SCA) is the tooling behind it. An SCA scanner detects dependencies in code or build, generates the SBOM and matches it against vulnerability and licence data such as OSV or NVD.
A scanner returns findings, often hundreds. The reporting duty turns on different questions: Is the vulnerability actively exploited? Is it reachable in your product at all? What gets fixed first? No tool answers that on its own. Record that assessment in machine-readable form, for example as a VEX statement alongside the SBOM.
What applies since 11.09.2026
Article 14 requires manufacturers to report actively exploited vulnerabilities and severe incidents through the single ENISA reporting platform: early warning within 24 hours, notification within 72 hours, final report no later than 14 days after a corrective measure is available, or within one month for incidents.
This also covers products placed on the market before the cut-off date (Art. 69(3)). Without a current SBOM, the 24-hour window turns into a search through your own code.
Five steps to an SBOM that holds up
1. Clarify products and role: manufacturer, importer or distributor, and which products are in scope.
2. Generate the SBOM automatically in the build for every release, in CycloneDX or SPDX.
3. Match continuously against vulnerability and licence data via SCA, not just once before release.
4. Assess findings, record decisions as VEX, prioritise remediation.
5. Test the reporting path in advance: EU Login, competent CSIRT, platform access, weekend cover.
Where awedit comes in
We read your SBOM and SCA results, experts assess the findings against your product and your reporting duty, and we get your reporting path ready. You sign your own declaration of conformity, and products in class I, II or critical may need a notified body. That step is never ours.
External information security consulting is eligible for funding in some programmes, for example Hamburg Digital Check. The funding body decides on approval.
SBOM FAQ
Do I have to publish my SBOM?
No. The CRA requires you to draw up the SBOM and keep it as part of the technical documentation. Market surveillance authorities can request it. The Regulation contains no publication duty.
Are top-level dependencies enough?
Legally they are the minimum. For vulnerability handling they rarely suffice in practice, because vulnerabilities often sit in transitive dependencies that a top-level list does not show.
When does the SBOM requirement apply?
The Annex I requirements apply with full application from 11.12.2027. The Article 14 reporting duties have applied since 11.09.2026, and in practice they assume you know your components.
Do I need an SCA tool?
The CRA does not prescribe a tool. An SBOM that has to be accurate for every release is hard to maintain without automation in the build, though. An SCA scanner does not replace the expert assessment of its findings.
Does the SBOM requirement cover pure SaaS?
Usually not. The CRA covers products with digital elements and their remote data processing solutions. Pure SaaS without an associated product is generally out of scope. Check it against the specific offering.
Last checked: 20.10.2026
Sources
Orientation, not evidence. This guide is not legal advice.
awedit provides readiness tooling and expert judgment. awedit does not perform reserved examination acts and does not issue certificates or Testate. The C5 Testat (Wirtschaftsprüfer, ISAE 3000 / IDW PS 860), the MDR notified-body certificate, and every other reserved act belong to the licensed examiner the law names. A Self-Check or scan result is orientation, not proof of compliance, and satisfies no legal requirement. awedit is a sumthink brand operated by Die Quadratur UG, Hamburg. No legal advice.