CISA adds a vulnerability to its Known Exploited Vulnerabilities (KEV) catalog when three conditions hold: it has an assigned CVE ID, there is reliable evidence of active exploitation in the wild, and there is a clear remediation action. Proof of concept code or scanning alone does not qualify.
The three conditions in plain words
CISA states the criteria on its KEV page. Here they are, with what each means for you as a reader of the catalog.
| Condition | CISA's wording, shortened | What it means in practice |
|---|---|---|
| CVE ID | The vulnerability has an assigned CVE ID | It is tracked in the standard CVE system, so you can match it to your inventory |
| Exploited | Reliable evidence of active exploitation in the wild | Someone actually ran malicious code against a system without the owner's permission |
| Fix exists | A clear remediation action, such as a vendor update | There is something concrete you can do, including removing an end-of-life product |
CISA also clarifies what does not count as exploitation: scanning, security research and proof of concept code.
Why the third condition surprises people
A vulnerability can be exploited and still be missing from KEV if no clear fix exists yet. That is a gap in the catalog by design. KEV is an action list for defenders. Every entry comes with something to do.
This matters when you use KEV as a gate. An empty result means "nothing confirmed exploited with a known fix has been listed", which is narrower than "nothing is being exploited".
What an entry contains
From the catalog page, each entry carries the vendor and product, the CVE ID and link, a name and description, related CWEs, whether it is known to be used in ransomware campaigns (yes, no or unknown), whether forensic triage is required under BOD 26-04, the date added, a due date, the required action, and notes such as vendor advisories.
The due date is what makes KEV different from a score. For US federal agencies it is a deadline. For everyone else it is a strong prioritization signal, which CISA encourages when it says organizations should use the catalog as an input to their vulnerability management prioritization.
A worked reading
Suppose a new entry appears for a web framework library you use. Walk it through:
- Is the product and version in your SBOM? Match the CVE ID against your component list.
- Is the vulnerable code reachable in your build? A reachability check can separate real exposure from a library that is present but unused.
- What does the required action say? Apply the vendor update, or remove the product.
- Check the ransomware field and the forensic triage flag to decide how urgent an investigation is.
- Record the due date in your tracker, even if you are not a federal agency, so the fix has a clock.
For deeper context on how KEV timelines work, see CISA KEV remediation timelines and the KEV catalog overview.
Try it yourself
Open the demo and look at how a finding list is triaged by exploitation evidence and fix availability.
Click through it at your own pace, or open it full screen.
Safeguard's SBOM and dependency scanning lets you match KEV entries to the components you actually ship. The free scan is at gold.safeguard.sh/scan.
Quick check
Does a public proof of concept put a CVE in KEV?
No. CISA says scanning, research and proof of concept code do not count as active exploitation.
Can KEV be used as a complete list of exploited vulnerabilities?
No. An exploited CVE without a clear remediation, or one CISA has not yet assessed, can be absent.
Sources
Last reviewed: 19 October 2026.
