KEV does not include every exploitable vulnerability: it includes those with confirmed and published exploitation. It is a conservative catalogue, explicitly stated as such by CISA. A vulnerability not in KEV may still be exploited without CISA having registered it yet.
What KEV is
KEV (Known Exploited Vulnerabilities) is the public catalogue maintained by CISA (the United States federal cybersecurity agency) with the vulnerabilities whose real-world exploitation has been confirmed. Unlike the CVE database, which records every published vulnerability regardless of operational impact, KEV only includes those being used or that have been used in observable attacks. The catalogue was created in 2021 with an operational directive for U.S. federal agencies, but today it is used internationally as a prioritisation reference by any serious organisation managing vulnerabilities, because it answers a very specific question: is this being used today against anyone?
Why it matters
A typical security team has thousands of open findings at any moment. Without a useful priority criterion, that queue gets handled by CVSS and capacity ends up devoted to patching theoretical risks while a medium-severity vulnerability is being actively exploited against the sector. KEV is the list that says "this is happening now" and therefore must appear in any remediation policy as immediate priority, above the standard SLAs. For frameworks like NIS2, DORA or ENS that require risk-based prioritisation, KEV is also one of the strongest pieces of evidence that such prioritisation is not theoretical but follows public evidence.
Key points
Each KEV entry includes inclusion date, brief technical description and, in most cases, a recommended remediation deadline. That deadline is binding for U.S. federal agencies; for everyone else it is a useful urgency reference.
KEV updates frequently and not on a fixed schedule. Vulnerability management platforms must consult it at least daily to enrich their findings: a CVE can move from "medium" to "urgent treatment" within hours of being added.
Combined with EPSS, KEV produces a very effective operational rule: "anything in KEV is treated as urgency; anything with EPSS above 0.5 is prioritised; the rest follows the standard SLA". That rule, kept as written policy, usually shrinks the critical queue to less than half.
KEV is especially useful for conversations with leadership and auditors. It is public, maintained by a recognised agency, and translates "I have five thousand open CVEs" into "I have six CVEs in KEV unpatched" — a metric any committee can act on.
It is worth combining KEV with sector-specific threat intelligence. KEV is global; a good programme adds country or industry-specific feeds (CCN-CERT in Spain, ENISA in the EU, private lists) that may move ahead of the official inclusion when the attack targets a specific country or industry.
Example: using KEV in a remediation policy
An organisation with a heterogeneous estate (cloud, on-premise infrastructure, several SaaS providers) writes its vulnerability management policy with three tiers. Tier 1: any CVE that appears in KEV requires remediation or compensating mitigation within 72 hours, with notification to the CISO and the asset owner. Tier 2: any CVE with EPSS above 0.5 enters an accelerated queue of 7 days. Tier 3: everything else follows the standard SLA based on CVSS and asset criticality.
On the first day after publishing the policy, the team detects two internet-facing servers affected by a CVE just added to KEV. Compensating mitigation is applied (a WAF rule plus port restriction) in less than 24 hours and the definitive patch is scheduled within the deadline. The metric presented to the committee is simple: "zero KEV vulnerabilities without containment"; the committee understands it without technical translation. The same evidence (KEV entries covered and deadlines met) feeds the next audit as proof of risk-based prioritisation.
Common mistakes
- Treating KEV as a complete list of real-world threats. A vulnerability can be actively exploited without having entered KEV yet. Inclusion is a strong urgency signal, but absence does not mean safety.
- Ignoring the recommended deadlines. CISA publishes a remediation date with each entry precisely because of the urgency of confirmed risk. Treating that date as advisory cancels the catalogue's main value.
- Waiting for KEV inclusion before acting. For vulnerabilities with high EPSS or known public exploits, waiting for CISA to confirm exploitation is equivalent to handing the attacker an advantage.
- Centralising the decision in the security team alone. KEV entries should fire automated tickets to asset owners (IT, development, SaaS provider) with written deadlines and clear escalation if missed.
- Not mapping KEV to regulatory frameworks. When 'open CVEs in KEV' translates to 'ISO 27001 A.8.8 controls in breach', the metric travels through the organisation on its own and gets the weight it deserves.
Related terms
Related services
This concept may be related to services such as:
Frequently asked questions
Is a vulnerability never included in KEV safe to leave unpatched?
No. KEV is a conservative catalogue that only includes vulnerabilities with confirmed and published exploitation by CISA. Many vulnerabilities are exploited silently for weeks before appearing in the catalogue, and others are exploited in specific regions without ever being added. KEV is a strong signal of immediate priority; absence is not proof of safety.
How is KEV integrated into a vulnerability management tool?
Modern platforms automatically consume the public KEV feed and enrich each finding with a boolean flag ('in KEV') and the recommended remediation date. If the organisation still consumes plain CVE data without enrichment, the priority is to enable the integration or its equivalent script: the feed is public, open and updated daily.
Does it make sense to apply KEV outside the United States?
Yes. Although KEV was born as an operational obligation for U.S. federal agencies, exploited vulnerabilities do not respect borders. Any organisation outside the United States can use KEV as an operational urgency reference, usually combined with its national CERT feed (CCN-CERT in Spain, ENISA in the EU).
Does KEV replace commercial threat intelligence?
No, they operate at different levels. KEV is an official, conservative catalogue centred on specific CVEs with confirmed exploitation. Commercial intelligence adds actors, campaigns, TTPs and private telemetry that can move ahead of KEV inclusion. A mature programme uses both: KEV as an indisputable reference and CTI for anticipation.