What Is the CISA KEV Catalog?

The CISA Known Exploited Vulnerabilities catalog is, structurally, a short list with a long shadow. The Cybersecurity and Infrastructure Security Agency published it in November 2021 under Binding Operational Directive 22-01, which required federal civilian executive branch agencies to remediate every entry within defined deadlines. Since then it has grown into a reference point that reaches well beyond those agencies — security teams use it to prioritize patching, vendors reference it to explain product roadmaps, and the infosec community watches it to understand what’s actually being exploited in the real world, not just what scored highest on a chart.

Knowing what the catalog is and how it works is not esoteric knowledge. It’s table stakes for anyone managing infrastructure right now.

What the KEV Catalog Is

The KEV catalog is CISA’s authoritative list of CVEs — Common Vulnerabilities and Exposures — with confirmed evidence of active exploitation in the wild. It covers vulnerabilities across virtually every major software vendor. The full catalog is available at the CISA website and published as a machine-readable JSON feed; it is updated multiple times per week as exploitation is confirmed.

What the catalog is not is a severity ranking. A CVE doesn’t land in the KEV because it scored a 9.8 on the CVSS base scale. It lands there because someone is actively using it against real targets. CVSS scores measure potential impact in a reference scenario; KEV status measures observed reality. A medium-severity vulnerability that’s being used in ransomware campaigns will make the catalog. A critical-rated flaw with no known exploitation won’t — at least not yet. If the distinction between CVSS scores and actual exploitation likelihood is new to you, the related piece on how CVSS scoring works covers that ground.

How a CVE Gets Added

CISA applies two criteria for adding a CVE to the catalog:

1. The vulnerability must have a CVE ID assigned.
2. There must be credible evidence of active exploitation in the wild.

The phrase “credible evidence” carries weight. CISA typically relies on reports from its own incident response teams, coordination with federal agencies, threat intelligence from commercial and government partners, and published research from security vendors and incident responders. A single unverified claim doesn’t qualify; a pattern of confirmed exploitation that CISA can stand behind does.

Many entries include a required action and a remediation due date. Under BOD 22-01, civilian executive branch agencies must remediate KEV entries by the stated deadline or apply compensating controls and document the exception. The directive applies to those agencies; it does not directly compel state, local, or private-sector organizations. CISA explicitly recommends — and, increasingly, regulators and insurers effectively require — that all organizations treat the catalog as a prioritization guide.

Why It Matters Beyond Federal Agencies

The catalog is free, public, and machine-readable. That matters. Any vulnerability management platform worth using ingests the KEV JSON feed directly, surfacing catalog status alongside CVSS scores in dashboards. Tenable, Qualys, Rapid7, and most enterprise scanner tools have KEV integration. The same is true of EPSS — the Exploit Prediction Scoring System published by FIRST.org — which offers a probabilistic counterpart: where KEV confirms exploitation already happened, EPSS estimates how likely it is that a given CVE will see exploitation in the next 30 days. The two together give a clearer picture of actual risk than either alone.

Regulatory and insurance frameworks have begun treating KEV entries as an elevated tier. Cyber insurers conducting underwriting assessments will ask about unpatched KEV entries specifically; compliance regimes tied to federal contracting increasingly reference BOD 22-01 scope even for non-federal contractors. The practical result is that KEV status has moved from “something CISA cares about” to “something auditors care about,” which is a different kind of pressure.

The catalog also functions as a threat intelligence signal. When a vulnerability moves from NVD to KEV, it’s a public acknowledgment that the threat is active. The lag between a CVE’s NVD publication date and its KEV addition date is informative on its own: a short lag — days to a couple of weeks — suggests exploitation began quickly, which typically indicates a widely-deployed target, a low-friction attack path, or both. A long lag before KEV addition sometimes reflects a vulnerability that’s been exploited in narrow, targeted campaigns for some time before widespread confirmation.

How to Use the Catalog

Patch managers and sysadmins: Cross-reference the KEV catalog against your asset inventory every week. Any entry that affects software you’re running should move to the front of the patch queue, ahead of unconfirmed-exploitation CVEs regardless of their CVSS score. The deadline columns are for federal agencies; the underlying message applies to anyone running the same software.

SOC teams: A KEV entry for a vulnerability affecting your environment is a trigger for a hunt query, not just a ticket. Check logs for exploitation indicators before assuming you’re clean. If the entry includes specific IOCs or detection guidance in the associated advisory, pull those too.

Procurement and vendor management: If a vendor’s product appears in the KEV catalog — especially for a vulnerability that was exploited before a patch was available — treat that as a data point about the vendor’s disclosure practices and response timelines.

Risk and compliance teams: BOD 22-01 deadlines are a useful floor for remediation SLAs even in non-federal environments. If CISA sets a 14-day remediation window for a given CVE, that’s a reasonable baseline for internal escalation criteria.

The KEV Tracker on this site surfaces recent catalog additions, current remediation deadlines, EPSS scores, and links to NVD and CISA advisory entries — sorted and filterable, without needing to parse the raw JSON feed.

What the KEV Catalog Doesn’t Cover

The catalog is one input, not a complete vulnerability management strategy. It covers exploitation that has already been confirmed and reported to CISA; a zero-day used in a narrow targeted campaign might not make the list for weeks, if it ever does. A vulnerability absent from the KEV catalog is not necessarily safe to ignore, particularly for high-value targets operating against sophisticated adversaries.

The catalog is also limited to CVEs. Misconfigurations, credential reuse, and architectural weaknesses — which account for a substantial share of successful intrusions — fall outside its scope entirely.

The EPSS score from FIRST.org fills part of the gap by modeling exploitation likelihood for CVEs not yet on the KEV list. A CVE with a high EPSS probability is worth elevated attention even without a KEV entry.

---

The KEV catalog has become one of the cleaner examples of a government security product that gets used beyond government because it solves a specific, tractable problem: defenders needed an authoritative list of vulnerabilities that are actively on fire, maintained by people with access to real incident data. That’s what it is. It won’t catch everything. But it catches the things that are already catching people.