The EU CRA Reporting Clock: 24 Hours, 72 Hours, Then a Final Report

Manufacturers of products with digital elements must report two things: actively exploited vulnerabilities in those products, and severe incidents having an impact on product security. Both run on the same staged clock, described by the European Commission on its CRA reporting page: an early warning "within 24 hours of becoming aware", a fuller notification "within 72 hours", and a final report no later than 14 days after a corrective measure is available for a vulnerability, or within a month for a severe incident. Reports go to the CSIRT designated as coordinator where you have your main establishment and are shared simultaneously with ENISA, through a single platform, and all of it applies from 11 September 2026. The counterintuitive part is that this is the first substantive obligation the Cyber Resilience Act imposes, arriving well before the requirements it exists to police, and it reaches products you shipped years ago and have not touched since.

This piece covers what is and is not reportable, the three stages of the clock and what each one is for, where the reports go and through what platform, why the awareness trigger is harder than the deadlines, and what this obligation deliberately does not do.

Key takeaways

• Two reportable events: actively exploited vulnerabilities, and severe incidents having an impact on the security of the product with digital elements.
• Three stages: early warning within 24 hours of becoming aware, notification within 72 hours, final report at 14 days after a corrective measure is available (vulnerabilities) or within a month (severe incidents).
• Reports go to the CSIRT of the Member State of your main establishment and simultaneously to ENISA, through the CRA Single Reporting Platform. You report once.
• The obligation applies from 11 September 2026, and per the Commission it covers products already on the market before full applicability.
• This is a product-security clock, not a personal-data clock. It runs on exploitation, not on confirmation that personal data was affected.

The two reportable events, and what falls outside them

The Commission is precise about the trigger and deliberately economical about the rest: manufacturers "are required to report actively exploited vulnerabilities and severe incidents" affecting their products with digital elements.

Take the qualifiers seriously, because they are what keep this from swallowing your entire vulnerability backlog. A vulnerability is not reportable because it is severe, or because it has a high CVSS score, or because a researcher published it. It is reportable when it is actively exploited. An incident is not reportable because it happened; it is reportable when it is severe and has an impact on the security of the product with digital elements. An outage caused by a failed deployment is not a product-security incident. A compromise of your build pipeline that ships to customers almost certainly is.

An honest limitation: the Commission's public pages set out the obligation and the deadlines without publishing operational definitions of "actively exploited" and "severe" that a triage engineer could apply mechanically. That gap is where your internal criteria have to live, and writing them down in advance is the single most useful preparation available, because nobody makes a good definitional judgement inside a 24-hour window.

The three stages, and what each one is actually for

The staging is not bureaucratic duplication. Each stage answers a different question and the first one is deliberately cheap to file.

Early warning, within 24 hours of becoming aware. This is a heads-up, not an investigation. Its purpose is to let the coordinating CSIRT and ENISA know something is being exploited in the field while you still know almost nothing. Treat it as a notification you can produce with an on-call engineer and a template, because that is the only version of it that will actually be filed on time.

Notification, within 72 hours. The fuller account: what the vulnerability or incident is, what you know about scope and impact, what corrective or mitigating measures exist or are being prepared.

Final report. For an actively exploited vulnerability, no later than 14 days after a corrective or mitigating measure is available. For a severe incident, within a month of the 72-hour submission. Note the asymmetry: the vulnerability clock is pegged to the availability of a fix, so a fix that takes three months moves the final report with it, while the incident clock runs on the calendar regardless.

Where the reports go, and the platform that receives them

Reports go to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment, and are made available simultaneously to ENISA, unless exceptional circumstances apply. The initial CSIRT then distributes the notification to CSIRTs in the other territories where the product is available, and the Commission notes that in exceptional circumstances, on justified cybersecurity-related grounds, that onward sharing can be delayed.

The single-window design is the practical part. The Commission states that manufacturers "report only once through the CRA Single Reporting Platform (SRP)", that ENISA is responsible for developing it, and that it will be operational by 11 September 2026, the same date the obligations take effect.

Two things follow for a manufacturer outside the EU. You need to know which Member State is your main establishment, because that determines your coordinating CSIRT, and that is a legal-entity question your counsel answers rather than an engineering one. And you need someone accountable for platform onboarding before you need to file, not on the day you do.

The awareness trigger is harder than the deadlines

Twenty-four hours sounds like the difficult part. It is not. The difficult part is that the clock starts on awareness of exploitation, and awareness is distributed across your organisation in ways your incident process probably does not capture.

Consider where the first signal usually appears. A support ticket describing behaviour that only makes sense as exploitation. A threat intelligence feed naming your product. A customer's own security team emailing an account manager. A public post about a proof of concept being used in the wild. None of those arrive in your security operations queue by default, and any of them can constitute the moment the organisation became aware.

The fix is unglamorous and it is the same fix that works for every other regulatory clock: define what becoming aware means in your own documented terms, name the roles whose knowledge counts, and give every inbound channel a route into the triage that starts the clock. Then timestamp the moment, because the timestamp is the evidence that your 24 hours ran from where you say it ran. Our breach notification deadlines guide makes the same argument about trigger events across the other regimes, and the lesson transfers directly: teams miss deadlines by getting the start time wrong far more often than by working too slowly.

