When a security advisory says CISA has "added a flaw to KEV" and set a deadline, it is pointing to one specific list: the Cybersecurity and Infrastructure Security Agency's Known Exploited Vulnerabilities catalog. It has become one of the most widely watched patch-priority lists in the industry, and it shows up in many ZeroDayFeed stories about exploited bugs. This guide explains what the catalog is, how a vulnerability gets onto it, what the deadlines mean, and why a business that owes nothing to CISA should still use it.

One thing has changed recently. For most of its life the catalog was tied to Binding Operational Directive (BOD) 22-01. On June 10, 2026, CISA revoked that directive and replaced it with BOD 26-04, "Prioritizing Security Updates Based on Risk." The catalog itself carried over. The way its deadlines are set did not.

What the KEV catalog is

The National Vulnerability Database lists every publicly known vulnerability that has a CVE identifier. The KEV catalog is a much smaller subset: the vulnerabilities CISA has reliable evidence attackers have actually used. CISA calls it "the authoritative source of vulnerabilities that have been exploited in the wild."

CISA created the catalog in November 2021 under BOD 22-01. The earliest entries in the catalog's own data feed are dated November 3, 2021. As of catalog version 2026.10.21, released October 21, 2026, the feed lists 1,754 vulnerabilities, 270 of them added so far in 2026. CISA marks 361 entries as having known use in ransomware campaigns. Those counts grow almost every week.

Each entry is short and practical. It names the CVE, the vendor and product, a plain description of the flaw, the date CISA added it, a due date, the required action (usually "apply updates per vendor instructions," apply vendor mitigations, or stop using the product), and a ransomware-use flag. The feed now also includes a forensic-triage field, explained below. The whole catalog can be downloaded as CSV or JSON, and CISA offers email alerts when entries are added.

How a vulnerability gets on the list

CISA's published criteria page sets three conditions:

  • It has a CVE ID. A flaw without a CVE number cannot be listed, however badly it is being exploited.
  • There is reliable evidence of active exploitation in the wild. CISA counts both successful and attempted exploitation; an attack that fires at a honeypot or at a system that turns out not to be vulnerable still counts as attempted. Scanning, security research, and the release of proof-of-concept code do not count. A public proof of concept is not required for listing either.
  • There is a clear remediation action, such as a vendor update. If the product is end-of-life or cannot be updated, the action is to remove it from the network.

The BOD 26-04 implementation guidance adds a fourth condition: the flaw must carry significant risk to U.S. government information systems. CISA says it gathers exploitation evidence from vendors, researchers, government partners, its own incident response work, daily open-source monitoring and paid threat-intelligence feeds. It says it aims to add a qualifying vulnerability within 24 hours, though missing evidence, an unassigned CVE or no available mitigation can delay a listing.

Two things often confuse readers. First, an old CVE appearing on the list does not necessarily mean CISA is seeing attacks today. Any vulnerability can qualify at any time once reliable evidence turns up, and CISA says it does not assume legacy or end-of-life products have been patched or retired. Second, entries almost never come off. CISA says it removes one only because of an error or other problem, such as a vendor fix that causes an unforeseen issue with greater impact than the vulnerability itself, and that it typically restores the entry once the vendor resolves the issue.

The old deadlines under BOD 22-01

BOD 22-01 required federal civilian agencies to fix catalog entries on a simple clock: within six months for CVEs assigned before 2021, and within two weeks for everything else. CISA could shorten either window "in the case of grave risk to the Federal Enterprise."

In practice the catalog's due dates usually followed a three-week pattern. A ZeroDayFeed count of the catalog's JSON feed (catalog version 2026.10.21) found that 1,025 of the 1,617 entries added before June 10, 2026, carried a due date exactly 21 days after the date they were added. Most of the rest were 14 days, about six months, or, in a few dozen urgent cases, as little as three days.

In its 2021 FAQ for the directive, CISA made the case for prioritizing on exploitation rather than severity scores. It said fewer than 4% of all CVEs had been publicly exploited, but that attackers were quick with the ones they chose: of those exploited CVEs, 42% were used on the day of disclosure, 50% within two days and 75% within 28 days. It also noted that some damaging attacks chain together flaws rated "high," "medium" or even "low."

The new deadlines under BOD 26-04

BOD 26-04 revokes both BOD 22-01 and BOD 19-02, the older directive covering internet-accessible systems. It replaces a single clock with a table built on four questions about each vulnerable asset:

  • Is the asset publicly exposed? That is, reachable by unauthenticated or untrusted parties over a public network such as the internet.
  • Is the CVE in the KEV catalog?
  • Is it automatable? Can an attacker automate every step needed to exploit it?
  • What is the technical impact? Does exploitation give the attacker partial control of the asset or total control? CISA counts an exploit that reliably reveals login credentials as total control.

