What the KEV catalog actually is
The Known Exploited Vulnerabilities catalog is a list, published and continuously updated by the US Cybersecurity and Infrastructure Security Agency, of CVEs that are confirmed to have been exploited in the wild. Not theoretically exploitable. Not high-scoring. Observed, in real attacks.
That distinction is the entire value. A CVSS score is an assessment of how bad a vulnerability would be if someone used it. KEV membership is evidence that someone did. For a team deciding what to patch this week, the second is a far stronger signal than the first.
For US federal civilian agencies the catalog is not advisory: Binding Operational Directive 26-04 requires them to prioritise remediation of KEV-listed CVEs on defined timelines (CISA). Everyone else gets the same list for free, without the deadline. Most organisations do not use it.
Why CVSS alone sends you to the wrong place
CVSS answers "how severe would this be?" It does not answer "is anyone doing it?" — and those two questions produce different queues.
A CVSS 9.8 in a library you compile out, on a host with no inbound path, is a number. A CVSS 7.5 in the VPN appliance at your perimeter, listed in KEV last Tuesday, is your weekend. Sorting by severity puts the first one at the top of the list.
This is not an argument against CVSS. It is an argument against using one dimension as a queue. Severity tells you the consequence; exploitation status tells you the probability; your own architecture tells you the reachability. A queue built on only one of the three is guessing with confidence.
Where EPSS and SSVC fit
Two other signals are worth wiring in, and they answer different questions.
- EPSS (Exploit Prediction Scoring System) estimates the probability that a CVE will be exploited in the near term. It is predictive, so it covers the window before something reaches KEV.
- SSVC (Stakeholder-Specific Vulnerability Categorization) is a decision framework rather than a score: it walks you from exploitation status and exposure to an action — act now, schedule, track.
The practical combination is simple. KEV tells you what is being used. EPSS tells you what is likely to be used next. SSVC gives you a defensible route from those inputs to a decision your change board will accept. A CVE that is both in KEV and high on EPSS is not a prioritisation question; it is an incident with a patch available.
A workflow that survives a real backlog
The failure mode of every "prioritise by exploitation" article is that it assumes you know what you run. Most teams do not, precisely. So the workflow has to start earlier than the catalog.
- Know what is exposed. Reconcile your asset inventory against what is actually reachable from the internet. Certificate transparency and DNS will show you hosts your inventory has forgotten — this is the step people skip, and it invalidates everything after it.
- Match KEV against the exposed set first. A KEV entry for software you run but never expose is a scheduled patch. The same entry on a perimeter device is today's work.
- Confirm the version, not the banner. Fingerprinted versions are a strong signal, not proof — backported fixes routinely make a host look vulnerable when it is not, and vice versa.
- Fix, then verify by testing. A patched package is not the same as a closed path. Re-test the exposure rather than trusting the change ticket.
- Automate the arrival, not the decision. New KEV entries should reach your queue without a human refreshing a web page. Whether to act stays a human call.
The gap KEV does not cover
KEV is a lagging indicator by construction: a CVE lands there once exploitation has been observed and confirmed. That is what makes it trustworthy, and it is also its limitation. Between the first exploitation of a zero-day and its appearance in the catalog, you are on your own.
Three things narrow that window. Vendor advisories, which arrive first for the products you actually run. EPSS, which moves before confirmation. And knowing your own exposure well enough that when an advisory drops, you can answer "do we run that, and is it reachable?" in minutes rather than days. The last one is entirely within your control and is the only one that is free.
The window is also where a curated feed earns its keep. We publish every new KEV entry with an action plan attached on ZeroDayAlert — the facts quoted from CISA, the guidance written around them.
What to do this week
If your vulnerability programme is a spreadsheet sorted by severity, one change will improve it more than any tool purchase: add a column for exploitation status, populate it from KEV, and re-sort. Most teams discover that their genuine top-ten looks nothing like their previous top-ten, and that several items sitting at the top were never worth the argument.
Frequently Asked Questions
What is the CISA KEV catalog?
A continuously updated list, published by the US Cybersecurity and Infrastructure Security Agency, of CVEs confirmed to have been exploited in real attacks. It is free and public, and it is the strongest available signal that a vulnerability matters right now.
Is KEV better than CVSS for prioritisation?
They answer different questions. CVSS estimates how bad exploitation would be; KEV states that exploitation has been observed. Use exploitation status to order the queue and severity to size the consequence.
How does EPSS differ from KEV?
EPSS predicts the probability of exploitation in the near term, so it moves before confirmation. KEV records exploitation after it has been confirmed. EPSS covers the window KEV cannot.
Do non-US organisations need to care about KEV?
The binding directive applies to US federal civilian agencies, but the catalog is public and the attackers it describes are not geographically limited. It is one of the few genuinely free, high-quality inputs available to any team.
How quickly should a KEV-listed vulnerability be patched?
Federal deadlines are defined by directive; for everyone else the sensible rule is exposure-based. On an internet-facing asset, treat it as an incident with a patch already available rather than as a scheduled change.