It depends on the source. For the CISA KEV catalog, scanning does not count, but attempted exploitation does, and a hit on a honeypot counts as an attempt. EPSS also records attempts, such as honeypot captures and blocked intrusion signatures, as exploitation activity. A proof of concept alone counts for neither.
CISA's definitions
CISA's KEV criteria page separates the terms carefully.
| Event | Counts for KEV? | CISA's description |
|---|---|---|
| Scanning | No | Listed as not active exploitation |
| Security research of an exploit | No | Listed as not active exploitation |
| Public proof of concept | No | Code that would allow exploitation, shared among researchers and vendors |
| Attempted exploitation | Yes | An attacker runs code against a target, but it fails because the system is not vulnerable or is a honeypot |
| Successful exploitation | Yes | The attacker takes unauthorized actions on the system or network |
CISA says active exploitation and exploited are synonymous for KEV, and that it includes attempted and successful exploitation. The two key points are that the actor intends to succeed and that the attack happens in real time, in the wild. It adds that successful code execution on a honeypot is considered attempted exploitation because the attacker gets no real target data.
EPSS uses a similar idea with a different job
FIRST says the exploitation data behind EPSS comes from endpoint malware telemetry, honeypots, intrusion detection and prevention telemetry, and threat intelligence feeds. These record exploitation activity, not necessarily success. FIRST notes that honeypots are designed to be attacked and IPS devices block what they see, and argues that a blocked attempt reflects the same attacker decision as a successful one.
So both systems treat intent plus real world action as the signal. The difference is purpose. KEV is a curated list for action. EPSS is a model that learns from activity to forecast the next 30 days.
Why the line between scanning and attempts matters
Internet wide scanning is constant background noise. If every scan counted, a catalog would list nearly everything. The test is whether code was run against a target to exploit a flaw. A probe that only asks whether a service answers is a scan. A request carrying an exploit payload is an attempt.
Reading a vendor notice
When a notice says exploited, ask which meaning it uses.
- Is it describing attempts seen by sensors, or compromises of real systems?
- Is the evidence from the vendor's own telemetry or a third party?
- Does it say whether customers were affected?
These questions shape your response. Attempts against exposed systems still raise urgency, because the same attackers will try yours. A confirmed compromise adds a need to check whether you were hit before you patched.
Using this in a policy
Define the term once in your vulnerability policy and link it to your triggers. For example, list KEV membership as one trigger and a vendor statement of exploitation as another, and say that scanning reports alone are not a trigger. This stops arguments in the middle of an incident.
Safeguard's asset discovery and reachability analysis help answer whether the affected product or code is in your estate at all. You can try a free scan at gold.safeguard.sh/scan.
Quick check
Is an internet scan for a vulnerable version exploitation?
Not under CISA's KEV definition, which lists scanning as not active exploitation. A payload run against a target would be an attempt.
Why does EPSS count blocked attempts?
FIRST says a blocked attempt reflects the same attacker decision to target a vulnerability as a successful one, so the activity is the signal regardless of outcome.
Sources
Last reviewed: 19 October 2026.
