What counts as “reliable evidence”?

The CRA does not spell this out. In practice it means evidence showing actual exploitation: log entries with a matching attack pattern, forensic findings on an affected system, a credible report from a customer or a CSIRT. Mere suspicion is not enough, but a fully confirmed compromise is not required either.

Does a public proof of concept already count as active exploitation?

No. A published exploit makes a vulnerability exploitable, not actively exploited. The reporting duty applies only once there is evidence that someone actually used it without the system owner’s permission. In practice a public proof of concept should still raise your urgency, because the likelihood of the second step following rises sharply.

What if the exploitation happens at a customer rather than at us?

The definition turns on the vulnerability in the product, not on where the incident occurs. If your software is attacked at a customer site, the vulnerability is actively exploited and the clock runs from the moment you become aware. A workable process therefore has to route customer reports to the right people quickly.

Cyber Resilience Act

Actively exploited vulnerability

Legal definition Art. 3(42) CRA

“a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner”

Regulation (EU) 2024/2847, Art. 3(42) CRA

An actively exploited vulnerability is the only vulnerability state to which the Cyber Resilience Act (CRA) attaches a reporting deadline. The definition requires three things at once: reliable evidence, a malicious actor, and exploitation without the system owner’s permission.

That last element cleanly excludes penetration tests and commissioned security assessments: there, exploitation happens with permission. No reporting duty arises.

What follows from it

The CRA attaches a staged reporting duty to it. Once a Manufacturer becomes aware of an actively exploited vulnerability in its product, it notifies the CSIRT designated as coordinator and ENISA simultaneously, through the single reporting platform. The sequence has three stages:

without undue delay and in any event within 24 hours, an early warning naming, where applicable, the Member States on whose territory the manufacturer is aware the product has been made available
without undue delay and in any event within 72 hours, a notification with general information, as available, about the product, the nature of the exploitation and any measures already taken
no later than 14 days after a corrective or mitigating measure is available, a final report covering at least the vulnerability with its severity and impact, any available information on the malicious actor, and the security update made available to remedy it

What starts the clock is becoming aware, not the time of the attack. Learning of an incident weeks later starts the clock only at that moment. The 24 hours are an outer limit rather than a budget, because the notification is due without undue delay.

Why 24 hours is an organisational problem

The deadline runs in calendar time, not working days. A report on Friday evening means a notification by Saturday evening. That is only achievable if three things are settled in advance: who may trigger a notification, how that person is reached outside office hours, and whether the product details required for the early warning are readily at hand.

The bottleneck is rarely technical; it is the decision. Working out whether a finding crosses the threshold while the clock is already running costs exactly the hours the deadline consists of.

Distinguishing it from an incident

The CRA has a second reporting duty for severe incidents affecting the security of a product. The deadlines are structured similarly, but there the final report is due within one month of the 72-hour notification.

Both duties can cover the same events: an actively exploited vulnerability that led to a compromise is also an incident affecting product security. One notification does not replace the other.

Practical questions

: The CRA does not spell this out. In practice it means evidence showing actual exploitation: log entries with a matching attack pattern, forensic findings on an affected system, a credible report from a customer or a CSIRT. Mere suspicion is not enough, but a fully confirmed compromise is not required either.
: No. A published exploit makes a vulnerability exploitable, not actively exploited. The reporting duty applies only once there is evidence that someone actually used it without the system owner’s permission. In practice a public proof of concept should still raise your urgency, because the likelihood of the second step following rises sharply.
: The definition turns on the vulnerability in the product, not on where the incident occurs. If your software is attacked at a customer site, the vulnerability is actively exploited and the clock runs from the moment you become aware. A workable process therefore has to route customer reports to the right people quickly.

This glossary is for orientation and does not constitute legal advice. The wording of Regulation (EU) 2024/2847 prevails.