CRA reporting obligations: awareness, notifications and final reports

Establish whether an Article 14 trigger exists

An actively exploited vulnerability requires reliable evidence that a malicious actor has exploited it in a system without the owner’s permission. A theoretical vulnerability or proof of concept alone is not automatically evidence of active exploitation.

A severe incident is assessed against Article 14(5), including effects on protection of sensitive or important data or functions, or malicious-code introduction or execution. Do not substitute a generic severity score for the statutory criteria. Keep the facts and the basis for the awareness decision.

Calculate 24 and 72 hours from the same awareness time

For both event types, the early warning and main notification are measured from becoming aware of the qualifying event. The second deadline is not 72 hours after the early warning. Use elapsed hours, so a change in daylight-saving time must not add or remove an hour.

The deadlines are maximum limits, not permission to delay unnecessarily. A timeline cannot decide when you legally became aware; it calculates from the timestamp you provide. Record the timezone and the supporting incident chronology.

The launch version of the SRP displays its 72-hour reminder counter at 48 hours after the early warning is submitted. This can flag a notification before the legal 72-hour limit from awareness. The platform counter does not replace the CRA deadline; the calculator continues to use awareness.

Vulnerability final report: corrective or mitigating measure

For an actively exploited vulnerability, the final report is due no later than 14 days after a corrective or mitigating measure becomes available. The trigger is not automatically the awareness time, the early warning or the final patch.

If no measure is available, the calculator can show the requirement but cannot invent an exact final deadline. Document when the measure became available and what it addressed. Earlier notifications and applicable user communication still need attention.

Severe incident final report: actual notification

The final report for a severe incident is due within one month after submission of the incident notification referred to in Article 14(4)(b). Use the actual submission timestamp, not an assumed submission at the 72-hour limit. A month is not a fixed 30-day interval.

The final report includes the incident severity and impact, the likely threat or root cause, and applied and ongoing mitigation measures. Article 14(4)(c) does not defer this deadline until the incident has been resolved. The calculator asks for the actual notification date and does not infer it from the 72-hour limit.

Submit through the official reporting channel

The CRA Single Reporting Platform is maintained by ENISA. Notifications reach the relevant designated CSIRT coordinator and ENISA under the statutory arrangements. Determine the appropriate CSIRT using Article 14(7), rather than simply choosing the timezone of your incident team.

Selecting the wrong coordinating CSIRT may invalidate the notification, requiring it to be resubmitted to the correct CSIRT. If the SRP is unavailable, submit once it is restored; urgent direct contact with the CSIRT does not replace that submission.

Voluntary reporting under Article 15 is not available at launch. A person outside the current manufacturer reporting process should contact the relevant national CSIRT directly. Steward reporting under Article 24(3) applies from 11 December 2027 under Article 71(2); manufacturer Article 14 reporting applies from 11 September 2026.

This calculator does not submit reports. It does not ask for vulnerability details or connect to an incident API. Use the official ENISA instructions for reporting access, fields and current operational arrangements.