Actively Exploited Vulnerability
An actively exploited vulnerability is a security flaw for which evidence exists that threat actors are currently using exploit code in real-world attacks. Under the CRA, manufacturers must notify ENISA within 24 hours of becoming aware that a vulnerability in their product is being actively exploited.
An actively exploited vulnerability is a security flaw for which evidence exists that threat actors are currently using exploit code in real-world attacks. Under the CRA, manufacturers must notify ENISA within 24 hours of becoming aware that a vulnerability in their product is being actively exploited.
CVD & Vulnerability ManagementWhat Is an Actively Exploited Vulnerability?
An actively exploited vulnerability is one for which credible evidence exists that it is being used by threat actors in real-world attacks — not merely demonstrated in a proof-of-concept or published as a theoretical risk, but actually weaponised against live systems. Evidence of active exploitation includes: threat intelligence reports from security researchers, ISACs, or vendors documenting exploitation attempts; incident response cases attributing attacks to a specific vulnerability; honeypot or telemetry data showing exploitation attempts in the wild; or inclusion in the CISA Known Exploited Vulnerabilities (KEV) catalogue. The distinction between theoretical and active exploitation matters significantly under the CRA because it triggers the most time-critical notification obligation.
CRA Notification Requirements for Actively Exploited Vulnerabilities
Article 14 of the CRA establishes a cascading notification obligation when a manufacturer becomes aware of an actively exploited vulnerability in their product:
- Within 24 hours: Submit an early warning to ENISA (via the EUVDB portal) identifying the vulnerability and confirming that active exploitation is occurring. This is a notification of awareness, not a full analysis.
- Within 72 hours: Submit a fuller notification including the CVE identifier (if assigned), a description of the vulnerability, affected product versions, an assessment of severity, and available mitigations.
- Within 14 days: Submit a final report including the root cause analysis, the remediation plan, and the status of any patch development or deployment.
These timelines are non-negotiable and begin from the moment the manufacturer has credible awareness of exploitation, not from when they confirm it internally.
Determining Exploitation Status: Sources and Signals
Manufacturers must establish mechanisms to monitor for exploitation evidence across multiple channels:
- CISA KEV: The CISA Known Exploited Vulnerabilities catalogue is the most authoritative public source. Manufacturers should monitor it for vulnerabilities affecting their products' component stack.
- Threat intelligence feeds: Commercial and open-source threat intelligence platforms aggregate exploitation indicators. Subscribing to feeds relevant to the product's technology stack is essential.
- Security research publications: Exploit proof-of-concept publications on GitHub, Exploit-DB, or researcher blogs often precede or coincide with in-the-wild exploitation.
- Incident telemetry: Manufacturers with cloud-connected products should monitor anomalous usage patterns that may indicate exploitation attempts.
- National CSIRT alerts: EU national CSIRTs and ENISA regularly issue alerts for actively exploited vulnerabilities; subscribing to relevant alerting channels is good practice.
Response Actions When Exploitation Is Detected
When a manufacturer becomes aware of active exploitation, the response should be immediate and parallel across three tracks:
Track 1 — Notification: Submit the CRA Article 14 notification to ENISA within 24 hours. Prepare follow-on notifications for the 72-hour and 14-day deadlines. Notify national CSIRT and relevant MSA if appropriate.
Track 2 — User protection: Publish an emergency security advisory with interim mitigation guidance (configuration changes, feature disablement, network controls) that users can apply immediately, even before a patch is available.
Track 3 — Remediation: Accelerate patch development, compress testing cycles where safely possible, and prepare the update delivery mechanism for rapid deployment. For exploited vulnerabilities, the normal remediation SLA should be overridden in favour of emergency response timelines.
CVD Portal makes Actively Exploited Vulnerability compliance straightforward.
Public CVD submission portal, acknowledgment tracking, Article 14 deadline alerts, and CSAF advisory generation. Free forever for EU manufacturers.
Start your free portalFrequently asked
When exactly does the 24-hour CRA notification clock start?+
The 24-hour clock starts when the manufacturer 'becomes aware' of the active exploitation. This is defined as when the manufacturer has credible, actionable information that exploitation is occurring — not when they have fully confirmed or reproduced it. Manufacturers should err on the side of early notification when in doubt: submitting a notification that is later revised is far better than missing the 24-hour deadline. The initial notification does not need to be a complete technical analysis.
What if active exploitation is discovered through a third party's incident, not the manufacturer's own systems?+
The notification obligation triggers regardless of where exploitation evidence is first observed. If a customer reports that their deployment of your product is being attacked via a specific vulnerability, or if a CSIRT notifies you that your product's vulnerability is being exploited in the wild, the 24-hour clock starts from that notification. Manufacturers should treat third-party exploitation reports as high-priority alerts and initiate their emergency response process immediately.
Is a proof-of-concept exploit the same as active exploitation for CRA purposes?+
No. A published proof-of-concept (PoC) demonstrates that exploitation is theoretically possible but does not constitute evidence of actual attacks occurring. A PoC publication significantly raises the exploitation risk and typically triggers escalated remediation priority and EPSS score increases. However, the CRA's 24-hour notification obligation applies specifically to active exploitation — evidence that attacks are actually happening. Manufacturers should accelerate response upon PoC publication without necessarily treating it as the same trigger as confirmed exploitation.
Related terms
Browse the full CRA Compliance Checklist
See how Actively Exploited Vulnerability fits into your complete CRA compliance programme.