Patch what attackers are actually using: a practical guide to the CISA KEV catalog
Tens of thousands of CVEs are published every year, and no team can patch them all on time. CISA’s Known Exploited Vulnerabilities catalog narrows the list to flaws with confirmed real-world exploitation. This guide explains what KEV is, what it isn’t, and how to build a patching process around it.
Every year brings tens of thousands of newly published CVEs. Most organizations have a backlog of vulnerability scanner findings measured in the thousands, and a severity score alone doesn’t tell you which ones matter this week. The question that actually drives risk is simpler: is anyone exploiting this right now?
That is the question CISA’s Known Exploited Vulnerabilities (KEV) catalog answers.
What KEV is
KEV is a public list, maintained by the U.S. Cybersecurity and Infrastructure Security Agency, of vulnerabilities that have been exploited in the wild. A vulnerability is added only when three conditions are met: it has an assigned CVE ID, there is reliable evidence of active exploitation, and there is clear remediation guidance such as a vendor patch or mitigation.
Under Binding Operational Directive 22-01, U.S. federal civilian agencies must remediate KEV entries by the due date CISA sets for each one, often within a few weeks and sometimes within days for the most urgent flaws. Private organizations aren’t bound by the directive, but the catalog is free, machine-readable, and arguably the most useful single prioritization signal available.
What KEV isn’t
It isn’t complete. KEV includes only exploitation CISA can confirm. A vulnerability not on the list may still be exploited; it just hasn’t been verified publicly yet.
It isn’t a severity ranking. Some KEV entries have moderate CVSS scores. They’re on the list because attackers use them, often as one link in a chain. A medium-severity flaw being exploited is usually more urgent than a critical one that isn’t.
It isn’t a substitute for asset inventory. KEV tells you what’s dangerous. Only your inventory tells you whether you run it.
Building a KEV-driven patching process
1. Match KEV against your inventory continuously. Most vulnerability scanners can tag KEV findings. If yours can’t, the catalog is available as JSON and CSV and is easy to cross-reference. Set a daily check, because new entries can land any day of the week.
2. Set your own due dates. A reasonable baseline for most organizations: internet-facing systems on KEV within 72 hours, internal systems within 14 days, and everything else in the normal patch cycle. When CISA sets a shorter federal deadline, treat that as a signal of urgency.
3. Put internet-facing edge devices first. VPN gateways, firewalls, and remote-access appliances show up in KEV repeatedly and are reachable by anyone. A KEV entry for one of these warrants an out-of-cycle change.
4. Patch, then hunt. Many KEV entries were exploited before a patch existed. After remediating, check logs on the affected system back to the earliest reported exploitation date.
5. Track what you can’t patch. End-of-life systems and vendor delays happen. Record compensating controls, such as isolating the system, restricting access, or adding monitoring, and set a review date.
6. Report on KEV exposure, not total CVE count. “Zero internet-facing KEV findings older than 72 hours” is a metric leadership can understand and that actually reflects risk.
Where to follow KEV
ThreatGrid tracks KEV additions daily. The security bulletins page and the live threat ticker in the site footer are fed by the catalog, and MSSP clients get KEV entries matched against their monitored assets in TLINK PRO automatically. If you’d like help building a prioritization process around KEV, start with an assessment.
Sources: CISA Known Exploited Vulnerabilities Catalog (cisa.gov/known-exploited-vulnerabilities-catalog); CISA Binding Operational Directive 22-01.