Most of the CRA doesn't bite until December 2027. The reporting obligation is different — it's the first part with operational teeth, it lands in September 2026, and it runs on a clock measured in hours. If you make a product with digital elements sold in the EU, this is the obligation to understand first.
What the CRA actually requires
Article 14 of the Cyber Resilience Act requires a manufacturer to notify two kinds of event: an actively exploited vulnerability in one of its products, and a severe incident having an impact on the security of one of its products. These are separate streams with their own triggers, and both run to the same headline cadence: an early warning, a fuller notification, and a final report.
The obligation applies from 11 September 2026, and it reaches back — it covers products already placed on the EU market, not just ones you ship after that date. This is worth sitting with: it means your existing, shipped portfolio is in scope on day one.
The 24 / 72 / 14 timeline, stage by stage
The numbers refer to three deadlines that begin the moment you become aware of a reportable event.
| Stage | Deadline | What you submit |
|---|---|---|
| Early warning | 24 hours | That you are aware of an actively exploited vulnerability or a severe incident. Minimal detail; the point is to start the conversation, not to have all the answers. |
| Notification | 72 hours | A fuller account: the nature of the issue, an initial assessment, and any corrective or mitigating measures taken or planned. |
| Final report | 14 days * | A complete description, root cause, and the measures applied. For an actively exploited vulnerability, within 14 days of a corrective measure becoming available. |
* The final-report clock differs by stream — see the two streams below.
The 24-hour figure is the one that reshapes how you operate. It doesn't pause for a weekend, a public holiday, or the fact that the person who understands the affected component is on leave. A clock that starts on a Friday evening is due Saturday evening.
When does the clock start?
The clock starts when you become aware — and awareness is doing a lot of work in that sentence. For the vulnerability stream, the trigger is awareness that a vulnerability in your product is being actively exploited. That word has a specific meaning: there is reliable evidence that a malicious actor has exploited the vulnerability in a system, without the owner's authorisation.
The distinction that catches teams out is between exploitation and mere existence. A newly published CVE is not, on its own, an actively exploited vulnerability. A public proof-of-concept is not either. A listing in the CISA Known Exploited Vulnerabilities (KEV) catalogue, or comparable threat intelligence, is a strong signal that the bar has been crossed. Wiring that signal to a timer — so the moment a component in one of your products crosses into active exploitation, a clock starts — is the piece that almost nobody has built.
The 24-hour clock is only half-solvable by tools. Detecting the trigger automates. Deciding whether your product is actually affected has stayed a human task.
Where the report goes: the ENISA Single Reporting Platform
You report once, through the ENISA Single Reporting Platform (SRP). The notification is routed to the CSIRT designated as coordinator in the member state where you have your main establishment, and made available to ENISA at the same time. The "report once" design is deliberate — it spares manufacturers from filing the same event with multiple national authorities.
The SRP is not yet live, and exposes no API. With the deadline approaching, the sensible posture is to prepare structured, SRP-aligned reports and run dry-run exercises now, so that when the platform opens you are filing a finished report rather than drafting one against the clock.
The two streams: vulnerability vs. severe incident
The 24 and 72-hour steps are shared. The final report is where the two streams diverge:
| Actively exploited vulnerability | Severe incident | |
|---|---|---|
| Trigger | Reliable evidence of exploitation in the wild | An incident with an impact on the product's security |
| Early warning | 24 h | 24 h |
| Notification | 72 h | 72 h |
| Final report | within 14 days of a corrective measure being available | within 1 month of the 72-hour notification |
Keep the streams separate in your process. They start on different signals, and mixing them up is how a severe-incident final report ends up filed against a vulnerability deadline, or vice versa.
The real bottleneck isn't the form
It's easy to read the obligation as an administrative problem — templates, a submission portal, an on-call rota. Those matter. But the hard part sits earlier, in the 24 hours before you can write anything useful: is our product actually affected, and is this really the kind of exploitation that has to be reported?
Answer "yes" too readily and you flood your coordinating CSIRT with reports on vulnerabilities that don't reach your product — noise that costs you credibility and time you don't have. Answer "no" and you'd better be able to show why, because that decision is exactly what a market-surveillance authority can later question. This is the point where a vulnerability scanner stops being useful: it tells you a CVE exists, not whether it matters in your product.
This is why the reporting problem and the evidence-backed VEX problem are the same problem wearing different hats. If you can prove which component CVEs are genuinely reachable and exploitable, the clock only starts on the ones that qualify — and every "we didn't report this" is backed by an artifact instead of a judgement call made at 2am.
Getting ready before September
A workable state of readiness has a few concrete parts:
- Know your coordinating CSIRT. Identify the authority in your member state of main establishment before you need it, not during an incident — see CSIRT routing under the CRA.
- Wire the trigger. Monitor KEV and threat intelligence against the components in your products, so active exploitation raises a timed, auditable alert rather than a Slack message someone might miss.
- Prepare the reports in advance. Draft SRP-aligned templates for both streams and all three stages, so drafting doesn't eat the 24 hours.
- Have an out-of-hours process. A clock that ignores weekends needs a rota that doesn't.
- Make the assessment fast and defensible. The determination of whether your product is affected is the critical path. Evidence — reachability and exploitation proof — is what makes it both quick and answerable later.
For how that assessment gets made in practice, the pipeline walkthrough shows the path from an SBOM to a reportability shortlist, and the evidence-backed VEX guide covers what stands behind each decision. For the run of play once a clock is actually running, see the 24-hour CRA checklist.
Frequently asked
When does the CRA reporting obligation start?
The Article 14 reporting obligations apply from 11 September 2026, and cover products already on the EU market. The wider baseline — SBOM, secure-by-design, technical documentation, Declaration of Conformity and CE marking — applies from 11 December 2027.
What are the 24, 72 and 14 timeframes?
For an actively exploited vulnerability: an early warning within 24 hours of becoming aware, a fuller notification within 72 hours, and a final report within 14 days of a corrective measure becoming available. Severe incidents share the 24 and 72-hour steps, with a final report within one month of the 72-hour notification.
Where do CRA reports go?
Through the ENISA Single Reporting Platform, which routes the notification to your coordinating CSIRT and to ENISA simultaneously. As of mid-2026 the platform is not yet live and has no API, so prepare SRP-aligned reports in advance.
What counts as an actively exploited vulnerability?
One for which there is reliable evidence that a malicious actor has exploited it in a system without authorisation. A CISA KEV listing is a strong signal; a public proof-of-concept on its own is not.