The CISA KEV catalog: the vulnerabilities already being exploited

What KEV actually is

The Known Exploited Vulnerabilities (KEV) catalog is maintained by the US Cybersecurity and Infrastructure Security Agency. CISA describes it as the authoritative source of vulnerabilities that have been exploited in the wild, and recommends that all organisations use it as an input to their vulnerability management prioritization framework – naming SSVC, Stakeholder-Specific Vulnerability Categorization, as an example of a framework that consumes exploitation status.

The wording is worth taking literally. KEV is an input, not the framework. It answers exactly one question – has this been exploited in the wild – and CISA sets a deliberately narrow bar for answering yes. Three conditions must all hold:

1. The vulnerability has an assigned CVE ID.
2. There is reliable evidence that the vulnerability has been actively exploited in the wild.
3. There is a clear remediation action for the vulnerability, such as a vendor-provided update.

The third criterion is the one people forget. A vulnerability under active attack may lack a patch yet still enter KEV when a clear action exists, such as mitigation or discontinuing the product. Without a clear remediation action it does not meet the inclusion criteria. So KEV is not a complete picture of what is being exploited – it is the exploited set you can currently do something about.

How big KEV is, and how fast it grows

Scale is what makes the catalog usable. The JSON feed published on 11 September 2026 – catalog version 2026.09.11 – holds 1,709 entries in total. That is the entire catalog accumulated since 2021, set against roughly 61,000 CVEs published in the last 12 months alone.

KEV entries added by year

Year	Entries added
2021	311
2022	555
2023	187
2024	186
2025	245
2026 (to 11 September)	225

The rate is steadier than the totals suggest. 2022 was the outlier at 555 additions. 2025 added 245, which works out at roughly five additions a week, and 2026 has run a little faster: 225 by 11 September, about six a week.

Five or six a week is a number you can build a process around. It is small enough to review by hand and frequent enough that a monthly check will miss things – which is the argument for consuming the feed rather than visiting the page.

BOD 22-01 is revoked: what BOD 26-04 changed

KEV was created by Binding Operational Directive 22-01, issued on 3 November 2021, which set fixed remediation deadlines for US federal civilian agencies. That directive no longer exists. BOD 26-04: Prioritizing Security Updates Based on Risk, issued on 10 June 2026, supersedes and hereby revokes BOD 19-02 and BOD 22-01.

The catalog itself survives untouched – the KEV inclusion criteria are unchanged by BOD 26-04 – but the deadline model has gone. One fixed clock for everything in KEV has been replaced by risk-tiered timelines driven by four decision points, so the deadline attached to a CVE now depends on the answers rather than on the listing alone.

CISA is direct about why it stopped labelling work by severity:

CVSS scores such as “critical” or “high” do not prescribe specific actions. To eliminate ambiguity, CISA replaces these labels with explicit timelines for required remediation under defined conditions.– CISA, BOD 26-04 Implementation Guidance, 2026

The four decision points

Table 1 of the directive is informed by SSVC. Three of the four answers come from CISA itself through the Vulnrichment Program, which publishes enrichment including KEV status, exploit automation and technical impact for CVEs it assesses. Check coverage; missing enrichment is not a negative answer. Only the first is yours to answer.

The four decision points in BOD 26-04

Decision point	What it asks	Where the answer comes from
Asset Exposure	Is the vulnerable asset publicly exposed?	Your own asset inventory
KEV Status	Is the CVE in the Known Exploited Vulnerabilities catalog?	The KEV catalog, republished via Vulnrichment
Exploit Automation	Can an adversary automate every step of exploitation?	CISA Vulnrichment Program
Technical Impact	Does exploitation give partial or total control of the target?	CISA Vulnrichment Program

Two mechanics are worth copying even if no directive binds you. The clock starts when CISA adds the CVE to KEV or when you enumerate it on an asset, whichever comes first – not when someone opens a ticket. And the days are calendar days, so a weekend is not a pause.

The three-day tier

The sharp end of BOD 26-04 is short. Where CISA determines that the vulnerability is present on a publicly exposed asset, the technical impact is total, and it is automatable by an adversary, the KEV due date will reflect a three-day patching deadline. That tier also requires a forensic triage of the asset, to assess whether it is already compromised.

The second requirement is the one private-sector teams skip. If a vulnerability was internet-exposed, trivially automatable and handed over total control, the honest position is not that you patched in time – it is that you do not yet know. Patching closes the door; it says nothing about who came through it first.

At the other end sits a “fix on system upgrade” tier: items agencies do not need to prioritise and can leave until the next scheduled major upgrade or rebuild. An explicit “later” tier is what makes an urgent tier credible, because it gives the team somewhere honest to put the rest.

What KEV does not tell you

KEV has no view of your environment. It does not know whether you run the affected product, whether the vulnerable component is reachable, or what the asset is worth – the same blind spot the scores have, covered in CVSS vs EPSS. A KEV match is the start of triage, not the end of it – run one through the triage tool to see which context is still missing.

Age matters as well. FIRST notes that the KEV signal degrades over time: a vulnerability added to KEV years ago reverts toward the exploitation probability its current features would otherwise predict. A 2021 entry you have long since compensated around is a weaker prompt than one added last week.

And KEV is a filter, not a queue. That is the real significance of 1,709 entries against 61,000 CVEs in a single year: cross-referenced against a real asset inventory, the catalog usually resolves to a handful of things you actually run.

Using KEV outside the US federal government

BOD 26-04 binds federal civilian executive branch agencies only. The private sector is not covered by it, and CISA explicitly encourages SLTT government and private industry to prioritise KEV remediation anyway. Outside government, KEV is a useful prioritisation input alongside affected assets, exposure and applicable obligations.

1. Consume the JSON feed continuously and diff it, rather than checking a page.
2. Cross-reference every new entry against your asset inventory automatically – an addition matters only where you run the affected product.
3. Copy the decision points rather than the deadlines. Exposure, KEV status, automatability and technical impact are the right four questions whether or not a directive binds you.
4. Where no patch is deployable yet, apply the remediation action CISA lists and isolate the asset – an entry only exists because a clear remediation action exists.
5. Route the match into one ranked list instead of a parallel spreadsheet: see the prioritisation playbook.