Active exploitation is an evidence-based Article 14 trigger. A vulnerability can be serious, publicly known or technically exploitable without yet meeting the CRA definition. The key questions are whether there is reliable evidence of actual exploitation, whether the exploitation involved a malicious actor and whether it occurred without the system owner's permission.
The CRA Gives Actively Exploited Vulnerability a Specific Definition
Article 3(42) defines an actively exploited vulnerability 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. Each part matters. There must first be a vulnerability. There must then be evidence of actual exploitation rather than only evidence that exploitation would be technically possible. The evidence must be reliable, the exploitation must involve a malicious actor and the activity must occur without permission of the system owner. Article 14 connects this definition to mandatory manufacturer reporting when the manufacturer becomes aware of an actively exploited vulnerability contained in its product with digital elements.
- A vulnerability must exist.
- There must be reliable evidence of actual exploitation.
- The exploitation must involve a malicious actor.
- The exploitation must occur without the system owner's permission.
A Vulnerability Is Not the Same as an Exploitable Vulnerability
Article 3(40) defines a vulnerability as a weakness, susceptibility or flaw of a product with digital elements that can be exploited by a cyber threat. Article 3(41) separately defines an exploitable vulnerability as a vulnerability that has the potential to be effectively used by an adversary under practical operational conditions. This creates an important intermediate category. A product-security team may conclude that a weakness is realistically exploitable while still having no reliable evidence that a malicious actor has actually used it. Such a flaw can require urgent remediation, but technical exploitability alone does not establish the separate actively exploited vulnerability definition used by Article 14.
- Vulnerability: a weakness, susceptibility or flaw exists.
- Exploitable vulnerability: an adversary could effectively use it under practical conditions.
- Actively exploited vulnerability: reliable evidence shows actual malicious unauthorised exploitation.
- Do not use the three terms interchangeably.
Technical Possibility Alone Does Not Prove Active Exploitation
A public proof of concept, published exploit code, successful laboratory reproduction or high severity score can demonstrate that a weakness is exploitable. Those facts do not by themselves establish that a malicious actor has already exploited the vulnerability in a real system without authorisation. The Article 14 determination therefore requires an evidence step. Product-security teams should preserve the information supporting their conclusion, such as incident findings, validated customer evidence, telemetry, credible threat intelligence or other reliable information. The CRA does not reduce reliable evidence to one particular technical source, so the assessment should focus on the quality of the evidence available rather than an arbitrary requirement for one specific type of indicator.
- Separate exploitability evidence from real-world exploitation evidence.
- Assess the reliability of external exploitation reports.
- Preserve evidence sources and timestamps.
- Escalate credible evidence quickly because Article 14 deadlines are short.
Good-Faith Security Research Is Different From Malicious Exploitation
The CRA's recitals explain that vulnerabilities discovered without malicious intent for good-faith testing, investigation, correction or disclosure intended to promote the security or safety of the system owner and users should not be subject to mandatory notification merely because the vulnerability was exercised during that research. This is consistent with the Article 3 definition, which requires exploitation by a malicious actor. Manufacturers should therefore distinguish authorised or good-faith security research from hostile exploitation. A responsible disclosure can still reveal a serious vulnerability that needs immediate remediation, but the existence of the research activity does not by itself satisfy the active-exploitation trigger. The conclusion should be revisited if later evidence shows malicious exploitation.
- Good-faith research can reveal a real vulnerability without satisfying the malicious-actor element.
- Research findings still enter the vulnerability-handling process.
- Authorisation and intent are relevant to the active-exploitation assessment.
- Reassess when new evidence of malicious exploitation appears.
The Vulnerability Must Be Connected to the Manufacturer's Product
Article 14 refers to an actively exploited vulnerability contained in the product with digital elements. Manufacturers therefore need to connect external exploitation evidence to their own affected product or component context instead of treating every industry exploitation alert as an automatic report for every product. This is especially important where a third-party component is used across many products. A public report that a component vulnerability is being exploited should trigger urgent investigation, but the manufacturer still needs to determine whether the component is present in the product, which versions are affected, how it is configured and whether the vulnerable conditions exist. Dependency and version records can make this assessment substantially faster.
- Identify the affected component.
- Identify affected product versions.
- Determine whether the vulnerable conditions exist in the manufacturer's product.
- Connect external exploitation evidence to the actual product context.
- Preserve dependency and version evidence.
Manufacturer Awareness Starts the Article 14 Clock
Once the manufacturer becomes aware that the active-exploitation trigger is met, Article 14 requires an early warning without undue delay and in any event within 24 hours. The fuller vulnerability notification follows without undue delay and in any event within 72 hours. The organisation therefore needs a clear escalation route for credible exploitation evidence received through researchers, customers, suppliers, security operations, incident response and external threat sources. A fragmented process creates risk when one product team possesses reliable evidence but the Article 14 reporting owner does not see it until much later. Organisations should record when credible information is received, when the active-exploitation determination is made and which facts supported the determination.
- Create a clear escalation route for suspected active exploitation.
- Record when credible evidence is received.
- Record the manufacturer awareness determination.
- Calculate the Article 14 deadlines immediately.
- Ensure distributed product teams know the central reporting route.
The 72-Hour Notification Describes the Exploit and Vulnerability
Following the 24-hour early warning, the vulnerability notification is due without undue delay and in any event within 72 hours after awareness unless the relevant information has already been provided. Article 14 requires general information, as available, about the product concerned and the general nature of the exploit and vulnerability. The manufacturer also provides corrective or mitigating measures already taken, measures users can take and, where applicable, an indication of how sensitive the notified information is considered to be. The technical investigation can continue after the 72-hour notification. The objective is to provide the available operational picture within the statutory timeframe rather than delaying until every fact about the exploit chain is known.
- Describe the affected product.
- Describe the general nature of the exploit.
- Describe the general nature of the vulnerability.
- State corrective or mitigating measures already taken.
- Provide user mitigation measures where available.
- Identify sensitive information where applicable.
Build an Active-Exploitation Decision Record
A practical active-exploitation decision record should identify the vulnerability, affected product and versions, exploitability status, evidence of actual exploitation, evidence source, malicious-actor assessment, authorisation context, manufacturer awareness time and reporting decision. It should link to the 24-hour warning, the 72-hour notification, remediation activity and the final report. This makes later review easier and avoids vague statements such as exploitation reported online without documenting what information the manufacturer actually regarded as reliable. The record also allows a conclusion to be updated when the evidence changes. A vulnerability initially treated as not actively exploited can become an Article 14 event if later information establishes malicious unauthorised exploitation.
- Record the vulnerability and affected product versions.
- Separate exploitability from evidence of actual exploitation.
- Record why the evidence is considered reliable.
- Record the malicious and unauthorised exploitation analysis.
- Record the manufacturer awareness timestamp.
- Link the record to reporting and remediation actions.
Official sources
Read the full legal text and Commission material for precise wording, qualifications and updates.