What “actively exploited” means, and where KEV and EPSS fit

In short: The CRA defines an actively exploited vulnerability as one with “reliable evidence that a malicious actor has exploited it”. A CISA KEV listing is evidence of exploitation in the wild; an EPSS score is a prediction. Neither is named in the regulation, and neither tells you whether your product is affected: a person has to decide, and the time they became aware starts the clock.

The definition

“‘actively exploited vulnerability’ means a vulnerability for which there is reliable evidence that a malicious actor has exploited it in a system without permission of the system owner”
Article 3(42), Regulation (EU) 2024/2847

Three things have to hold: there is reliable evidence, a malicious actor did it, and it happened in a system without permission. Security research, scanning and proof-of-concept code don't meet that bar. The regulation separately defines an exploitable vulnerability, one that “has the potential to be effectively used by an adversary” (Article 3(41)), and only the exploited kind triggers the 24-hour early warning.

Known is not exploited

A dependency scanner reports known vulnerabilities: every advisory that matches a package version you use. For a typical lockfile that is a steady stream, and almost none of it is exploited in the wild. Reporting each one would be wrong and would bury the reports that matter. Ignoring them all would miss the one that does.

CISA KEV: evidence of exploitation in the wild

The US Cybersecurity and Infrastructure Security Agency keeps the Known Exploited Vulnerabilities catalogue. A vulnerability is added only when, according to CISA's criteria, it has a CVE ID, “there is reliable evidence that the vulnerability has been actively exploited in the wild”, and there is a clear remediation, such as a vendor update.

That is close to the CRA's wording, which makes KEV the strongest public signal you have. It is still not a decision: KEV says the vulnerability has been exploited somewhere, not that your product is affected. Whether your product uses the vulnerable code in a way that exposes it is your assessment. KEV is also a US list and covers only vulnerabilities with a CVE.

EPSS: a prediction, not evidence

FIRST's Exploit Prediction Scoring System “estimates the probability a vulnerability will be exploited in the wild within the next 30 days”. Scores run from 0 to 1 and are updated daily; per FIRST, a score of 0.05 means a 5% estimated probability of observed exploitation activity in the next 30 days.

A high EPSS score is a good reason to look first. It is not “reliable evidence that a malicious actor has exploited it”, so on its own it does not make a vulnerability actively exploited.

Awareness starts the clock

The early warning is due “within 24 hours of the manufacturer becoming aware” (Article 14(2)(a)). Neither KEV nor EPSS is mentioned in the regulation, so a listing doesn't start the clock by itself; your awareness of reliable evidence does. That makes two things worth recording every time: what you knew, and when a person concluded that it was exploited.

A workable routine

Keep an SBOM of what you shipped, per version.
Re-check it regularly against new advisories, KEV and EPSS. New advisories appear long after you ship.
Treat a KEV listing or a high EPSS score as a prompt: is the vulnerable code in your product reachable?
When a person concludes there is reliable evidence of exploitation affecting your product, record who and when, and send the early warning within 24 hours. See the reporting deadlines.