The reporting timeline is the part of Article 14 that turns a compliance obligation into an operational test. Once an event qualifies, the manufacturer is on the clock, and the windows are short. A 24-hour early warning is not a deadline you meet by starting work when you hear about it. It is a deadline you meet because you prepared for it months earlier.
This post sets out the three reporting stages, what each one must contain, the precise moment the clock starts, and the follow-up obligations that continue after the final report is filed. It is the fourth post in our CRA reporting series, following when reporting becomes mandatory, which vulnerabilities and incidents must be reported, and how reporting is routed to ENISA and national authorities. For a single-page overview of the whole reporting regime, see our guide to which CRA reporting obligations apply, when they start, and how to be ready.
When the clock starts
Every deadline in Article 14 runs from the same moment: when the manufacturer becomes aware of the actively exploited vulnerability or the severe incident. We covered the legal weight of "becomes aware" in the first post of this series. For the timeline, the practical consequences are three.
First, awareness can form before confirmation. A credible report of exploitation can start the clock even while you are still verifying it. The early warning exists precisely so you can notify on a preliminary basis.
Second, awareness can sit anywhere in the organisation. Knowledge held by a support agent or unread in a disclosure inbox still counts. If you cannot route signals to a decision-maker quickly, the clock may already be running while nobody senior knows.
Third, you must be able to evidence when awareness formed. The timestamp on the first credible signal is the anchor for the whole cascade, so capture it.
The three-stage cascade
Article 14 structures reporting as three escalating reports for the same event, each with its own deadline and its own purpose.
Stage one: the early warning, within 24 hours
Within 24 hours of becoming aware, the manufacturer submits an early warning to the reporting platform. This is an alert, not a full analysis. Its job is to put ENISA and the relevant national CSIRT on notice that something is happening, fast enough to be useful.
An early warning should identify the product affected, state that there is an actively exploited vulnerability or a severe incident, and give whatever is known at that point, including, where applicable, an indication of whether the event is suspected to be caused by unlawful or malicious acts. It is understood to be preliminary. You are not penalised for not yet knowing the root cause. You are expected to raise the flag inside the window.
Stage two: the detailed notification, within 72 hours
Within 72 hours of awareness, the manufacturer submits a vulnerability or incident notification that goes substantially further than the early warning. This is the substantive technical report.
It should cover the nature of the vulnerability or incident, an assessment of its severity and impact, the affected product and versions, indicators of compromise where available, and the corrective or mitigating measures taken or in progress. Where the early warning was a flag, the 72-hour notification is the analysis: enough for authorities and, ultimately, affected users to understand the risk and the response.
Stage three: the final report
The final report closes the cascade, and its deadline depends on which kind of event you are reporting.
For an actively exploited vulnerability, the final report is due within 14 days of a corrective or mitigating measure becoming available. The clock for this stage is keyed to the availability of the fix, because the final report is meant to describe the resolved position.
For a severe incident, the final report is due within one month of the detailed notification.
The final report draws the event to a close. It should include a description of the vulnerability or incident and its severity and impact, the root cause, the corrective and mitigating measures applied, and, where relevant, information about the threat actor or the nature of the compromise. It is the record of what happened, why, and how it was resolved.
A note on disclosure strategy
The final report is also where the manufacturer's disclosure strategy comes into focus. Coordinated public disclosure of the vulnerability, typically through an advisory, has to be handled in a way that informs and protects users without unnecessarily arming other attackers before mitigations are in place.
This is why mature programmes produce a machine-readable advisory as part of closing an event. We covered the format the EU ecosystem is converging on in our explainer on CSAF 2.0 advisories. The advisory and the final report are complementary: one informs authorities, the other informs the wider user base and downstream systems.
Summary of the deadlines
| Stage | Deadline | Clock starts from | Purpose |
|---|---|---|---|
| Early warning | 24 hours | Becoming aware | Flag that an exploited vulnerability or severe incident exists |
| Detailed notification | 72 hours | Becoming aware | Substantive technical assessment and measures |
| Final report (vulnerability) | 14 days | A corrective or mitigating measure becoming available | Root cause and resolved position |
| Final report (severe incident) | 1 month | The detailed notification | Full account of the incident and its handling |
Follow-up obligations after the final report
Filing the final report is not always the end of the manufacturer's duties for an event.
Where the situation is still developing, authorities may seek interim updates between the defined stages, and a manufacturer should be prepared to provide them. The reporting relationship is intended to be a dialogue during a live event, not a fixed set of one-way filings.
Beyond the platform notifications, the manufacturer's wider obligations continue. Affected users must be informed of the vulnerability and the available corrective or mitigating measures, and where appropriate told what they can do to protect themselves. This user-notification duty runs alongside the authority-reporting cascade. A manufacturer that has filed all three reports but left customers in the dark has not discharged its responsibilities.
The handling obligations under Article 13 also continue. The vulnerability must be remediated, the fix distributed through the product's update mechanism, and the whole event recorded so it informs future development and risk management. The connection between a single reported event and the broader programme is the subject of the final post in this series.
Why preparation, not speed, wins the clock
The instinct when reading these deadlines is to focus on moving fast. The more useful insight is that the deadlines are won or lost before the event, in preparation.
Twenty-four hours is comfortable if the intake channel is monitored, a named person can declare a reporting event without waiting for executive approval, platform access is verified, the national CSIRT contact is on file, and an early-warning template is ready to populate. Twenty-four hours is impossible if any of those is missing and you are assembling them while the product is under live attack. The operational machinery that makes the timeline achievable is covered in the post on internal detection and escalation.
A recurring failure mode is waiting for legal sign-off inside the 24-hour window. The early warning is preliminary by design, so the decision to file it should not require the same approval chain as a public statement. Pre-authorising the early warning is one of the highest-value preparations a manufacturer can make. We explored the demands of this specific window in our piece on the 24-hour notification obligation.
How CVD Portal supports the timeline
CVD Portal is built around this three-stage structure. When a submission is triaged as a potential Article 14 event, the platform timestamps awareness, generates a pre-populated early-warning draft from the intake data, and tracks the 24-hour, 72-hour, and final-report deadlines against that anchor. The detailed notification and final report inherit the case context, so each stage builds on the last rather than starting fresh. Every action is recorded in an immutable audit trail, which is the evidence that the timeline was met.
The bottom line
Article 14 reporting is a three-stage cascade: a 24-hour early warning, a 72-hour detailed notification, and a final report due within 14 days of a fix being available for a vulnerability or one month after the detailed notification for a severe incident. Every clock runs from the moment of awareness, follow-up updates and user notification continue after filing, and the deadlines are met through preparation rather than heroics.
With the what, where, and when of reporting now covered, the series turns to the internal machinery that makes it work: preparing internal detection, escalation, and decision-making processes.