CRA 24-Hour and 72-Hour Reporting Requirements

The shortest deadlines get the attention, but the core control is the single event record that connects awareness, staged submissions, corrective measures and evidence.

Awareness is the controlling event

Both the 24-hour and 72-hour periods run from manufacturer awareness of the actively exploited vulnerability or severe incident. After a prompt initial assessment, awareness is reached when the manufacturer has a reasonable degree of certainty that the reporting trigger is met. A signal alone is not automatically awareness, but an internal approval step cannot postpone an awareness time already reached. Organizations still confirming scope can review whether the CRA applies to U.S. manufacturers.

A defensible process preserves the original signal, who received it, what evidence existed, the prompt assessment, the UTC awareness determination and the factual basis—including earlier uncertainty. It does not wait for a finished investigation or delete the chronology that led to the decision.

The 24-hour early warning

The early warning is due without undue delay and no later than 24 hours after awareness. For an actively exploited vulnerability, the manufacturer identifies the occurrence and, where applicable, the Member States where the product has been made available. For a severe incident, the early warning also indicates whether unlawful or malicious acts are suspected.

Operationally, a 24-hour packet should at least have the reporter and manufacturer identity, affected product, concise title, factual summary, event type, awareness time and basis, available market information, sensitivity review and approval. Unknowns should be identified as unknown. A rushed guess is not stronger than a transparent gap. Use the EU CRA 24-hour readiness checklist to turn those fields into an assignable first-response control.

The 72-hour vulnerability or incident notification

This stage is due without undue delay and no later than 72 hours after awareness. It adds general information about the product and event, the general nature of the exploit or incident, the initial assessment, corrective or mitigating measures already taken, measures users can take and, where applicable, the manufacturer’s sensitivity assessment.

ENISA says to continue the same notification record through the 24-hour early warning, 72-hour notification, subsequent updates and final report. A coordinating CSIRT may request an intermediate report where necessary. The internal control system should preserve that lifecycle so changes and submission history remain traceable.

The final report deadlines differ

The final report adds severity and impact, malicious-actor information where available, root cause or likely threat type, security updates and applied or ongoing mitigation measures. The event should not be administratively closed merely because a patch shipped; the final submission and available confirmation evidence still need to be completed.

Assigned Representatives and platform access

ENISA’s “Assigned Representative” is an SRP user role and is distinct from a CRA Article 18 authorised representative. Manufacturers retain legal responsibility. Teams can prepare active personal EU Login accounts with two-factor authentication, legal-entity details, likely routing basis and named personnel now, but ENISA says SRP registration occurs when a report is needed. Recheck the production registration and validation flow once it is available.

Do not make a single person the only path to submission. Primary and backup owners need documented authority and an escalation route for nights, weekends and holidays.

When the platform is unavailable

A fallback plan should preserve the attempted access, screenshots or other evidence, internal approval, the prepared packet, the outage period and any communication with the relevant CSIRT or ENISA. The plan should also require submission through the SRP as soon as it becomes available. A platform outage does not justify losing the internal chronology.

The practical reporting sequence

1. Open an event record and preserve the original signal.
2. Assign the event owner and begin a UTC chronology.
3. Complete a prompt initial assessment; document awareness and calculate 24-hour and 72-hour due times.
4. Organize facts under the actively exploited vulnerability and severe-incident screens.
5. Prepare the early-warning packet and obtain emergency approval without delaying a clock already started.
6. Submit through the production SRP when available and preserve the notification ID, confirmation email or alert, and a screenshot or export if available.
7. Update the same controlled record for the 72-hour stage.
8. Track corrective measures, user communications and sensitivity decisions.
9. Calculate the correct final deadline for the event type.
10. Submit, preserve and close the evidence package only after the final stage is complete.

What a good workbook should not do

It should not pretend to determine legal scope, classify an event conclusively, investigate malware, choose the coordinating CSIRT without qualified review or certify the report. Its job is to preserve facts, ownership, time, fields, decisions, evidence and submission history so qualified people can act quickly and consistently.

Frequently asked questions

Primary sources

• Regulation (EU) 2024/2847
• European Commission — CRA reporting obligations
• ENISA — Single Reporting Platform FAQ
• European Commission — final CRA implementation guidance