The CISA KEV catalog (Known Exploited Vulnerabilities Catalog) is a public, continuously updated list maintained by the U.S. Cybersecurity and Infrastructure Security Agency that documents software and hardware vulnerabilities confirmed to have been exploited in the wild. So what is the CISA KEV catalog, precisely? It is not a theoretical risk score or a prediction — every CVE on the list has documented evidence of active exploitation, which is what distinguishes it from broader vulnerability databases like the NVD. Each entry includes the CVE identifier, affected product, a short description, the date added, and — for federal civilian agencies — a required remediation deadline. Originally built to drive Binding Operational Directive 22-01, the catalog has become a de facto industry standard: security teams everywhere use it to triage patching, because "actively exploited" is a far stronger signal than CVSS severity alone.
What Is the CISA KEV Catalog Used For?
The CISA KEV catalog is used primarily to prioritize patching based on real-world exploitation evidence rather than theoretical severity scores. A vulnerability can carry a CVSS score of 9.8 and sit unpatched for years because no one is actually using it; conversely, a "medium" severity flaw can be catastrophic if threat actors are exploiting it at scale right now. CISA's known exploited vulnerabilities list solves this prioritization problem by filtering the noise: as of 2026 it contains well over 1,300 entries, spanning everything from decade-old Adobe Flash bugs to vulnerabilities disclosed within the last week. Security teams commonly feed the KEV catalog directly into vulnerability management tooling so that any CVE appearing on it is automatically escalated to "patch now" status, regardless of its base score. This is also why many compliance frameworks and cyber-insurance questionnaires now ask organizations directly whether they track and remediate against KEV.
How Does a Vulnerability Get Added to the KEV Catalog?
A vulnerability gets added to the KEV catalog only after CISA confirms three specific criteria: the vulnerability has an assigned CVE ID, there is reliable evidence of active exploitation in the wild, and a clear remediation action (a patch, update, or documented mitigation) exists. CISA gathers exploitation evidence from its own threat intelligence, vendor disclosures, incident response engagements, and reports from partners like the FBI and NSA. This is a deliberately conservative bar — CISA does not add a CVE just because a proof-of-concept exploit exists on GitHub or because a researcher demonstrated exploitability at a conference. A real example: CVE-2021-44228, the Log4Shell vulnerability in Apache Log4j, was added within days of confirmed mass exploitation in December 2021, while plenty of "critical" Log4j-adjacent CVEs disclosed around the same time never made the list because no exploitation evidence emerged. That gap is the entire point of the catalog — it separates vulnerabilities that are being weaponized from vulnerabilities that merely could be.
What Is the CISA KEV Compliance Deadline for Federal Agencies?
The CISA KEV compliance deadline is set individually for each catalog entry, typically requiring remediation within 15 calendar days for actively exploited vulnerabilities in internet-facing systems and up to 21 days for others, though CISA can shorten this window for especially dangerous flaws. These deadlines are legally binding for Federal Civilian Executive Branch (FCEB) agencies under Binding Operational Directive 22-01, issued in November 2021, but they are not legally enforceable against private-sector organizations. That said, the deadlines function as a widely adopted industry benchmark: state governments, critical infrastructure operators, and defense contractors under CMMC frequently adopt the same timelines contractually, and auditors increasingly ask commercial organizations to demonstrate they remediate KEV entries within comparable windows. When the MOVEit Transfer vulnerability (CVE-2023-34362) hit the KEV catalog in June 2023 after Clop ransomware actors began mass-exploiting it, federal agencies had roughly two weeks to patch — a deadline plenty of private companies missed, resulting in some of the largest data breach disclosures of that year.
What Are the KEV Remediation Requirements Under Binding Operational Directive KEV?
The KEV remediation requirements under Binding Operational Directive 22-01 require FCEB agencies to remediate the specific vulnerability listed — not just apply a general security update — and to report compliance status through CISA's Continuous Diagnostics and Mitigation (CDM) dashboard. Remediation doesn't always mean "install a patch": in cases where a vendor patch isn't yet available, CISA-approved mitigations such as disabling a vulnerable feature, restricting network access, or implementing a documented workaround can satisfy the directive until a permanent fix ships. Agencies are also required to maintain an accurate, continuously updated asset inventory, since you cannot remediate a KEV-listed vulnerability in software you don't know you're running — this asset-visibility requirement is frequently the actual bottleneck, not the patching itself. BOD 22-01 also mandates that agencies update internal vulnerability management policies to explicitly reference the KEV catalog rather than relying solely on CVSS-based SLAs.
Does the KEV Catalog Apply to Private-Sector Companies?
The KEV catalog does not carry legal force for private-sector companies, but it has effectively become a mandatory reference point through contracts, regulations, and industry norms. Software vendors selling into the federal government must attest to secure development practices that account for KEV under frameworks like the Secure Software Development Framework (SSDF), and cyber-insurance underwriters increasingly price policies based on whether an applicant has unpatched KEV entries in their environment. Sector-specific regulators have gone further: the SEC's cybersecurity disclosure rules and several state breach-notification statutes treat an organization's failure to remediate a known-exploited, publicly cataloged vulnerability as evidence of inadequate risk management following a breach. In practice, most mature security programs now treat CISA's known exploited vulnerabilities list as a floor, not a ceiling — a mandatory subset of "must patch immediately" that sits alongside, rather than replaces, their broader risk-based vulnerability management program.
How Is the KEV Catalog Different from CVSS or EPSS?
The KEV catalog differs from CVSS and EPSS because it reports confirmed past exploitation rather than predicting future risk. CVSS scores describe theoretical severity — how bad a vulnerability could be if exploited, based on factors like attack complexity and impact — without any signal about whether anyone is actually exploiting it. EPSS (Exploit Prediction Scoring System) is probabilistic, estimating the likelihood a vulnerability will be exploited in the next 30 days based on statistical modeling. KEV sits downstream of both: it's a binary, evidence-based confirmation that exploitation is already happening. Most mature vulnerability management programs now layer all three — using CVSS for baseline severity, EPSS to catch rising-risk CVEs before they're weaponized, and KEV as the non-negotiable, immediate-action tier that overrides everything else regardless of score.
How Safeguard Helps
Tracking the CISA KEV catalog manually — cross-referencing it against every dependency, container image, and internal service in a modern software supply chain — doesn't scale past a handful of applications. Safeguard continuously maps your software bill of materials (SBOM) and deployed artifacts against the live KEV feed, so the moment CISA adds a new entry, Safeguard immediately flags which of your builds, services, or third-party components are affected — before an auditor or an attacker finds it first.
Beyond detection, Safeguard tracks each KEV-listed finding against its associated remediation deadline, giving security and engineering teams a single view of what's due, what's overdue, and what mitigation status has been applied, which is exactly the evidence auditors and compliance frameworks ask for when validating KEV remediation requirements. For teams operating under or adjacent to Binding Operational Directive 22-01 obligations, Safeguard's provenance and attestation tooling generates the audit trail needed to prove not just that a patch was applied, but that it addressed the specific exploited vulnerability CISA identified — closing the gap between "we updated the package" and "we remediated the KEV entry" that trips up so many organizations during incident post-mortems and compliance reviews.