Most teams think of the Cyber Resilience Act as a 2027 problem. It isn’t. The CRA doesn’t have one compliance date, it has a staged timeline with three binding milestones between 2024 and 2027, and the one that matters most right now lands in about five weeks. Get the timeline wrong and you either start compliance work too late or waste months preparing for the wrong deadline first. Here’s the full Cyber Resilience Act timeline, what’s already in force, what’s coming, and where to focus if you build or distribute products with digital elements in the EU.
Cyber Resilience Act Timeline
| Date | Milestone | What it actually requires |
|---|---|---|
| 10 Dec 2024 | CRA enters into force | No direct technical obligations yet, but any product designed from this point will be judged against CRA requirements when it reaches the market. |
| 2025 to mid-2026 | Implementing and delegated acts, harmonized standards (CEN/CENELEC/ETSI) | Technical specifications, SBOM format guidance, and vulnerability-handling standards take shape. The Commission adopted Implementing Regulation (EU) 2025/2392 on 28 Nov 2025 and published a CRA implementation Q&A in Dec 2025. |
| 11 Jun 2026 | Conformity assessment body framework applies | Member states begin designating and notifying the bodies that will carry out third-party audits for Class I and Class II products. |
| 27 Jul 2026 | Commission publishes practical implementation guidance | Working document to help manufacturers of all sizes interpret their obligations ahead of the September deadline. |
| 11 Sept 2026 | Article 14 reporting obligations apply | Manufacturers must report actively exploited vulnerabilities and severe incidents to ENISA and their national CSIRT, on a 24-hour / 72-hour / 14-day staged timeline. Applies to products already on the market, not just new ones. |
| 11 Dec 2027 | Full application of the CRA | Essential cybersecurity requirements, technical documentation, conformity assessment, and CE marking become mandatory for all in-scope products placed on the EU market. |
Three of those rows are the ones that actually bind you: 10 December 2024 (entry into force, design-stage relevance), 11 September 2026 (reporting obligations, the one closing in now), and 11 December 2027 (full application). The other rows exist to get the infrastructure ready for those three.
Why 11 September 2026 is the deadline to build around first
It’s tempting to treat 2027 as the real deadline and 2026 as a warm-up. That’s backwards, and it’s the mistake we spent a full session unpacking with Jesus Cuadrado (CEO, Xygeni) and Nariman Aga-Tagiyev (Founder, SecureHabits) in 24 Hours to Report: Surviving the CRA’s Notification Clock.
Article 14’s reporting obligation is the first CRA requirement with real operational teeth, and it applies from 11 September 2026 to every in-scope product already on the EU market, whether you shipped it last quarter or five years ago. There’s no grandfather clause for old products once this date arrives. The moment you become aware that a vulnerability in your product is being actively exploited, or that you have a severe security incident, the clock starts:
- 24 hours for an early warning to ENISA and your national CSIRT
- 72 hours for a full notification
- 14 days for a final report (or one month for severe incidents not tied to a single exploited vulnerability)
Penalties for the most serious breaches run up to €15 million or 2.5% of global annual turnover, whichever is higher.
“If you become aware of an active exploit, you have to act, even if it’s a product you shipped ten years ago. There’s no ‘it’s an old product’ exception in this law.” Nariman Aga-Tagiyev, Founder, SecureHabits (adapted from the recording for clarity)
What “becoming aware” actually looks like in practice
The part of the timeline most teams underestimate isn’t the deadline itself; it’s the chain of events that has to happen before the clock even starts. A finding in your SCA or SAST tool is not, by itself, a reportable incident. The path looks like this:
- A concern comes in. A CVE advisory, a bug bounty report, a pen test finding, a scanner alert, a direct disclosure.
- You investigate it, prioritized by severity. Is it in production or just in test? Is there a known exploit? Does your code actually reach the vulnerable function?
- You confirm (or rule out) active exploitation. Only once you’ve confirmed real-world exploitation against you or your customers does this become an incident.
- The clock starts. From confirmation, you have 24 hours for the early warning.
Skip straight from “we found something” to “we’re reporting it” and you’ll flood ENISA with noise. Wait too long to investigate and you’ll blow the 24-hour window on something you should have caught in hour one.
“Without the right tooling in place beforehand, good luck figuring out which product versions are affected within three or four hours.” Nariman Aga-Tagiyev, Founder, SecureHabits (adapted from the recording for clarity).
What needs to be built before September, not during it
Three things determine whether your team can actually hit the 24-hour window when it matters:
- A current, queryable SBOM. You need to know in minutes, not days, exactly which product versions contain a given component, and whether it arrived as a direct or transitive dependency. Generating your first real SBOM after the clock has started is how a 24-hour deadline turns into a missed one.
- Triage that separates real risk from volume. Most organizations carry thousands of open SCA findings at any given time. The CRA doesn’t require you to close all of them, it requires you to act fast on the ones that are reachable in your code, exploitable in the wild, and actually running in production.
- A notification path that doesn’t rely on someone checking a dashboard. The instant a finding crosses from “vulnerability” to “actively exploited,” the right person needs to know, automatically.
The session walks through this end to end on a live platform: configuring a product across multiple repositories, comparing SBOMs release over release, the prioritization funnel that turns thousands of findings into the handful that are reachable and exploitable, and the incident status workflow (open → investigating → confirmed → resolved) that produces the audit trail regulators, and your own legal team, will eventually ask for.
How Xygeni fits into the Cyber Resilience Act Timeline
None of this works without knowing, at the moment a vulnerability turns into a confirmed incident, whether it’s actually reachable in your code and whether a fix exists that won’t break anything downstream. That’s the layer Xygeni’s ASPM platform sits on: it ingests findings from your SCA, SAST, secrets, and IaC scans (plus third-party tools you already run), maps them against how your application actually executes, and tells you which ones are real risk versus noise, before your team burns hours doing that triage by hand.
“The vulnerability lives in a specific function of the component. We check whether your application’s code actually reaches that function. If it doesn’t, the vulnerability isn’t reached, and nobody can exploit it to attack your application. And when it does affect you, in most cases we can fix it automatically, right from the platform.” Jesus Cuadrado, CEO, Xygeni
That’s the mechanic that turns “we have thousands of open findings” into “we have sixteen that matter,” and it’s the same reachability and remediation logic that has to sit underneath any CRA notification workflow. Teams that want to try this before the September deadline can start on Xygeni’s free Developer tier, no cost, up to 25 repositories, no reason to wait until the clock is already running to see where they stand.
The Cyber Resilience Act timeline doesn’t leave room for a 2027 mindset. September 11, 2026 is the deadline that will actually test whether your incident response works, and it’s roughly five weeks away.
FAQ
What is the Cyber Resilience Act timeline?
The CRA has three binding milestones: entry into force on 10 December 2024, Article 14 vulnerability and incident reporting obligations from 11 September 2026, and full application, including conformity assessment and CE marking, from 11 December 2027. A related milestone, the conformity assessment body framework, applies from 11 June 2026.
What happens on 11 September 2026?
Manufacturers of products with digital elements sold in the EU must start reporting actively exploited vulnerabilities and severe incidents to ENISA and their national CSIRT, on a 24-hour early warning, 72-hour notification, and 14-day (or one-month) final report timeline.
Does the reporting obligationn apply to products already on the market?
Yes. Unlike the CRA’s full application in 2027, the September 2026 reporting obligation applies to any in-scope product already available on the EU market, not only new launches.
What is the final Cyber Resilience Act deadline?
11 December 2027. From that date, the CRA’s essential cybersecurity requirements, technical documentation, conformity assessment, and CE marking obligations apply in full to in-scope products placed on the EU market.
What’s the difference between the June 2026 and September 2026 dates?
11 June 2026 is when the legal framework for notifying and designating conformity assessment bodies (the auditors for Class I and II products) takes effect, an operational milestone for regulators and notified bodies. 11 September 2026 is when manufacturers themselves gain a binding reporting obligation.
What are the penalties for missing a CRA deadline?
Fines for the most serious breaches can reach €15 million or 2.5% of global annual turnover, whichever is higher, with lower penalty tiers for other types of non-compliance.
Watch the full session, “24 Hours to Report: Surviving the CRA’s Notification Clock,” with Jesus Cuadrado (Xygeni) and Nariman Aga-Tagiyev (SecureHabits), for the complete live walkthrough of the incident response workflow ahead of the 11 September 2026 deadline!