The answers set the deadline in calendar days. For anything in the KEV catalog, the table gives agencies either 3 days or 14 days. A KEV-listed flaw on a publicly exposed asset gets 3 days in most cases. It gets 14 days only when the flaw is both not automatable and limited to partial control. A KEV-listed flaw that hands an attacker total control on an exposed system, or one that is automatable with total control on an internal system, gets "3 days & forensic triage." For vulnerabilities not in the catalog the table allows 3, 14 or 60 days, and for internal assets where the flaw is neither in the catalog nor automatable, "fix on system upgrade."

CISA supplies the KEV status, automatable and technical-impact answers for every CVE through its Vulnrichment program. Agencies supply the exposure answer. The KEV due date you now see in the catalog is CISA's own calculation using the same table. The implementation guidance gives an example: if CISA determines a flaw is present on publicly exposed assets, gives total control and is automatable, the KEV due date reflects a 3-day deadline. Agencies still apply the table asset by asset, so an internal server may get a different clock than an internet-facing one with the same bug.

The effect on the catalog is easy to see. As of catalog version 2026.10.21, of the 137 entries added from June 10 through October 20, 2026, 111 carried a 3-day due date and 26 carried a 14-day due date. None got the old 21-day window. Two recent examples: CISA added the exploited SiteGuard Server Edition flaw CVE-2026-106931 on October 20 with a due date of October 23, and the Fortinet flaw CVE-2025-61624 on October 16 with a due date of October 19. Both are flagged for forensic triage.

What "forensic triage" means

The forensic-triage requirement is arguably the biggest conceptual change. Under the old directive, an agency that patched in time had met its obligation. Under BOD 26-04, the flagged entries assume the system may already have been compromised before the patch went on, so the agency must patch and also check for signs of intrusion.

CISA's implementation guidance lays out six steps: scoping, preserving and collecting evidence, critical patching and stabilization, containment and control, triage analysis, and an escalation decision. Its suggested targets run from the first two hours after a KEV addition to a written triage report within 48 to 72 hours. CISA says those targets are recommended practice, and that what the directive requires is an adequate forensic triage. Where CISA has indicators of compromise or flaw-specific forensic guidance, it puts them in the KEV entry itself. In the data feed (catalog version 2026.10.21), 89 of the 137 entries added since June 10 carry the forensic-triage flag, and every one of them has a 3-day due date.

Who has to follow it, and who should

Legally, BOD 26-04 binds federal civilian executive branch agencies. It does not cover national security systems or certain Department of War and intelligence community systems. It does not apply to contractors unless their contract says so, but agencies must review their contracts and work with contracting officers on any changes needed. Federal contractors should expect KEV timelines to start appearing in contract language and service-level agreements.

Everyone else is in the same position as before. CISA says that state and local governments and private companies, "although not bound by BOD 26-04," can "significantly strengthen their security and resilience posture" by prioritizing KEV entries. It recommends that every organization's vulnerability management plan include a requirement to address catalog entries immediately.

The reason is simple. The catalog is a list of bugs that attackers have already shown they can and will use. Most organizations cannot patch everything at once, and the KEV catalog is free, curated evidence about where to start. CISA is also clear that it should not be the only input. It says organizations should use the catalog as an input to a prioritization framework such as Stakeholder-Specific Vulnerability Categorization (SSVC), the decision-tree model that informed BOD 26-04's timeline table. That works best alongside an accurate asset inventory, so you know which entries actually affect you.

What It Means for Defenders

  • Subscribe to the feed. Sign up for CISA's KEV email alerts or pull the JSON or CSV feed into your scanner or ticketing system. CISA suggests organizations consider vulnerability and patch management tools that automatically flag or prioritize KEV entries.
  • Treat the due date as a ceiling, not a target. CISA's implementation guidance says the timelines are maximums and that agencies with a lower tolerance for risk may set shorter ones. A 3-day due date puts a flaw in CISA's most urgent category.
  • Answer the exposure question for your own assets. The new table turns on whether a system is reachable from the internet. Know which of your firewalls, VPNs, remote-access gateways, mail servers and web applications are public, because a KEV entry against one of those is your most urgent work.
  • Look for compromise, not just missing patches. When an entry is flagged for forensic triage, patching closes the door but does not tell you whether someone already got in. Check logs and the indicators in the KEV notes, and preserve evidence before rebuilding.
  • Have a plan for what you cannot patch. CISA's guidance for assets that cannot be updated is to take them off the network or isolate them through segmentation, proxies or decommissioning. An end-of-life device on the internet that appears in the catalog should be replaced.
  • Check the ransomware flag. The 361 entries marked as used in ransomware campaigns (as of October 21, 2026) are a good place to start a backlog review.
  • Do not stop at KEV. The catalog only holds flaws with CVE IDs and confirmed exploitation. Misconfigurations, weak credentials and newly disclosed bugs that have not yet been exploited still need a plan.

Sources