CRA vulnerability reporting: the 24-hour early warning, 72-hour notification and final report

Last updated:

Under the Cyber Resilience Act, a manufacturer that becomes aware of an actively exploited vulnerability or a severe incident affecting its product must send an early warning within 24 hours, a notification within 72 hours, and a final report later. Everything goes through the ENISA Single Reporting Platform to the national CSIRT coordinator and ENISA at the same time. This has applied since 11 September 2026.

For the full picture of the regulation, see the Cyber Resilience Act hub.

What triggers a mandatory report

TriggerDefinition in the CRA
Actively exploited vulnerabilityA vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without the owner’s permission (Art. 3)
Severe incident affecting product securityAn incident that harms, or can harm, the product’s ability to protect the availability, authenticity, integrity or confidentiality of sensitive or important data or functions, or that has led or can lead to malicious code being introduced or executed in the product or the user’s systems (Art. 14(5))

A researcher’s report of a bug that nobody has exploited is not a mandatory notification. It is handled through your coordinated vulnerability disclosure process and fixed under Annex I Part II. You may notify it voluntarily (Art. 15).

The clock starts when you become aware. Evidence of exploitation can come from a researcher, a customer, a CSIRT, a threat-intelligence feed or your own telemetry.

The three reports for an exploited vulnerability

ReportDeadlineMinimum content (Art. 14(2))
Early warningWithout undue delay, at most 24 hours after awarenessThat an actively exploited vulnerability exists; where applicable, the Member States where the product is made available
Vulnerability notificationAt most 72 hours after awarenessGeneral information on the product, the nature of the exploit and vulnerability, corrective or mitigating measures taken and those users can take, and how sensitive you consider the information
Final reportAt most 14 days after a corrective or mitigating measure is availableDescription, severity and impact; information on the malicious actor where available; details of the security update or other corrective measures

The three reports for a severe incident

ReportDeadlineMinimum content (Art. 14(4))
Early warningAt most 24 hours after awarenessWhether the incident is suspected to be caused by unlawful or malicious acts; where applicable, the Member States where the product is available
Incident notificationAt most 72 hours after awarenessNature of the incident, initial assessment, corrective or mitigating measures taken and those users can take, sensitivity
Final reportWithin one month after the 72-hour notificationDetailed description, severity and impact; likely threat type or root cause; applied and ongoing mitigations

The CSIRT may also ask for an intermediate report on status updates (Art. 14(6)).

Where to send it

  • Channel: the Single Reporting Platform established by ENISA under Article 16. ENISA deployed its initial operating capability on 11 September 2026; the portal is at portal.cra-srp.enisa.europa.eu.
  • Recipient: the CSIRT designated as coordinator in the Member State of your main establishment in the EU, meaning where cybersecurity decisions for your products are mainly taken (or, failing that, where you have the most EU employees). ENISA receives the notification simultaneously (Art. 14(7)).
  • Non-EU manufacturers use the CSIRT of the Member State determined in this order: where your authorised representative for most of your products is established; else your importer for most products; else your distributor for most products; else where most of your users are located.
  • The receiving CSIRT shares the notification with the CSIRTs of the Member States where the product is available. It can delay that only in exceptional, justified cases (Art. 16(2)).

Account set-up and access steps are described in ENISA’s SRP user manuals (to be confirmed for your organisation type).

Tell your users too

Separately from the authorities, you must inform impacted users, and where appropriate all users, about the exploited vulnerability or incident and any mitigations they can apply, where appropriate in a structured, machine-readable format (Art. 14(8)). If you do not do this in time, the CSIRT may inform users itself.

What to prepare before the first incident

  1. A triage rule that defines “reliable evidence of exploitation” for your products, and who signs off.
  2. An on-call roster that covers weekends and holidays. A 24-hour deadline does not pause.
  3. Product data ready to paste: model names, firmware versions, the Member States where each is sold, and the SBOM per version.
  4. SRP access tested in advance, with at least two people able to submit.
  5. Pre-written templates for the early warning, 72-hour notification, final report and user advisory.
  6. A link to your disclosure intake: reports arrive through your published policy and security contact. Use our VDP template and security.txt guide.
  7. Evidence logging: when you became aware, what you knew, and what you sent. Authorities will look at the timeline.

Common mistakes

  • Waiting for a patch before the early warning. The 24-hour report does not need a fix; the final report comes after the fix.
  • Treating only your own code as relevant. A vulnerability in a third-party library inside your firmware is a vulnerability in your product.
  • Forgetting legacy models. Products placed on the market before 11 December 2027 are covered by Article 14 too.

Fines and the small-company carve-out

Breaching Article 14 falls under the highest fine band: up to EUR 15 million or 2.5% of worldwide annual turnover (Art. 64(2)). Micro and small enterprises are not fined for missing the 24-hour early-warning deadline (Art. 64(10)), but they still have to report.

Softwsp runs intake, triage and CRA notifications for device makers that have no in-house PSIRT: see PSIRT as a service. For the wider task list, use the CRA checklist for device makers.

This guide is general information, not legal advice.

Frequently asked questions

When does the CRA 24-hour reporting obligation apply?

Article 14 has applied since 11 September 2026. It covers all in-scope products, including those placed on the EU market before 11 December 2027.

What must be reported within 24 hours?

An early warning for any actively exploited vulnerability in your product, and for any severe incident affecting its security, within 24 hours of becoming aware of it.

Where do I submit CRA notifications?

Through the Single Reporting Platform run by ENISA, using the electronic end-point of the CSIRT designated as coordinator in the Member State of your main EU establishment. The notification is made available to ENISA at the same time.

Does every vulnerability report need to be notified?

No. The mandatory duty covers actively exploited vulnerabilities, meaning there is reliable evidence a malicious actor exploited it without the system owner's permission, and severe incidents. Other vulnerabilities can be notified voluntarily.

Can a small company be fined for missing the 24-hour deadline?

Article 64(10) states that administrative fines are not applied to micro and small enterprises for missing the 24-hour early-warning deadline. The other obligations still apply.

Sources

  1. Regulation (EU) 2024/2847 (Cyber Resilience Act), Articles 14, 16 and 64, EUR-Lex
  2. European Commission: CRA reporting obligations
  3. ENISA: The CRA Single Reporting Platform is launched
  4. ENISA: Single Reporting Platform (SRP) topic page