What Is the CISA Known Exploited Vulnerabilities (KEV) Catalog?

What Is the CISA KEV Catalog?

The CISA Known Exploited Vulnerabilities (KEV) catalog is a curated list of CVEs that the Cybersecurity and Infrastructure Security Agency (CISA) has confirmed are being actively exploited in the wild. Each entry in the catalog represents a vulnerability where exploitation has been verified through CISA's own analysis, reports from trusted government and private-sector partners, or direct observation of exploitation activity affecting federal systems or critical infrastructure. The KEV catalog is not a prediction. It is a confirmation that exploitation is happening now or has happened recently.

CISA established the KEV catalog in November 2021 through Binding Operational Directive (BOD) 22-01, which requires all federal civilian executive branch (FCEB) agencies to remediate KEV-listed vulnerabilities by specified due dates. The directive transformed the catalog from an informational resource into a compliance requirement for federal agencies, with mandatory remediation timelines that typically range from 14 to 21 days from the date of catalog addition.

While BOD 22-01 is mandatory only for federal agencies, CISA strongly recommends that all organizations use the KEV catalog as a prioritization input. The catalog has become one of the most widely used threat intelligence sources for vulnerability management because it provides a high-confidence, actionable signal: if a CVE is on the KEV, exploitation is confirmed, and remediation should be a top priority.

How the KEV Catalog Works

Inclusion Criteria

CISA adds a CVE to the KEV catalog when three criteria are met. First, the CVE must have been assigned to the vulnerability (it must be in the CVE catalog). Second, there must be reliable evidence that the vulnerability is being actively exploited in the wild. Third, there must be a clear remediation action available, typically a vendor patch or a specific mitigation. CISA does not add vulnerabilities with no available fix to the KEV, because the mandatory remediation directive requires a defined remediation action.

The active exploitation requirement is the catalog's distinguishing feature. CISA verifies exploitation through multiple evidence sources before adding a CVE. This verification process means the KEV catalog is conservative: it includes only CVEs with confirmed exploitation, not CVEs with theoretical risk or publicly available exploit code that has not been observed in use. The result is a high-confidence, low-noise signal that organizations can use as a priority override without worrying about false positives.

Catalog Structure

Each KEV entry includes the CVE identifier, the vulnerability name, the affected vendor and product, the date added to the catalog, the required remediation action (typically "apply vendor patch"), the due date for federal agency remediation, a description of the vulnerability, and notes about the exploitation activity. The catalog is available as a JSON feed, a CSV download, and through the CISA KEV web interface, making it accessible for both manual review and automated integration.

The catalog is additive. CVEs are added but not removed (though entries may be updated). As of mid-2026, the catalog contains over 1,100 entries spanning vulnerabilities disclosed from the 1990s to the present. This means the KEV represents not only recently disclosed vulnerabilities but also older CVEs that continue to be exploited because organizations have not yet remediated them.

Using KEV for Prioritization

The most effective use of the KEV catalog is as a priority override in the vulnerability management workflow. When a scan finding matches a KEV entry, the finding should be escalated to top priority regardless of its CVSS score, EPSS probability, or any other prioritization input. The rationale is straightforward: CISA has confirmed that this vulnerability is being exploited in the wild, which means the threat is real and active, not theoretical or probabilistic.

Operationalizing this override requires correlating scan findings against the KEV catalog. This can be done through API integration (querying the KEV JSON feed with the CVE identifiers from scan results), native support in the vulnerability management platform (many commercial platforms include KEV matching as a standard feature), or manual cross-reference (suitable for small environments but not practical at scale). The correlation should run automatically at scan ingestion time so that KEV-matched findings receive top priority without analyst intervention.

Organizations should also perform a one-time check of all currently open vulnerabilities against the full KEV catalog. Because the catalog includes CVEs dating back decades, an organization may have open findings matching older KEV entries that were not flagged because the vulnerability was open before the corresponding KEV addition. This initial backfill identifies any legacy KEV matches that need immediate remediation.

KEV and Compliance

For federal agencies, KEV compliance under BOD 22-01 is mandatory. Agencies must remediate KEV-listed vulnerabilities by the specified due dates and are subject to oversight on compliance. The remediation timelines are aggressive, typically 14 days for newly added entries, reflecting the urgency associated with confirmed active exploitation. Agencies that cannot meet the deadline must document the delay and implement compensating controls pending remediation.

