EU Cyber Resilience Act SBOM requirements: what product makers must do
EU Cyber Resilience Act SBOM obligations are the first horizontal, legally binding SBOM mandate in a major market: any product with digital elements sold in the EU must be backed by a machine-readable software bill of materials as part of its technical documentation. Unlike U.S. federal rules that bind government vendors, the CRA reaches every manufacturer selling into the EU market—hardware, firmware, and standalone software alike.
This guide covers:
- What the CRA regulates and where SBOMs fit in its essential requirements
- Who is in scope (including non-EU companies and open source nuances)
- Exactly what the SBOM obligation says and what depth is expected
- The enforcement timeline and penalty exposure
- A preparation plan that starts paying off before the deadlines
GIF via GIPHY
Related guides:
Key takeaways
- The CRA requires manufacturers to draw up an SBOM in a commonly used, machine-readable format, covering at least the product's top-level dependencies.
- Scope is broad: any product with digital elements placed on the EU market, wherever the maker is headquartered.
- The SBOM lives in your technical documentation—market surveillance authorities can demand it; it is not required to ship to end users.
- Main obligations apply from December 2027, with vulnerability reporting duties starting earlier (September 2026).
- Non-compliance risks fines up to €15 million or 2.5% of global turnover—and blocked market access.
- SecureSlate helps build the vulnerability-handling and documentation processes the CRA expects around the SBOM.
What the Cyber Resilience Act is
The CRA (Regulation (EU) 2024/2847, in force since December 2024) sets essential cybersecurity requirements for products with digital elements: secure-by-default configuration, vulnerability handling, security updates for the support period, and CE marking to attest conformity.
SBOMs appear in the vulnerability-handling requirements (Annex I, Part II): manufacturers must identify and document vulnerabilities and components in their products, including by drawing up an SBOM. The logic mirrors the U.S. rationale—you cannot handle vulnerabilities in components you have not inventoried.
Who is in scope
| Actor | In scope? |
|---|---|
| Hardware makers (routers, IoT, industrial controllers) | Yes |
| Standalone software vendors (including downloaded apps) | Yes |
| Non-EU manufacturers selling into the EU | Yes—the market, not the HQ, determines scope |
| Pure SaaS (remote data processing not tied to a product) | Generally out of scope, unless integral to a product's function |
| Open source developers (non-commercial) | Largely exempt; commercial open source stewards get a lighter regime |
| Importers and distributors | Yes—with duties to verify manufacturer compliance |
Products already covered by sector rules (medical devices, automotive, aviation) are carved out where equivalent requirements exist.
The SBOM requirement in detail
What the regulation and its annexes establish:
- Format: a commonly used, machine-readable format—SPDX and CycloneDX are the practical choices
- Depth: at minimum the top-level dependencies of the product; the European Commission can specify format and elements further via implementing acts
- Location: part of the technical documentation—supplied to market surveillance authorities on request, not necessarily published
- Purpose: supporting the vulnerability handling obligations—identifying affected components when new vulnerabilities emerge, and delivering security updates across the support period (at least 5 years for most products)
Treat "top-level minimum" as a floor, not a target: your own vulnerability-handling duties are far easier with the full transitive tree, and buyers will keep asking for more depth than the legal minimum.
Deadlines and enforcement
| Date | What applies |
|---|---|
| December 2024 | CRA in force; transition period begins |
| September 2026 | Reporting obligations: actively exploited vulnerabilities and severe incidents to ENISA/CSIRTs within 24h (early warning) |
| December 2027 | Full application: essential requirements, SBOM-backed technical documentation, CE marking for new products |
Penalties reach €15M or 2.5% of worldwide annual turnover for essential-requirement breaches—and non-conforming products can be pulled from the market, which for most vendors is the sharper threat.
How to prepare now
- Classify your products against CRA scope, including the "important" and "critical" categories that trigger stricter conformity assessment.
- Automate SBOM generation per release now—the pipeline you need is the standard one; see how to generate an SBOM.
- Stand up vulnerability handling: intake (coordinated disclosure policy), triage SLAs, and a security update mechanism covering the support period.
- Build the technical documentation file structure early, with the SBOM as a living artifact inside it.
- Prepare for the 24-hour reporting clock with an incident process that can classify and notify fast—see our incident recovery plan guide.
- Push SBOM clauses to your own suppliers—your product's SBOM is only as good as component visibility from upstream.
CRA readiness with SecureSlate
SecureSlate helps you run the program behind CRA conformity—vulnerability management with SLAs, documented processes, supplier risk, and evidence—mapped alongside ISO 27001 and SOC 2 so one control library serves every market.
Get started for free · Free readiness score
FAQ: CRA and SBOMs
Must we publish our SBOM under the CRA?
No—the SBOM belongs to technical documentation available to market surveillance authorities on request. Sharing with customers remains a commercial decision (and increasingly a commercial expectation).
Does the CRA apply to software sold before December 2027?
Products placed on the market before full application are generally not retroactively covered, but substantial modifications after that date bring them into scope.
Is a SaaS product with a downloadable agent in scope?
The downloadable component is likely a product with digital elements even where the hosted service is not—many SaaS vendors are partially in scope through agents, CLIs, and SDKs.
Top-level dependencies only—really?
That is the stated minimum pending implementing acts. Full-depth SBOMs remain the practical standard because your own vulnerability handling and customer requests demand them.
How does the CRA interact with NIS2?
NIS2 regulates organizations (their security posture); the CRA regulates products. Vendors selling to NIS2-covered entities will feel both—NIS2 customers pass supply chain requirements downstream.
Disclaimer (legal note)
SecureSlate is not a law firm, and this article does not constitute legal advice or create an attorney-client relationship. Security and compliance obligations vary by industry, contract, and jurisdiction—consult qualified counsel as needed.
Need compliance without the complexity?
SecureSlate automates ISO 27001, SOC 2, GDPR, HIPAA, and more. Built for growing teams. See it in action.
No credit card required
