If you sell software in the EU — or sell to anyone who does — the Cyber Resilience Act now applies to you. Not in some hypothetical future. The regulation is in force, the clock is running, and the deadlines that matter are closer than most teams think.
This isn’t a legal primer. It’s a developer’s read on what the CRA requires, when each obligation kicks in, and what you can do now so the December 2027 deadline doesn’t turn into a fire drill.
TL;DR
- In scope: any “product with digital elements” — software, firmware, hardware-with-code, and the remote services they depend on — sold into the EU.
- Three dates: 11 June 2026 (conformity bodies), 11 September 2026 (vulnerability and incident reporting), 11 December 2027 (full application, CE mark, SBOM, the lot).
- Hard reporting clocks from Sep 2026: 24h early warning, 72h full notification, 14d final report on actively exploited vulnerabilities.
- SBOM is mandatory in a machine-readable format (CycloneDX or SPDX), generated from your build, kept for 10 years.
- Fines up to €15M or 2.5% of global annual turnover.
- What to do this quarter: classify your products, stand up an incident process that can move in 24 hours, and start generating SBOMs from CI today.
What the CRA is, in one paragraph
The Cyber Resilience Act is an EU regulation that sets binding cybersecurity requirements for any “product with digital elements” placed on the EU market. That phrase is deliberately broad: it covers software, hardware with software in it, and the remote services those products depend on to function. If your code ends up running on a device or in a service that reaches an EU customer, you’re almost certainly in scope — even if your company isn’t based in Europe.
The core idea is to make manufacturers responsible for security across a product’s whole lifecycle, not just at the moment of sale. That means secure-by-design engineering, a documented vulnerability-handling process, security updates for the product’s expected lifetime, and — the part that matters most for this blog — a machine-readable Software Bill of Materials.
The timeline: three dates that matter
The CRA uses a phased rollout. It entered into force on 10 December 2024, but the obligations land at different times:
- 11 June 2026 — Rules on notifying conformity assessment bodies begin to apply. This is mostly relevant to the certification infrastructure: national authorities can now designate the bodies that will certify higher-risk products.
- 11 September 2026 — Vulnerability and incident reporting obligations begin. From this date, manufacturers must report actively exploited vulnerabilities and severe incidents. This applies even to products already on the market, which is why it bites first for most teams.
- 11 December 2027 — Full application. Every new product placed on the EU market must meet the complete CRA baseline: CE marking, conformity assessment, secure-by-design, the SBOM, the lot.
The reporting obligations are the sharp edge. From September 2026, the clock on an actively exploited vulnerability is strict: a 24-hour early warning to ENISA and the relevant national CSIRT, a 72-hour full notification, and a 14-day final report once a patch is available. Severe incidents follow a similar pattern with a one-month final report. If you don’t already have an incident process that can move at that speed, that’s the first thing to build.
What “in scope” really means
A few points that trip teams up:
It’s not just EU companies. A manufacturer based anywhere is in scope if their product reaches the EU market. Selling through a distributor doesn’t get you out of it — importers and distributors have their own verification duties.
Existing products aren’t automatically exempt. Products placed on the market before December 2027 are subject to the CRA if they undergo a substantial modification after that date — a new version, a feature change that alters the intended purpose, or anything that materially changes the security risk. A long-lived product you keep shipping updates to will eventually cross that line.
Risk class changes the burden. The CRA sorts products with digital elements into tiers. Most fall into the default category and can self-assess. “Important” and “critical” classes — think password managers, network management tools, operating systems, certain industrial components — face stricter conformity assessment, sometimes requiring a third party. Knowing your class early tells you how heavy the process will be.
You must define a support period. The CRA requires manufacturers to declare — and stick to — a period during which they will provide security updates. It has to reflect how long the product is reasonably expected to be in use, and for most products the Commission expects a minimum in the range of five years. The clock on documentation retention runs at least as long.
The penalties are real: non-compliance can trigger fines of up to €15 million or 2.5% of global annual turnover, whichever is higher.
Quick risk-class cheat sheet
| Class | Examples | Conformity route |
|---|---|---|
| Default | Most business apps, games, productivity software | Self-assessment |
| Important — Class I | Password managers, VPNs, network management, identity software | Self-assessment against a harmonised standard, or third-party |
| Important — Class II | Hypervisors, firewalls, intrusion detection, tamper-resistant microprocessors | Third-party conformity assessment |
| Critical | Hardware security modules, smart meter gateways, smartcards in specific contexts | Mandatory European cybersecurity certification |
If you’re not sure which bucket you fall into, assume “important” until you’ve actually mapped your product to the CRA annexes. It’s a cheaper mistake to make than the other way around.
Where the SBOM fits
This is the part the CRA made non-negotiable. The regulation requires manufacturers to produce and maintain a machine-readable Software Bill of Materials — a complete, structured inventory of the components and dependencies in a product.
The reasoning is simple. You can’t manage vulnerabilities in software you can’t see. When the next Log4Shell-scale CVE drops, the question every regulator, customer, and security team will ask is: “Are you affected?” Without an SBOM, answering that means a manual scramble across repos and build systems — exactly the situation the CRA is designed to end.
A compliant SBOM under the CRA needs to be:
- Machine-readable. A PDF list of libraries doesn’t count. The accepted formats are structured standards — primarily CycloneDX and SPDX.
- Accurate and current. It has to reflect what’s actually shipping, which means it can’t be a document someone hand-maintains. It needs to be generated from your build.
- Maintained over the lifecycle. Not a one-time artifact. As dependencies change, the SBOM changes, and you need versioned history to trace what was in any given release.
At a minimum, every component entry should include the data points the US NTIA defined as the baseline and that both CycloneDX and SPDX cover natively:
- Supplier / author of the component
- Component name
- Version
- Unique identifiers (purl, CPE, hash)
- Dependency relationships (what depends on what)
- Author of the SBOM itself
- Timestamp
The CRA also expects you to retain documentation — including the technical records the SBOM is part of — for at least 10 years after placing the product on the market, or for the length of the support period if that’s longer.
What you can do now
Update, October 2026: the reporting obligations have applied since 11 September 2026. Reports go to ENISA’s Single Reporting Platform.
You have until December 2027 for full compliance and until September 2026 for reporting. Here’s the order that makes sense:
- Determine your scope and risk class. Figure out which of your products are in scope and which tier they fall into. This sets the size of everything that follows.
- Stand up a vulnerability-handling process. The September 2026 reporting deadlines are the closest hard requirement. You need defined triggers for “actively exploited vulnerability” and “severe incident,” plus workflows that can hit the 24/72-hour windows. A shared on-call rota, a documented decision tree for “do we report?”, and pre-drafted ENISA / CSIRT contact templates remove most of the friction.
- Start generating SBOMs from your builds — now. This is the foundation for almost everything else: vulnerability tracking, conformity documentation, the records you’ll keep for a decade. Generating them manually doesn’t scale and won’t stay accurate. Wire SBOM generation into CI so every build produces a CycloneDX and SPDX bill of materials automatically. (Generators per ecosystem →)
- Set up continuous CVE monitoring against your SBOMs. A bill of materials is only useful if something is watching it. Match your dependencies against the NVD and OSV databases continuously, so a new critical CVE in your stack surfaces in minutes — well inside the reporting window — rather than when a customer emails you. (Vulnerability monitoring docs →)
- Update supplier contracts. Your own compliance depends on your suppliers’. Bake CRA obligations into due diligence, and prioritize suppliers of critical components. Ask for their SBOMs, their support periods, and their disclosure process — in writing.
- Declare your support period publicly. Pick a duration, document the reasoning, and publish it. Buyers and regulators both look for it, and committing to a number forces the internal conversation about how long you’ll really patch a product.
A 90-day starter plan
If you’re starting from zero, this is a realistic first quarter:
- Weeks 1–2: Inventory your products, draft scope and risk-class assessments, identify the responsible owner per product.
- Weeks 3–6: Add SBOM generation to CI for every product. Pick CycloneDX and SPDX, store every artifact, tag it to a release.
- Weeks 5–8: Stand up continuous CVE scanning against those SBOMs and triage the initial backlog.
- Weeks 7–10: Write the vulnerability handling and incident response playbook. Dry-run a 24-hour ENISA report.
- Weeks 10–12: Update supplier contracts and customer-facing security documentation. Lock in your support period.
None of this requires a heroic effort. It does require starting.
The boring version of compliance
Here’s the thing nobody says about the CRA: most of it is good engineering you should be doing anyway. Knowing what’s in your software. Watching for known vulnerabilities. Shipping patches. Keeping records. The regulation just makes it mandatory and puts a date on it.
The teams that struggle in 2027 won’t be the ones who did anything heroic. They’ll be the ones who treated the SBOM as a last-minute export and the vulnerability process as a fire drill. The teams that are fine will be the ones for whom this all runs quietly in the background — SBOMs generated on every build, CVEs tracked continuously, documentation accumulating automatically.
That’s the part boring.tools takes care of: your CI uploads the CycloneDX or SPDX SBOM, every component is matched against OSV continuously, and every triage decision is kept per release, ready to export as OpenVEX when a customer asks. When a vulnerability in your product is actively exploited, it opens a reporting case and keeps the 24-hour, 72-hour and 14-day clocks. You can try it for 14 days, no credit card needed.
This article is for general information, not legal advice. The official CRA text is the authoritative reference for compliance decisions.