Private-sector organizations are not legally bound by BOD 22-01, but many adopt KEV timelines as internal standards. Using KEV remediation deadlines as SLA benchmarks demonstrates a security posture informed by real-world threat data. Compliance frameworks like NIST CSF and ISO 27001 require organizations to prioritize based on risk, and using confirmed exploitation data from the KEV catalog satisfies this requirement with high-confidence evidence.

Auditors increasingly reference the KEV catalog in security assessments. Questions like "Do you have any open vulnerabilities in the CISA KEV catalog?" and "What is your remediation timeline for KEV-listed findings?" are becoming standard in security audits, vendor risk assessments, and due diligence processes. Organizations that can demonstrate zero open KEV findings, or rapid remediation of new KEV additions, present a stronger security posture than those that cannot.

KEV Limitations

The KEV catalog has limitations that organizations should understand. The catalog is conservative: it only includes CVEs with confirmed exploitation, meaning it misses vulnerabilities that are being exploited but not yet reported to or verified by CISA. The absence of a CVE from the KEV does not mean it is not being exploited; it means exploitation has not been confirmed to CISA's standard. Organizations should supplement KEV with EPSS and other threat intelligence sources to cover vulnerabilities with high exploitation probability that have not yet reached the KEV threshold.

KEV coverage is also biased toward vulnerabilities affecting widely deployed software and systems that CISA and its partners monitor most closely. Vulnerabilities in niche software, custom applications, or emerging technology categories may be exploited but not added to the KEV because they fall outside CISA's primary visibility. Organizations using specialized software should not rely exclusively on KEV for exploitation awareness and should monitor vendor advisories and industry-specific intelligence sources for their specific technology stack.

The remediation requirement (a clear fix must exist) means that some actively exploited vulnerabilities are not in the KEV because no vendor patch is available. Zero-day vulnerabilities being exploited before a fix exists would not meet the KEV inclusion criteria. Organizations must have processes for responding to zero-day exploitation threats that exist outside the KEV framework, using compensating controls and monitoring until a patch becomes available.

Operationalizing KEV in Your Program

Building KEV into the vulnerability management workflow requires several operational steps. First, automate the KEV correlation. The KEV catalog is available as a JSON feed that can be polled daily. When new CVEs are added, the system should automatically check whether any open findings in the vulnerability management platform match the new additions and escalate them if they do. This automation ensures zero-delay response to new KEV additions.

Second, establish a KEV-specific SLA that is more aggressive than the standard CVSS-based SLAs. Many organizations adopt 14 days for new KEV additions, aligned with CISA's typical federal timeline. Some organizations with higher risk tolerance may use 21 days. Organizations in critical infrastructure sectors or with significant public exposure may target 7 days. The SLA should reflect the organization's risk appetite and remediation capacity.

Third, create a KEV compliance dashboard that tracks the number of open KEV findings, the age of each finding, compliance with KEV-specific SLAs, and trending data over time. This dashboard serves both operational (tracking remediation progress) and strategic (demonstrating posture to leadership and auditors) purposes. A goal of zero open KEV findings is aspirational but achievable for organizations with mature vulnerability management programs.

Fourth, integrate KEV into executive reporting. The question "How many confirmed-exploited vulnerabilities are open in our environment?" is one of the most direct risk indicators a CISO can present to a board. KEV provides the data to answer it authoritatively. Tracking the trend over quarters demonstrates whether the organization's response to confirmed threats is improving.

KEV as a Benchmarking Tool

Beyond individual vulnerability prioritization, the KEV catalog serves as a benchmarking tool for program maturity. Organizations can measure their "KEV response time," the elapsed time between a CVE being added to the KEV and the organization confirming remediation across all affected assets. Shorter response times indicate a more responsive and capable program. Comparing response times over quarters reveals whether the program is improving its ability to respond to confirmed threats.

The KEV catalog also supports risk communication with non-technical stakeholders. Board members and executives who may not understand CVSS scores or EPSS probabilities can understand the concept of "these specific vulnerabilities are being actively used by attackers right now." Framing vulnerability management progress in KEV terms, "we reduced our open KEV count from 15 to 2 this quarter and our average response time from 21 days to 9 days," communicates security posture in terms that resonate with business leaders.