AA-sec logo AA-sec
Vulnerability Management

What Counts as an Actively Exploited Vulnerability Under the CRA?

A practical guide to the CRA definition of an actively exploited vulnerability, the reliable-evidence threshold, awareness timing, and defensible triage records.

AA-sec8 August 2026
  • actively exploited vulnerability under the CRA
  • CRA actively exploited vulnerability
  • actively exploited vulnerability definition
  • CRA reliable evidence of exploitation
  • CRA Article 14 vulnerability
  • Cyber Resilience Act exploit reporting
AA-sec cover graphic explaining how to identify an actively exploited vulnerability under the Cyber Resilience Act

An actively exploited vulnerability under the Cyber Resilience Act is not simply a serious or technically exploitable weakness. The CRA threshold is reached when there is reliable evidence that a malicious actor has actually exploited the vulnerability in a system without the system owner's permission. For manufacturers, the practical challenge is therefore to recognise credible evidence of exploitation quickly, record when the organisation became aware of it, and connect that evidence to the affected product before the Article 14 reporting clock starts to run unnoticed.

The legal definition is narrower than "high risk"

The CRA distinguishes three concepts that product-security teams should keep separate.

A vulnerability is a weakness, susceptibility, or flaw of a product with digital elements that can be exploited by a cyber threat. An exploitable vulnerability is one that has the potential to be used effectively by an adversary under practical operational conditions. An actively exploited vulnerability goes one step further: Article 3 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.

That distinction matters operationally. A vulnerability can be severe without evidence of exploitation. It can have working proof-of-concept code and still not meet the CRA definition of active exploitation. Conversely, a vulnerability with a modest severity score may become reportable if reliable evidence shows that a malicious actor is exploiting it.

For triage, do not collapse "critical", "exploitable", and "actively exploited" into one internal status. They answer different questions:

  • Severity asks how serious the potential impact is.
  • Exploitability asks whether practical exploitation is possible.
  • Active exploitation asks whether malicious exploitation has actually occurred and whether the evidence is reliable.

Article 14 reporting is triggered by the last of these concepts, not by a severity score alone.

What "reliable evidence" means in practice

The regulation defines the legal threshold but does not provide a closed technical checklist of evidence types in Article 3. Product teams therefore need a repeatable way to assess the credibility, specificity, and relevance of exploitation information.

A useful internal test is to ask four questions.

  1. Does the information describe actual exploitation rather than only capability? A public exploit, demonstration, or scanner finding may prove that exploitation is possible. It does not by itself prove that a malicious actor has exploited the vulnerability.
  2. Is the source credible enough to support the conclusion? Direct incident telemetry, a confirmed customer incident, a validated supplier notice, or an authoritative security report can carry different evidentiary weight from an unverified social-media claim.
  3. Can the evidence be tied to the vulnerability? The organisation should be able to explain why the observed malicious activity corresponds to the weakness being assessed rather than to another technique or unrelated compromise.
  4. Is the vulnerable condition present in an in-scope product? Product and component context matters. The reporting team needs to identify affected products, versions, configurations, and component relationships rather than treating a vulnerability identifier as sufficient product evidence.

These questions are an engineering and governance method, not a substitute for legal interpretation. Their purpose is to make the decision reproducible and to preserve the facts on which the manufacturer acted.

Signals that should not be treated as proof on their own

Fast-moving vulnerability information creates pressure to make binary decisions too early. Several common signals are important for prioritisation but do not, on their own, establish every element of the CRA definition.

A CVE or EUVD identifier establishes a reference to a vulnerability, not proof of malicious exploitation. A high CVSS score describes severity characteristics, not whether an attacker has used the weakness. Public proof-of-concept code demonstrates technical feasibility, but a demonstration in a controlled environment is different from malicious exploitation without the system owner's permission.

Likewise, scanner detection inside a product build can show that a vulnerable component is present, but it does not automatically show that the vulnerability is reachable, exploitable in the product's configuration, or actively exploited. Threat-intelligence statements such as "exploitation observed" may be highly relevant, but the reporting team should preserve the source, date, affected versions, and any technical details that connect the statement to its own product.

This does not mean teams should wait for perfect evidence. It means they should distinguish the facts they have from the conclusions they draw and retain both.

Stronger evidence patterns

Evidence becomes more persuasive when independent facts converge.

Examples can include incident-response telemetry showing exploitation of the relevant weakness, a customer or operator report supported by logs or forensic material, a supplier or component maintainer notice describing confirmed malicious exploitation, or authoritative threat intelligence that identifies the vulnerability and exploitation activity with enough specificity to assess affected products.

The reporting record should capture the original evidence rather than only the final status. Useful fields include:

  • source and receipt time;
  • vulnerability identifier and affected component;
  • product, version, or release context;
  • description of the observed exploitation;
  • why the activity is considered malicious;
  • validation steps performed by the product-security team;
  • confidence or uncertainty that remains;
  • reviewer and decision owner;
  • the time at which the manufacturer concluded it was aware of an actively exploited vulnerability.

A later reviewer should be able to reconstruct the decision without relying on the memory of the person who handled the case.

The awareness timestamp is operationally critical

