CRA Reporting Deadlines: 24-Hour, 72-Hour & Final Report Guide

The Cyber Resilience Act reporting clock is easy to describe and easy to mishandle under pressure.

For a manufacturer dealing with a potentially reportable product-security event, the useful operational question is not simply “does the CRA require reporting?” It is:

If this event is reportable, what are the next deadlines, what starts each clock, and what information should the team be preparing now?

Use the free CRA Reporting Deadline Planner to turn an awareness date and time into a working timeline.

Quick answer: what are the main CRA reporting deadlines?

For the Article 14 reporting paths covered by this guide:

24 hours: early warning after the manufacturer becomes aware of the reportable event;
72 hours: fuller vulnerability or incident notification after awareness;
actively exploited vulnerability final report: no later than 14 days after a corrective or mitigating measure becomes available;
severe security incident final report: within one month after the 72-hour incident notification is submitted.

The reporting obligations in Article 14 apply from 11 September 2026.

Primary sources:

This article is a planning guide, not a determination that a particular event is legally reportable.

The first date to preserve: when the manufacturer became aware

The 24-hour and 72-hour clocks run from awareness.

That makes the awareness timestamp an operationally important fact. During a live security response, teams can lose time debating when an event became “real enough” internally. A better process is to preserve the relevant timestamps and the evidence behind them rather than reconstructing the sequence later.

For planning purposes, record at least:

date and time;
timezone;
source of the information;
team or person who received it;
product or product family affected;
internal case or incident identifier.

The GentleTools planner uses the browser’s local timezone and keeps the information locally on the device.

CRA 24-hour early warning

Article 14 requires the early warning without undue delay and in any event within 24 hours of awareness.

For an actively exploited vulnerability, the early warning indicates, where applicable, the Member States where the manufacturer knows the product has been made available.

For a severe security incident, the early warning also includes at least whether the incident is suspected of being caused by unlawful or malicious acts, together with relevant Member State information where applicable.

The 24-hour deadline should not be treated as a target for waiting until hour 23. It is an outer time boundary in the legal text, alongside the requirement to act without undue delay.

CRA 72-hour notification

The next major milestone is the fuller notification within 72 hours of awareness.

For an actively exploited vulnerability, Article 14 describes information including, as available:

general information about the product with digital elements;
the general nature of the exploit and vulnerability;
corrective or mitigating measures already taken;
corrective or mitigating measures users can take;
sensitivity of the information, where applicable.

For a severe security incident, the 72-hour notification includes, where available:

the nature of the incident;
an initial assessment;
corrective or mitigating measures taken;
corrective or mitigating measures users can take;
sensitivity of the information, where applicable.

The final-report deadline is not the same for both paths

This is the part most likely to be oversimplified in a generic “24h / 72h / 14 days” summary.

There are two different final-report clocks.

Actively exploited vulnerability

The final report is due no later than 14 days after a corrective or mitigating measure is available.

The legal text lists final-report content including:

a description of the vulnerability;
severity and impact;
information about a malicious actor, where available;
details about the security update or other corrective measures made available.

The important planning detail is the trigger: the final-report date does not simply equal “awareness + 14 days.”

Severe security incident

The final report is due within one month after the 72-hour incident notification is submitted.

The legal text describes content including:

detailed incident description;
severity and impact;
likely threat type or root cause;
applied and ongoing mitigation measures.

Again, the trigger matters. The final-report deadline is linked to submission of the incident notification.

Worked example: actively exploited vulnerability

Assume a manufacturer becomes aware of an actively exploited vulnerability at:

6 October 2026, 10:30

The first two planning deadlines are:

early warning: 7 October 2026, 10:30;
fuller vulnerability notification: 9 October 2026, 10:30.

Now assume a corrective measure becomes available on:

10 October 2026, 16:00

The final-report deadline is then:

24 October 2026, 16:00

The CRA Reporting Deadline Planner performs this timeline calculation automatically.

Worked example: severe security incident

Assume the manufacturer becomes aware of a severe security incident at:

2 November 2026, 09:00

Planning milestones:

early warning: 3 November 2026, 09:00;
72-hour incident notification deadline: 5 November 2026, 09:00.

If the incident notification is actually submitted on 4 November 2026, 18:00, the one-month final-report clock is calculated from that submission time rather than automatically from the 72-hour deadline.

This distinction is why an operational planner should capture both the statutory deadline and actual submission time.

A simple internal CRA reporting workflow

A useful internal workflow separates four questions that are often mixed together:

Classification: what happened and which reporting path might apply?
Clock: when did awareness occur and what deadlines follow?
Evidence: what facts are confirmed, suspected or still unknown?
Submission status: what has actually been filed, when and by whom?

The deadline calculator addresses the clock. It intentionally does not attempt to replace legal classification, incident response or submission review.

What should be saved beside the deadline?

A timestamp by itself is not enough for a mature workflow.

Consider retaining:

internal owner;
relevant product and version;
known affected markets;
awareness evidence;
current mitigation status;
user-facing mitigation information;
submission receipts or identifiers;
corrective-measure release timestamp;
final-report owner.

A lightweight calendar reminder is useful, but the underlying case record should remain the source of truth.

Why a deadline calculator is useful even when you already have an incident system

Most incident systems can store dates. The gap is often the path-specific calculation and the immediate human-readable sequence.

A small dedicated planner helps a security, engineering or compliance lead answer three questions quickly:

What is due next?
What starts the final-report clock?
Which information bucket should the team be preparing?

That makes the calculator useful as a front-end planning aid even when the formal record lives elsewhere.

CRA reporting deadline FAQ

When do the CRA reporting obligations start?

Article 14 reporting obligations apply from 11 September 2026. The broader CRA has other application dates, so do not assume every provision begins on the same day.

Is every vulnerability reportable within 24 hours?

No. Article 14 is specifically concerned with the reporting conditions described in the Regulation, including actively exploited vulnerabilities. Whether a specific case meets the legal test is outside the scope of this calculator.

Is the vulnerability final report due 14 days after awareness?

Not under the Article 14 wording used here. The final report for an actively exploited vulnerability is due no later than 14 days after a corrective or mitigating measure becomes available.

Is the severe incident final report due one month after awareness?

The Article 14 final-report clock is tied to submission of the incident notification described in the 72-hour stage.

Does the planner submit anything to ENISA or a CSIRT?

No. It is a local browser planning tool. It does not transmit a report or replace the CRA Single Reporting Platform.

Source check

For compliance work, always validate against the current official material rather than relying on a secondary summary.

The two most useful primary references for this timeline are:

Then use the CRA Reporting Deadline Planner to convert the applicable trigger times into a practical working schedule.