The EU Cyber Resilience Act (CRA, Regulation (EU) 2024/2847) is now in force. Most of its obligations apply from 11 December 2027, but the SBOM and vulnerability-handling requirements apply earlier and are already shaping procurement contracts. If you sell, distribute, or self-host software in the EU — solo dev included — read this once.
Who is in scope
The CRA covers any "product with digital elements" placed on the EU market. In practice that includes:
- Commercial software (SaaS, mobile, desktop, embedded)
- Components and libraries sold or distributed commercially
- Hardware with software components (IoT, routers, anything network-connected)
What is not in scope: pure FOSS released without monetary compensation, internal tools never placed on the market, software developed by a non-commercial body for its own use.
If you charge money for the software in any form — Stripe, App Store, license fee, support contract — you are placing it on the market. CRA applies.
What the SBOM has to contain
The text refers to "machine-readable" formats and explicitly accepts CycloneDX and SPDX. Annex I §2(1) requires the manufacturer to "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 minimum is therefore top-level (direct) dependencies. In practice, every reviewer asks for transitive too — partly because the CRA's vulnerability-handling obligations are impossible to meet without knowing the full graph.
Vulnerability obligations
The CRA also requires:
- An active vulnerability-handling policy: identify, document, address, disclose
- Free security updates for the support period (declared on the product page, minimum 5 years for most categories)
- Notification to ENISA within 24 hours of an actively exploited vulnerability or severe incident
- A Coordinated Vulnerability Disclosure (CVD) policy publicly available
Penalties
| Violation | Maximum fine |
|---|---|
| Non-compliance with essential cybersecurity requirements (Annex I) | €15M or 2.5% of global turnover |
| Non-compliance with other obligations (e.g. SBOM, CVD policy) | €10M or 2% of global turnover |
| Misleading information to authorities | €5M or 1% of global turnover |
For small teams the practical risk is not the fine — it's procurement. Larger customers will refuse to sign without seeing your SBOM and CVD policy.
Minimum viable compliance for a micro-SaaS
- Generate a CycloneDX SBOM at every release. Version it. Store it 10 years.
- Publish a
/.well-known/security.txtwith a contact and disclosure policy. - Track CVEs against your dependencies (OSV.dev is enough; subscribe to the feed).
- Document a vulnerability-handling SOP in your repo. One page is fine.
- Declare a support period on your product page.
Get a CRA-ready SBOM in 30 seconds
DepTriage emits CycloneDX 1.5 with the full transitive graph — exactly what your CRA-conscious customers want to see.
Generate one →FAQ
If you sell or distribute software to EU customers, yes — even with no EU office. The act extends to importers and authorized representatives.
Pure non-commercial FOSS is exempt. Once monetary compensation enters (paid support, dual-license commercial, hosted SaaS), it's in scope. The "open-source software steward" category covers some FOSS foundations under lighter obligations.
No — only to maintain it and make it available to market surveillance authorities and, in practice, to your customers under contract. It does not have to be public.
Most obligations apply from 11 December 2027. Reporting obligations on actively exploited vulnerabilities apply from 11 September 2026. Prepare now.