Skip to content
CRA Reporting Desk

Notifying an actively exploited vulnerability under the CRA

Since 11 September 2026, a manufacturer that becomes aware of an actively exploited vulnerability in its product must notify it under Article 14 of the EU Cyber Resilience Act. The test is evidence of malicious exploitation, not severity. Once it is met, the 24-hour clock is running.

The short version

  • What triggers it: reliable evidence that a malicious actor has exploited the vulnerability in a system without the owner's permission (Article 3(42)).
  • Early warning: within 24 hours of becoming aware.
  • Vulnerability notification: within 72 hours of becoming aware.
  • Final report: no later than 14 days after a corrective or mitigating measure is available.
  • Users: inform impacted users, and where appropriate all users, and tell them what they can do (Article 14(8)).

All three reports go through ENISA's Single Reporting Platform to your CSIRT designated as coordinator, and ENISA receives them at the same time.

Run the free CRA Reporting DeskBook a 20-minute demo

Is it actively exploited?

The definition has three parts. Record your evidence for each:

  • Reliable evidence. Teams typically look at telemetry, customer or CSIRT reports with indicators, and threat intelligence naming the product. Record what you saw and why you judged it reliable.
  • A malicious actor: good-faith research, testing and coordinated disclosure do not count (Recital 68).
  • Exploited in a system without the owner's permission: a working proof of concept on your own test bench is not exploitation in the wild.

If the evidence is not there yet, say so in the case file, with who is checking and by when. Many teams lose hours here. Write a triage rule in advance that says who decides and what evidence is enough.

Vulnerability or severe incident?

The same event can look like both. Recital 68 describes an actively exploited vulnerability as a malicious actor using a flaw in your product to breach your users or others. It describes a severe incident as one affecting your development, production or maintenance processes, for example an attacker getting malicious code into your update channel. The content and the final-report deadline differ, so record which track you chose and why. Notifying a severe incident.

What each report contains

Early warning (Article 14(2)(a)): the product, and where applicable the Member States where you know it has been made available.

Vulnerability notification (Article 14(2)(b)), unless already provided: general information, as available, about the product, the general nature of the exploit and of the vulnerability, corrective or mitigating measures taken and those users can take, and where applicable how sensitive you consider the information.

Final report (Article 14(2)(c)): a description of the vulnerability with its severity and impact, information about any malicious actor where available, and details of the security update or other corrective measures made available.

Copy the report template, or log the case in the free desk and download it filled in.

Two dates to record

  • When you became aware: this starts the 24-hour and 72-hour deadlines.
  • When a corrective or mitigating measure became available: this starts the 14 days for the final report. Article 14 says “corrective or mitigating measure”, not “patch”, so decide with counsel whether a published workaround already starts the clock.

ENISA's platform has no countdown for this final report yet, because it does not know when your fix shipped. Track it yourself.

Telling users

Article 14(8) requires you to inform impacted users, and where appropriate all users, about the vulnerability and, where necessary, the measures they can take, where appropriate in a structured, machine-readable format. If you do not do it in time, the CSIRT may inform them itself. Draft the advisory alongside the 72-hour notification so the two say the same thing.

After the notification

The CSIRT that receives the notification may ask for an intermediate report on status updates (Article 14(6)). Keep the case file current so you can answer quickly.

Questions people ask

What is an actively exploited vulnerability under the CRA?
Article 3(42) defines it as a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner.
Do I have to report a vulnerability found by a security researcher?
Not as an actively exploited vulnerability if there is no reliable evidence of malicious exploitation. Recital 68 says vulnerabilities discovered with no malicious intent, for good-faith testing, investigation, correction or disclosure, should not be subject to mandatory notification. Handle it through your vulnerability handling process, and report it if exploitation evidence appears later.
Do zero-days have to be reported before a patch exists?
Yes, once you have reliable evidence that a malicious actor has exploited the vulnerability. The early warning and notification do not wait for a fix; only the final report is timed from when a corrective or mitigating measure is available.
When does the 24-hour clock start?
When the manufacturer becomes aware of the actively exploited vulnerability. The European Commission's FAQs on CRA implementation (section 5.1) discuss how a manufacturer becomes aware.
What about exploitation we already knew about before 11 September 2026?
ENISA's FAQ, citing the Commission's FAQs, says manufacturers do not have to report retrospectively where they were already aware of the active exploitation before 11 September 2026. If you become aware of the exploitation after that date, the obligation applies, even if the vulnerability itself was known earlier.
What if the exploited vulnerability is in a third-party component?
The Commission addresses this in section 5.4 of its FAQs on CRA implementation and in its CRA guidance. Separately, Article 13(6) requires you to report vulnerabilities you identify in an integrated component to whoever maintains it.

Use the free CRA Reporting Desk

Log the awareness time and the date a fix became available, and the desk counts down the 24-hour, 72-hour and 14-day final-report deadlines. Download draft text for all three reports. No sign-up; your data stays in your browser.

Want help setting up a triage rule and reporting process for your products? Book a call or email us.

Run the free CRA Reporting DeskBook a 20-minute demoEmail us about your vulnerability process

Workflow support, not legal advice. Whether a vulnerability is actively exploited, when you became aware, which CSIRT is yours, and what you submit are your decisions. Confirm legal conclusions with qualified counsel or a compliance adviser. Source: Regulation (EU) 2024/2847, Articles 3, 13, 14 and Recital 68 (EUR-Lex).