Known Exploited Vulnerabilities: How to Patch What Matters
Patching by evidence of exploitation, not by severity label.
Most vulnerability management programmes are losing. Disclosure volume continues to rise (north of 40,000 CVEs in 2024 alone), patching teams are not getting larger, and the ratio of “critical” to “actually exploited” continues to skew further apart. The result, in many organisations, is a backlog that grows faster than it shrinks and a sense that every vulnerability is urgent — which, in practice, means none of them are.
The Known Exploited Vulnerabilities approach reverses that logic. Instead of trying to patch everything that could be exploited, you patch what is being exploited, in priority order. It is one of the highest-leverage shifts available to a security programme, and it is largely free. This article explains why everything cannot be urgent, what KEV adds to prioritisation, and what a simple, defensible KEV-driven workflow looks like in practice.
Why everything cannot be urgent
The honest position is that no organisation patches every vulnerability immediately. The functional position is that organisations should choose what they patch first, by reference to evidence rather than by reference to CVSS base scores in isolation.
The numbers make the point. In any given year:
- More than 40,000 CVEs are published.
- A substantial proportion — typically 50% or more by some analyses — carry a CVSS base score of “high” or “critical”.
- Fewer than 5% are exploited in the wild within the first year of disclosure, according to EPSS data.
- The CISA KEV catalogue, which records confirmed in-the-wild exploitation, adds roughly 200–400 entries per year.
A programme that treats every “critical” as a true emergency will not have time to address the small set of vulnerabilities that are actually being weaponised. Worse, remediation teams stop trusting the prioritisation when the labelling is consistently wrong, and start working from feel rather than from the queue. That is the failure mode behind most of the high-profile UK incidents in 2024 and 2025: a CISA KEV entry, internet-facing, available to patch for weeks, exploited before it was deployed.
The shift is from “patch by severity” to “patch by evidence of harm”.
How KEV lists improve prioritisation
The CISA Known Exploited Vulnerabilities catalogue was established in November 2021. It is a curated list of vulnerabilities for which CISA has evidence of active exploitation. Inclusion requires three criteria: a CVE ID, evidence of active exploitation and clear remediation guidance.
The catalogue’s value is not in its sophistication. It is precisely the opposite — it is a simple, public, free, regularly updated dataset that answers one question reliably: “is this CVE actually being exploited right now?” For prioritisation purposes, that question matters more than almost any other.
What KEV does well:
- High signal-to-noise. Every entry is confirmed exploitation. No prediction, no inference.
- Vendor coverage. Edge devices, operating systems, browsers, productivity tools, and increasingly cloud and identity products are all represented.
- Free and machine-readable. The catalogue is available as JSON; integration into a vulnerability management workflow is trivial.
- Authoritative. Federal civilian agencies in the US are required to remediate KEV entries within defined timelines under Binding Operational Directive 22-01. This drives vendor responsiveness in a way that benefits everyone.
What KEV does not do:
- Predict future exploitation. That is what EPSS is for. Use both.
- Cover everything. Lower-profile exploitation, particularly of niche enterprise software, may not be reflected.
- Tell you whether the vulnerable component is reachable in your environment. That is your job.
The most common mistake when adopting KEV is to treat it as a replacement for the rest of vulnerability management. It is not. It is the top filter — the lens through which the rest of the backlog is read.
A simple KEV-driven workflow
A defensible, repeatable KEV-driven workflow does not require expensive tooling. It requires that the right data sources feed a small number of consistent decisions. A workable end-to-end process:
- Ingest the KEV catalogue continuously. It updates frequently. Pull the JSON daily into your vulnerability management or SOAR platform.
- Match KEV entries against your asset inventory. If you do not know what you run, you cannot match. An accurate asset inventory is a prerequisite, not an output.
- Expedite remediation for matched entries. Define a fast-lane SLA for KEV matches affecting your environment — for example, internet-exposed assets within 7 days, internal within 14. Federal CISA timelines are typically 14–21 days; UK organisations regularly choose tighter windows for internet-facing assets.
- Apply EPSS as a secondary signal. For vulnerabilities not yet on KEV, EPSS scores above an organisation-defined threshold (commonly 0.5 or 0.7) enter an expedited queue, on the basis that they are likely to be exploited soon.
- Apply environmental context. Use CVSS 4.0 Environmental metrics, or your own asset criticality model, to differentiate the same CVE on a tier-1 production system from the same CVE on a non-reachable lab box.
- Verify remediation. Close tickets only when the fix is verified — by re-scan, by re-test or by configuration evidence. “Patched” tickets that were never re-scanned are one of the most common findings in our engagements.
- Report on what was prevented, not just what was patched. A monthly report showing KEV entries closed, average time-to-remediate, and any KEV match still outstanding is far more useful to the board than a backlog count.
This workflow has two important properties. It is defensible — every decision points to an external, named reason — and it is bounded. Teams can see the end of the queue rather than facing an infinite list. Morale, accuracy and trust in the programme all improve as a result.
The final and most underrated element is the loop back to detection. For each KEV match in your environment, ask: “if we had not patched this in time, would we have detected the exploitation?” If the answer is no, that is the next investment.
Frequently asked questions
What is the CISA KEV catalogue?
A public, curated list of vulnerabilities with evidence of active exploitation, maintained by the US Cybersecurity and Infrastructure Security Agency since November 2021.
How often is KEV updated?
Frequently — multiple times per week is typical. Production workflows should ingest it daily.
Is KEV applicable to UK organisations?
Yes. The catalogue is product- and vulnerability-based, not jurisdiction-based. UK organisations use it widely, and NCSC guidance broadly aligns with prioritising known-exploited issues.
What is the difference between KEV and EPSS?
KEV records confirmed exploitation; EPSS predicts exploitation probability. Use KEV as the highest-priority signal and EPSS as a forward-looking complement.