One more design note. This clock runs on exploitation of a product, not on confirmation that personal data was affected. A team that has built its entire notification muscle around personal-data breach analysis will start this clock too late, because it will wait for an analysis this obligation does not ask for.

Why this obligation arrives before everything else

The sequencing surprises people who have read the Act's substantive requirements and assumed they come first.

The Cyber Resilience Act entered into force on 10 December 2024. Chapter IV, which covers notification of conformity assessment bodies, applies from 11 June 2026 so that third-party assessment machinery exists in time. The main obligations, including the essential requirements and conformity assessment, apply from 11 December 2027. Article 14 reporting sits between them, from 11 September 2026.

More than a year separates the reporting duty from the requirements it accompanies, and the reporting duty reaches further back. The Commission notes that the reporting obligations apply to products already on the market before full implementation. A product you shipped in 2023 and have not modified since is inside the reporting regime if it is in scope, even though its design never has to meet the essential requirements.

That inverts the usual planning instinct. Teams plan CRA work around the later date because that is where the engineering is, and then discover that the earlier date needs an operational process covering a product portfolio much wider than the roadmap. If you have not established which of your shipped products are in scope, that scoping question is the prerequisite, and we cover it separately in does the EU CRA apply to your product.

What this does not do, and where we would tell you to stop

Three honest boundaries.

It does not tell you whether you are in scope. Everything above assumes you are a manufacturer of a product with digital elements placed on the EU market. If you sell only a hosted service with no component a customer installs or receives, the applicability analysis is a memo, not a programme, and the memo is the deliverable we would rather write for you.

It does not replace your other clocks. The reporting obligation is about product security, and it sits alongside personal-data breach notification and any sector rules you carry. Those have different triggers and different recipients, and collapsing them into one process is how organisations end up filing the wrong thing with the wrong authority.

And it does not require a new tool. What it requires is a triage path, written criteria, named roles, a timestamped log and a rehearsed template. Every organisation we have watched do this well did it with the incident process it already had. If a vendor is selling you a CRA reporting platform before you have written your criteria, you are buying the wrong thing first.

Where Top Floor fits

The reporting obligation is an incident-process problem wearing a regulatory hat, so the work runs across two practices. Under our EU CRA practice we do the scoping and the criteria: which shipped products are in scope, what your organisation will treat as an actively exploited vulnerability or a severe incident, and who is accountable for filing.

The operational half sits with incident response: building the 24-hour path into an existing process, adding the intake routes that carry awareness from support and threat intelligence into triage, and rehearsing it before it matters. Where the CRA is one of several regimes you carry, international compliance is where the clocks get reconciled so that one event triggers every applicable notification without duplicated triage.

Two adjacent pieces from this site are worth reading alongside: what the CRA requires in an SBOM, which is the artifact that makes exploitation assessment fast, and Annex III and the conformity routes for the classification question.

How to decide this week

Write down what your organisation will treat as an actively exploited vulnerability and as a severe incident, in a page, and get product and security to disagree about it now rather than during an incident. The definitions do not have to be perfect; they have to exist and be documented before you rely on them.

Then find the moment of awareness in your last three security events and ask whether you could evidence it. If the honest answer is that it lived in a support inbox for two days, the 24-hour clock is not your problem yet. Intake is.

Finally, settle which Member State is your main establishment and identify the coordinating CSIRT. That is a question for counsel, it takes one conversation, and everything about the filing path depends on the answer.

Frequently asked questions

What has to be reported under Article 14 of the EU Cyber Resilience Act?

Two categories: actively exploited vulnerabilities in a product with digital elements, and severe incidents having an impact on the security of that product. Both qualifiers are limiting. A vulnerability is not reportable on severity alone; the trigger is active exploitation. An incident is not reportable simply because it occurred; it must be severe and affect the security of the product. The Commission's published pages set the obligation and the deadlines without publishing mechanical definitions of those terms, so a manufacturer's own documented triage criteria carry the judgement.

What are the EU CRA reporting deadlines?

Three stages, per the European Commission. An early warning within 24 hours of becoming aware. A fuller notification within 72 hours. A final report no later than 14 days after a corrective or mitigating measure is available for an actively exploited vulnerability, or within a month for a severe incident. The vulnerability final report is pegged to the availability of a fix rather than to the calendar, while the severe-incident final report runs from the 72-hour submission.

Who do you report to, and do you have to file more than once?

Reports go to the CSIRT designated as coordinator in the Member State where the manufacturer has its main establishment, and are made available simultaneously to ENISA unless exceptional circumstances apply. That CSIRT then distributes to CSIRTs in other territories where the product is available. The Commission states that manufacturers report only once, through the CRA Single Reporting Platform, which ENISA is developing and which is to be operational by 11 September 2026.

Does this apply to products we shipped years ago?

Yes, if they are in scope. The Commission notes that the reporting obligations apply to products already placed on the market before full applicability. That is the opposite of the usual grandfathering instinct: a product whose design never has to meet the essential requirements can still sit inside the reporting regime. Any scoping exercise that only examines the current roadmap is answering a narrower question than the obligation asks.