From 11 September 2026, Article 14 requires manufacturers to report actively exploited vulnerabilities that they become aware of. The staged deadlines run from awareness: an early warning must be submitted without undue delay and in any event within 24 hours, followed by the vulnerability notification without undue delay and within 72 hours unless the relevant information has already been provided.

This makes the transition from "signal received" to "manufacturer aware" a control point that should be designed before a real incident occurs. ENISA's current Single Reporting Platform FAQ also states that the reporting process starts when the manufacturer becomes aware of active exploitation.

Teams should therefore record at least three timestamps separately:

  • when the first signal entered the organisation;
  • when sufficient information became available to support the active-exploitation assessment;
  • when the reporting decision was formally recorded or escalated.

Those times may be identical, but they may also differ. Preserving them allows legal or compliance reviewers to understand the sequence rather than reconstructing it from email and chat history after the deadline.

Internal processes should also avoid making awareness depend on a single executive approval. If reliable evidence reaches an engineering or security function that is part of the manufacturer's normal vulnerability-handling process, delaying formal escalation can create avoidable ambiguity about when awareness occurred.

Third-party components still require product context

Many CRA cases will begin with a vulnerability in an open-source library, commercial dependency, firmware component, or other third-party element. Article 14 concerns an actively exploited vulnerability contained in the manufacturer's product with digital elements. The component origin therefore does not remove the need for a product-level assessment.

The first task is mapping: determine whether the affected component and vulnerable version are actually present in supported products. The next task is impact context: identify which product versions, configurations, and releases contain the vulnerable condition. The final task is evidence: determine whether the exploitation information meets the active-exploitation threshold and document the reasoning.

An SBOM can accelerate the first part of that analysis, but an SBOM alone is not the reportability decision. It establishes component provenance and presence; the vulnerability assessment still needs exploitation evidence and product context.

This is one reason product-security teams benefit from keeping component inventory, vulnerability records, release history, and investigation evidence connected rather than operating them as separate spreadsheets.

What happens after the threshold is met

Once the manufacturer becomes aware of an actively exploited vulnerability, the Article 14 workflow is staged.

The 24-hour early warning is designed for speed. It is not a finished root-cause report. The manufacturer should be able to identify the product, the notification type, the relevant market information where applicable, and the facts available at that stage.

The 72-hour vulnerability notification adds general information about the affected product, the nature of the vulnerability and exploit, corrective or mitigating measures already taken, measures users can take, and sensitivity information where applicable.

The final report for an actively exploited vulnerability is due no later than 14 days after a corrective or mitigating measure becomes available. It includes the vulnerability's severity and impact, available information about the malicious actor, and details of the security update or other corrective measures.

Notifications are submitted through the CRA Single Reporting Platform. ENISA says the platform is scheduled to be operational when the reporting obligations apply on 11 September 2026.

The practical lesson is that triage and reporting cannot be separate processes. The evidence collected during the first assessment needs to flow directly into the staged notification record.

Build a defensible triage record

A simple decision record can prevent a large amount of confusion during a fast-moving vulnerability case. For each candidate, record:

  1. the vulnerability and affected component;
  2. the products and versions in which it is contained;
  3. the evidence that exploitation has occurred;
  4. the source and reliability assessment;
  5. why the activity is considered malicious and unauthorised;
  6. the awareness timestamp and supporting chronology;
  7. the reportability decision and accountable owner;
  8. any uncertainty that remains;
  9. the 24-hour, 72-hour, and final-report status if reporting is triggered;
  10. remediation, security-update, and user-mitigation evidence.

Do not overwrite earlier assessments when new facts arrive. Preserve the evolution of the case. A decision that was reasonable at 09:00 may need to change at 13:00 when a supplier confirms exploitation, and that chronology is itself relevant evidence.

Where AA-sec fits

AA-sec is a cyber resilience platform for secure product development and lifecycle evidence. Its planned scope combines vulnerability management, SBOM, security evidence, compliance workflows, and lifecycle visibility. For CRA vulnerability triage, that connected model is intended to help teams keep component context, investigation evidence, and lifecycle records together; the manufacturer still owns the legal decision about whether Article 14 reporting is required.

A practical test before September 2026

Before the reporting rules apply, run a tabletop exercise using a realistic component vulnerability.

Start with a supplier or threat-intelligence alert that says exploitation has been observed. Ask the team to identify the affected products from its component records, collect the original evidence, distinguish exploitation from severity, establish the awareness chronology, name the decision owner, and prepare the minimum early-warning data.

Then change one fact: make the original alert ambiguous. The team should be able to leave the case under investigation without losing the evidence. Add a later confirmation of malicious exploitation and test whether the workflow records the new awareness point and starts the reporting timeline without replacing the earlier assessment.

A mature process does not need every signal to be immediately certain. It needs to make uncertainty visible, preserve evidence, and escalate quickly when the legal threshold is reached.

The key distinction to remember

For CRA reporting, the question is not simply "Is this vulnerability dangerous?" The question is whether there is reliable evidence that a malicious actor has actually exploited the vulnerability in a system without permission, and whether that vulnerability is contained in the manufacturer's product.

Keeping those elements separate gives product teams a clearer triage model: severity drives prioritisation, exploitability informs technical risk, and evidence of actual malicious exploitation drives the specific Article 14 reporting assessment. That structure is easier to rehearse, audit, and execute under the 24-hour reporting pressure that begins on 11 September 2026.

Official sources