The Cyber Resilience Act SBOM obligation requires manufacturers of products with digital elements sold in the EU to draw up a software bill of materials in a commonly used, machine-readable format, covering at the very least the top-level dependencies of the product. It is part of Regulation (EU) 2024/2847, which entered into force on 10 December 2024, with the main obligations applying from 11 December 2027. If you ship software, firmware, or connected hardware into the European market, this is now a legal requirement with real penalties attached — not a voluntary best practice.
Who does the Cyber Resilience Act apply to?
The CRA covers "products with digital elements": software and hardware products, and their remote data processing solutions, made available on the EU market. That includes desktop applications, mobile apps, embedded firmware, IoT devices, operating systems, and most commercial SaaS components that qualify as remote data processing for a product. The obligations fall primarily on manufacturers, but importers and distributors carry duties too — they must verify that the products they bring to market meet the regulation's essential requirements.
There are carve-outs. Open-source software developed outside a commercial activity is exempt, and the regulation introduces a lighter "open-source software steward" regime for foundations and companies that support open-source projects without monetizing them as products. Sectors already covered by equivalent rules — medical devices, motor vehicles, civil aviation — are excluded to avoid double regulation. Everyone else selling into the EU, regardless of where the company is headquartered, is in scope.
What does the Cyber Resilience Act SBOM requirement actually say?
Annex I of the regulation lists the essential cybersecurity requirements, and the vulnerability handling section is where the SBOM lives. Manufacturers must "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."
Three details matter in that sentence. First, "machine-readable" rules out PDF component lists; in practice this means CycloneDX or SPDX. Second, "top-level dependencies" is the legal floor, not the ceiling — market surveillance authorities can request the SBOM, and a top-level-only document will not support the vulnerability handling duties that sit next to it in Annex I, because most exploitable CVEs arrive through transitive dependencies. Third, the SBOM is not required to be published; it must exist, be maintained, and be producible on request. The technical documentation you submit for conformity assessment must describe how you meet the requirement.
The Cyber Resilience Act SBOM duty also connects to ongoing obligations: manufacturers must handle vulnerabilities for the expected product lifetime (with a five-year default support period), apply due diligence when integrating third-party components, and remediate without delay when a component vulnerability affects the product.
When do the CRA deadlines hit?
The regulation entered into force on 10 December 2024, and the obligations phase in:
- 11 September 2026 — reporting obligations begin. Manufacturers must notify actively exploited vulnerabilities and severe incidents to their CSIRT and ENISA within 24 hours of awareness, with a fuller report at 72 hours.
- 11 December 2027 — the main obligations apply, including the essential requirements in Annex I, the SBOM duty, conformity assessment, and CE marking for products with digital elements.
That 2027 date sounds distant, but conformity assessment has lead time: you need the SBOM pipeline, the vulnerability handling process, the coordinated disclosure policy, and the technical documentation working well before you sign the declaration of conformity. Products placed on the market before the deadline are only caught when they are substantially modified afterwards — but any product still shipping updates in 2028 will almost certainly cross that line.
What are the penalties for non-compliance?
Non-compliance with the essential requirements — the tier the SBOM sits in — carries administrative fines of up to 15 million euros or 2.5 percent of worldwide annual turnover, whichever is higher. Lesser breaches of other obligations top out at 10 million euros or 2 percent, and supplying misleading information to authorities at 5 million euros or 1 percent. Market surveillance authorities can also order corrective action, restrict availability, or force a product withdrawal from the EU market entirely, which for most vendors is the more frightening outcome than the fine.
How should engineering teams prepare for CRA SBOM compliance?
Treat this as a pipeline problem, not a paperwork problem. A Cyber Resilience Act SBOM program that satisfies both assessors and your own vulnerability handling duties looks like:
- Generate SBOMs automatically at build time. A software composition analysis tool that emits CycloneDX or SPDX on every release removes the "drawing up" burden entirely. Safeguard's SCA product does this per build and keeps historical SBOMs queryable, which is exactly the shape of evidence a market surveillance request calls for.
- Go deeper than top-level. Capture the full transitive graph. The legal minimum will not power the vulnerability monitoring duty that accompanies it.
- Wire SBOMs to vulnerability handling. The regulation expects you to identify vulnerabilities in components on an ongoing basis. That means continuous matching of your SBOM against advisory feeds, with an owner and an SLA when something fires.
- Stand up the reporting path early. The 24-hour ENISA notification window arrives in September 2026, more than a year before the SBOM duty. Know who files the report at 2 a.m.
- Fold it into existing compliance work. If you already produce SBOMs for US federal customers under Executive Order 14028 or align to NIST SSDF, the CRA is an extension of that work, not a new program. Map the overlap once and maintain one pipeline.
For a broader look at how SBOM requirements are converging across jurisdictions, the Safeguard Academy covers CycloneDX and SPDX formats in depth.
FAQ
Does the Cyber Resilience Act require me to publish my SBOM?
No. The regulation requires you to create and maintain an SBOM in a machine-readable format and include it in your technical documentation. Market surveillance authorities can request it, but there is no obligation to make it public. Some manufacturers choose to publish SBOMs anyway as a trust signal.
Are transitive dependencies required in a CRA SBOM?
The legal minimum is "at the very least the top-level dependencies." However, the adjacent vulnerability identification duty is difficult to satisfy without the full dependency graph, since the majority of real-world component vulnerabilities are transitive. Most compliance teams standardize on complete SBOMs.
Does the CRA apply to open-source software?
Open-source software developed or supplied outside a commercial activity is out of scope. Once open source is monetized as part of a commercial product, the manufacturer integrating it takes on the obligations — including due diligence on those components. Non-profit stewards of open-source projects get a lighter, dedicated regime.
What SBOM format should I use for CRA compliance?
The regulation says "commonly used and machine-readable" without naming formats. CycloneDX and SPDX are the two formats that clearly qualify, both are supported by mainstream tooling, and the European Commission may specify formats further in implementing acts. Pick one, generate it automatically, and keep versions per release.