Known Exploited Vulnerabilities: How to Patch What Matters
Patching by evidence of exploitation, not by severity alone
Vulnerability disclosure numbers continue to climb each year and patching teams cannot keep up. Tens of thousands of new CVEs were published in 2024; more than half carried "high" or "critical" CVSS base scores. Yet only a small fraction — typically under five per cent — are exploited in the wild within a year of disclosure【. When everything is labelled critical, nothing truly stands out. Remediation teams become overwhelmed and start working from intuition rather than evidence.
The Known Exploited Vulnerabilities (KEV) approach flips the problem. Instead of trying to patch every theoretical risk, organisations prioritise vulnerabilities with evidence of active exploitation. This article explains why you cannot treat every CVE as urgent, what the KEV catalogue adds to a prioritisation strategy, and how to combine KEV with Exploit Prediction Scoring System (EPSS) and contextual data to create a simple, defensible workflow.
Why everything cannot be urgent
No organisation can patch every vulnerability immediately. The evidence shows that vulnerability volume far outstrips capacity and that severity labels are poor predictors of real‑world exploitation. As Cloudsmith explains, EPSS models estimate the probability that a vulnerability will be exploited in the next 30 days. They demonstrate that a high CVSS score signals potential danger but does not indicate whether anyone is actually exploiting the issue. In practice:
- Tens of thousands of CVEs are disclosed annually, with more than half rated "high" or "critical" by CVSS.
- Only a small fraction of those vulnerabilities are exploited in the wild.
- The CISA KEV catalogue, which lists confirmed exploited vulnerabilities, usually adds hundreds rather than thousands of entries per year.
If every "critical" is treated as an emergency, remediation teams will miss the handful that matter most. Over‑prioritisation erodes trust in the queue and leaves organisations exposed to the very vulnerabilities attackers are actively abusing. Prioritisation must therefore be grounded in evidence of harm.
How KEV lists improve prioritisation
The CISA Known Exploited Vulnerabilities (KEV) catalogue was established in November 2021 under Binding Operational Directive (BOD) 22‑01. It is a curated list of vulnerabilities with evidence of active exploitation. A vulnerability must satisfy three criteria to be added: it must have a CVE identifier, there must be proof of active exploitation, and there must be clear remediation guidance. CISA updates the catalogue continuously and requires federal agencies to remediate new KEV entries within defined timelines; agencies must fix internet‑facing KEVs within 15 days and internal KEVs within 25 days.
KEV's value lies in its simplicity and authority. It answers one question reliably: Is this CVE being exploited right now? For prioritisation purposes, that question matters more than any theoretical severity metric.
What KEV does well:
- High signal-to-noise: Every entry reflects confirmed exploitation; there is no inference or prediction.
- Wide vendor coverage: Operating systems, edge devices, productivity software, browsers and cloud services are all represented.
- Free and machine-readable: The catalogue is published in JSON and can be ingested into vulnerability management tools easily.
- Mandated remediation: Federal agencies in the United States must remediate KEV entries within specific time frames, which pressures vendors to release patches quickly.
What KEV does not do:
- Predict future exploitation: KEV is historical. To gauge future risk, use EPSS, which estimates the likelihood of exploitation in the next 30 days using machine‑learning models.
- Cover every exploited vulnerability: Low‑profile incidents or niche enterprise software may not be captured.
- Account for your environment: KEV does not tell you whether a vulnerable component is actually exposed in your network; that analysis is still required.
Treat KEV as a top filter, not a replacement for the rest of vulnerability management. It identifies vulnerabilities that demand immediate attention, but you still need to evaluate reachability, apply contextual risk factors and plan remediation.
A simple KEV-driven workflow
You do not need expensive tooling to adopt a KEV-centric approach. A defensible workflow requires that the right data sources feed consistent decisions:
- Continuously ingest the KEV catalogue. Subscribe to CISA alerts and pull the machine‑readable KEV JSON daily.
- Match KEV entries against your asset inventory. Accurate inventory is a prerequisite — you cannot prioritise what you do not know.
- Prioritise remediation. Define a fast lane for KEV matches: internet‑exposed assets patched within a week, internal assets within two weeks, aligning with or exceeding CISA timelines.
- Use EPSS for forward-looking prioritisation. Apply EPSS as a secondary signal for CVEs not yet on KEV. High EPSS scores (e.g., >0.5) indicate a higher probability of exploitation in the next 30 days and warrant expedited patching.
- Apply contextual risk factors. Use CVSS 4.0 Environmental metrics or your own asset criticality model to distinguish the same CVE on a critical production server from one on a disconnected test machine.
- Verify remediation. Close tickets only after verification through re‑scan or re‑test. "Patched" tickets without evidence of closure are a common failure point.
- Report outcomes, not backlog size. Track metrics such as KEV entries remediated, time to remediate and outstanding KEV matches. Reporting what was prevented — not just how many tickets remain — builds confidence with leadership.
This workflow has two important properties: it is defensible — every decision is tied to an external source such as KEV or EPSS — and it is bounded, so teams can see the end of the queue rather than an infinite list. The EPA's cybersecurity guidance for water and wastewater systems recommends receiving CISA alerts and prioritising the KEV list as part of a proactive threat detection strategy. Embedding KEV into your workflow aligns with that guidance.
Finally, use KEV as a feedback loop. For each KEV match in your environment, ask: If we had not patched this in time, would we have detected exploitation? If the answer is no, improving detection should be your 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.