The CRA's reporting obligation hangs on two words: actively exploited. They decide when a 24-hour clock starts, and they are easy to get wrong in both directions. Over-read them and you flood your CSIRT with reports on vulnerabilities nobody is using; under-read them and you miss a genuine obligation with a €15M ceiling behind it.
The bar
A vulnerability is actively exploited when there is reliable evidence that a malicious actor has exploited it in a system, without the owner's authorisation. Two parts matter. It requires evidence, not suspicion. And it requires real exploitation, not the demonstrated possibility of it. This is a factual claim about the world — someone is doing this — rather than a risk assessment.
What clears the bar
- A CISA KEV listing. The Known Exploited Vulnerabilities catalogue adds entries on evidence of exploitation in the wild — the strongest, most citable signal available.
- Credible threat intelligence reporting exploitation in the wild, from a vendor, CERT, or your own detections.
- Your own incident evidence that the vulnerability has been exploited against your product or infrastructure.
What doesn't
- A newly published CVE. Existence is not exploitation.
- A public proof-of-concept. It shows exploitation is possible, not that it has happened.
- A high CVSS score. Severity describes impact-if-exploited, not activity.
- A high EPSS score. That's a prediction of likely exploitation, not evidence of actual exploitation.
Actively exploited is a statement of fact, not of risk. PoCs, high scores and predictions raise your attention; they don't start the clock.
Exploited in the wild is not the same as affects you
Even a clear-cut actively-exploited vulnerability only creates a reporting obligation if it affects your product. A KEV-listed flaw in a library you ship may not be reachable in your build, or may not be triggerable in your configuration. Active exploitation starts the assessment; whether your product is actually affected is the second question — the one answered by reachability and exploitation evidence. Both have to be true before you file.
Wiring it to the clock
Because the bar is evidence-based and time-critical, the operational move is to watch the sources that carry that evidence — KEV and threat intelligence — against the components in your products, and raise a timed, auditable alert the moment one crosses the line. That's the piece that turns a definition into a working 24-hour process; the mechanics are in correlation and active-exploitation detection.
Frequently asked
What does "actively exploited" mean under the CRA?
A vulnerability is actively exploited when there is reliable evidence that a malicious actor has exploited it in a system without the owner’s authorisation. It is exploitation in the wild, not the theoretical possibility of exploitation.
Does a public proof-of-concept make a vulnerability actively exploited?
No. A published PoC demonstrates that exploitation is possible; it is not evidence that an attacker has used it against real systems. On its own it does not start the CRA clock, though it may raise the likelihood that active exploitation follows.
Is a CISA KEV listing enough to trigger CRA reporting?
A KEV listing is a strong signal that the active-exploitation bar is met, because KEV entries are based on evidence of exploitation in the wild. It still has to affect your product for a reporting obligation to arise — active exploitation somewhere is necessary but not sufficient.