What is CISA KEV, and how do CISOs use it?

CISA's Known Exploited Vulnerabilities catalog, KEV, is a public list of software flaws CISA has confirmed attackers are already using, not just flaws that could theoretically be exploited. CISA describes it as its authoritative record of vulnerabilities exploited in the wild, and it exists so that any organization, not only federal agencies, can tell which of its open vulnerabilities to fix first.

What are the three criteria for a vulnerability to make the KEV catalog?

A vulnerability needs all three: an assigned CVE identifier, reliable evidence that it has actually been exploited in the wild, and a clear remediation action such as a vendor patch. CISA lists those three conditions as the test for adding anything to the catalog.

That third criterion is what separates KEV from a generic severity score: a vulnerability can be critical and still sit off the list if nobody has confirmed exploitation yet, or if there is no fix to point an organization toward.

Does CISA tell non-federal organizations to use it too?

Yes. CISA recommends that every organization, not just federal agencies, build immediate remediation of KEV entries into its own vulnerability management plan, on the reasoning that doing so raises the whole community's resilience rather than just one organization's.

Nothing in that guidance is legally binding on a private company. The binding part of KEV applies only to federal civilian agencies, through a directive, and that directive changed substantially in 2026.

What did BOD 22-01 originally require?

Binding Operational Directive 22-01, issued November 3, 2021, covered every piece of software and hardware on a federal information system, whether it ran on agency premises or was hosted by a third party on the agency's behalf. It gave every agency the same flat deadline per vulnerability: six months for anything with a CVE assigned before 2021, two weeks for everything added after that.

That one-size-fits-all clock is what most older "what is CISA KEV" explainers still describe. It is no longer current.

What changed with BOD 26-04?

CISA issued BOD 26-04 on June 10, 2026, and it explicitly supersedes and revokes both the 2019 internet-accessible-systems directive, BOD 19-02, and BOD 22-01. The flat two-week and six-month deadlines are gone, replaced by a remediation clock built from four yes/no and partial/total factors scored for each vulnerability: whether the affected asset is publicly exposed, whether the vulnerability is in the KEV catalog, whether an adversary can exploit it in an automated way, and whether exploitation gives partial or total control of the asset.

Table 1 of the directive sets the resulting deadlines. A publicly exposed asset with a KEV-listed, automatable vulnerability that gives an attacker total control must be fixed within 3 days, with mandatory forensic triage. Drop to partial control under the same conditions and agencies get 7 days. A publicly exposed, KEV-listed vulnerability that is not automatable gets 14 days regardless of impact. A publicly exposed vulnerability that is not yet in KEV gets 30 days. A vulnerability on an asset that is not publicly exposed, KEV-listed or not, is handled on the next system upgrade cycle rather than a standalone deadline.

Agencies are not expected to switch over instantly. BOD 26-04 gives them 60 days from issuance to update their vulnerability management processes to use CVE and KEV data as the basis for remediation decisions, and 180 days from issuance to actually be remediating on the new, risk-tiered timelines in Table 1.

The scope is narrower than it sounds for contractors: the directive covers agency assets within the government's own definition of a federal information system, and CISA does not reach into a contractor's own systems directly. It has instead told agencies to check that their contracts let them require compliance where a contractor operates agency systems on the agency's behalf.

Why does KEV still matter if the directive changed?

Because KEV membership itself is still one of the four inputs to the new remediation clock, and it is still the single fastest signal of real-world exploitation a free, public source provides. Nothing about BOD 26-04 changed the three criteria for getting onto the catalog, only what happens to a federal agency once a vulnerability is on it.

For a non-federal CISO, the practical reading is the same before and after BOD 26-04: treat catalog membership as a forcing function, not a line item to queue behind a quarterly patch cycle, and treat the combination of publicly exposed and catalog-listed as the pairing that jumps every other ticket.

Is the catalog available as a feed for automation?

Yes. CISA publishes the whole catalog as a CSV and a JSON feed, with a published JSON schema, so a vulnerability-management tool can pull it on a schedule instead of a person checking the web page. Each entry on the catalog page itself carries a date-added field recording when CISA added that vulnerability, and a due-date field reflecting the remediation clock agencies are held to.

CISA keeps adding to the catalog continuously rather than on a fixed release day: one entry visible on the catalog page carries a date added of October 4, 2026, three days before this guide was published, consistent with CISA's own advice to subscribe to catalog update notifications rather than checking only on a schedule.

How is KEV different from a CVSS score or the NVD?

The National Vulnerability Database and a CVSS score describe how severe a flaw could be if exploited; neither says whether it has been. KEV answers a narrower, more operational question, built on that second catalog criterion: has this specific vulnerability actually been seen in use by an attacker. A vulnerability can carry a maximum CVSS score and never appear on KEV because nobody has confirmed exploitation, and a lower-scored vulnerability can land on KEV the day evidence of exploitation surfaces.

That makes the two tools complementary rather than substitutes: CVSS and the NVD are a starting severity filter across the full universe of known vulnerabilities, and KEV is the much shorter, continuously updated list of which of those vulnerabilities to stop deprioritizing right now.

How should a CISO build KEV into a daily routine?

Pull the catalog on a schedule, not only when a headline prompts it, since entries are added whenever CISA confirms a new flaw meets the three criteria, and filter first for anything touching an internet-facing asset. The four BOD 26-04 factors are a reasonable triage model even outside the federal government: publicly exposed, automatable and capable of total control is the pairing to drop everything else for; the rest can follow a normal patch cycle.

Map KEV entries to installed software automatically where possible, since manually cross-referencing a growing catalog against an asset inventory does not scale. Where a vendor patch is not yet available for a listed flaw, apply the compensating control CISA or the vendor has published rather than waiting, since the clear-remediation-action criterion for KEV inclusion means something is always available, even if it is not a patch.

Finally, keep the directive's own scope in mind when a vendor or auditor cites "CISA KEV compliance": for a private company there is no such legal status. What they likely mean is alignment with CISA's non-binding recommendation, or with the practice federal agencies are now bound to under BOD 26-04.