CISA KEV catalog: a working sysadmin's guide to actually using it

Most enterprise teams know the CISA Known Exploited Vulnerabilities catalog the same way they know the weather: a headline scrolls past ("CISA adds three vulnerabilities to KEV catalog"), someone forwards it, and everyone nods. That is a waste of the single most operationally useful list in vulnerability management. The KEV is small, machine-readable, updated near-daily, and every entry on it has one property your scanner output cannot give you: a real attacker has already used it against a real network.

This is a guide to the catalog itself: what it promises, what it doesn't, how the feeds are structured, how to map entries to your own estate without fooling yourself, and how to combine it with EPSS and vendor advisories into a defensible patch-ordering rule. Everything here is verified against the live feed and CISA's own pages as of late July 2026.

What the KEV is, and what it is not

CISA describes the KEV as the authoritative source of vulnerabilities that have been exploited in the wild. Entry is gated by three criteria, all of which must hold:

1. The vulnerability has an assigned CVE ID.
2. There is reliable evidence of active exploitation in the wild.
3. There is a clear remediation action, such as a vendor-provided update.

Read those criteria as exclusions and the catalog's real shape appears. No CVE assigned yet? Not in the KEV, even if exploitation is rampant. Exploitation reported but CISA's evidence bar not met? Not in the KEV. Actively exploited but no fix or mitigation exists? Not in the KEV. The catalog is a curated floor, not a census. As of the 2026.07.29 release the feed contains 1,656 entries, against an ecosystem publishing tens of thousands of CVEs per year. Absence from the KEV is not evidence of safety; presence is close to proof of danger. That asymmetry is the whole point, and it is why the correct reading of the list is "everything on here is urgent" rather than "everything urgent is on here."

The distribution is also worth knowing before you build anything on top of it. Microsoft dominates with 382 entries, followed by Cisco (95), Apple (93), Adobe (80), Google (72), then the appliance vendors that have defined the last few years of mass exploitation: Ivanti (35), Fortinet (29). 332 entries, about one in five, carry a known-ransomware-campaign flag. If you run a typical enterprise stack, a large slice of this catalog is aimed directly at you.

The due dates: BOD 22-01 is gone, and its replacement raised the stakes

The KEV was created by Binding Operational Directive 22-01 in November 2021, which required US federal civilian agencies to remediate each listed CVE by a per-entry due date. If your mental model of KEV deadlines still comes from that era ("two or three weeks for new entries"), it is out of date. On June 10, 2026, CISA issued BOD 26-04: Prioritizing Security Updates Based on Risk, which supersedes and revokes BOD 22-01 outright. The KEV catalog itself continues, with the same inclusion criteria, but due dates are now set by a four-variable risk model: public exposure of the asset, KEV status, exploit automatability, and technical impact (partial versus total control). Remediation timelines run from three calendar days, with mandatory forensic triage for the worst combinations, down to fix-on-next-upgrade for vulnerabilities that trip none of the variables. CISA's Vulnrichment program publishes answers for three of the four variables for every CVE; only asset exposure is yours to determine.

You can see the regime change directly in the feed. Of the 39 entries added since June 10, 34 carry a three-day deadline and the rest fourteen days. Under the old directive, three weeks was routine. A concrete example from the day I pulled the data: CVE-2026-20316, a hard-coded password vulnerability in Cisco Secure Firewall Management Center, was added on 2026-07-29 with a due date of 2026-08-01. Three days, for an FMC bug, over a weekend.

Why should you care if you are not a federal agency? Two reasons. First, the due dates are free triage: they encode CISA's judgment about exploitation velocity and impact, computed by people with incident data you will never see. When a directive built on that data says "three days," treating your own internet-facing FMC as a 30-day ticket is a choice you should at least make consciously. Second, the KEV increasingly shows up in places with teeth: cyber-insurance questionnaires, audit frameworks, and customer security reviews commonly ask how you track and remediate KEV-listed vulnerabilities. "We monitor the catalog and apply the federal timelines to exposed assets" is a clean, defensible answer that costs very little to make true.

The feeds: skip the webpage, consume the data

The browsable catalog page is fine for humans, but the operational interfaces are the feeds, all free and unauthenticated:

• JSON: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json
• CSV: https://www.cisa.gov/sites/default/files/csv/known_exploited_vulnerabilities.csv
• JSON schema: https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities_schema.json

The JSON document has a small envelope (title, catalogVersion, dateReleased, count) and a vulnerabilities array. Each entry carries: cveID, vendorProject, product, vulnerabilityName, dateAdded, shortDescription, requiredAction, dueDate, knownRansomwareCampaignUse (the string Known or Unknown), notes (semicolon-separated advisory URLs), and cwes.

Here is a minimal watcher in plain Node.js (18 or later, no dependencies) that pulls the feed and prints recent additions matching your vendors. I ran this exact script against the live feed while writing this article:

// kev-watch.mjs - Node 18+ (native fetch, top-level await)
const FEED = "https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json";
const KEYWORDS = ["cisco", "vmware", "broadcom", "windows server", "solarwinds"];
const DAYS_BACK = 30;

const res = await fetch(FEED);
if (!res.ok) throw new Error(`KEV feed returned HTTP ${res.status}`);
const { catalogVersion, count, vulnerabilities } = await res.json();

const cutoff = new Date(Date.now() - DAYS_BACK * 86_400_000);
const matches = vulnerabilities.filter((v) => {
  const haystack = `${v.vendorProject} ${v.product}`.toLowerCase();
  const recent = new Date(v.dateAdded) >= cutoff;
  return recent && KEYWORDS.some((k) => haystack.includes(k));
});

console.log(`KEV ${catalogVersion} (${count} total entries)`);
console.log(`${matches.length} matches added in the last ${DAYS_BACK} days:\n`);

for (const v of matches.sort((a, b) => a.dueDate.localeCompare(b.dueDate))) {
  const flag = v.knownRansomwareCampaignUse === "Known" ? "  << RANSOMWARE" : "";
  console.log(`due ${v.dueDate}  ${v.cveID}  ${v.vendorProject}: ${v.product}${flag}`);
}

Real output from 2026-07-29:

KEV 2026.07.29 (1656 total entries)
2 matches added in the last 30 days:

due 2026-07-16  CVE-2008-4128  Cisco: IOS
due 2026-08-01  CVE-2026-20316  Cisco: Secure Firewall Management Center (FMC)

Schedule that however you like and pipe it to email or chat. If you want the fuller version of this idea, a daily brief that also folds in Microsoft's MSRC feed and checks your firmware versions for compliance drift, I walked through that build in a separate article: Build a 5-minute morning security brief. This piece stays on the catalog itself.

Mapping KEV to your estate: the false-negative trap

Keyword matching on vendorProject and product is where every homegrown KEV consumer starts, and where most of them quietly rot. The fields are human-written strings, not a controlled vocabulary, and they will betray a naive filter in at least three ways.

First, vendors change names. VMware entries added before the Broadcom acquisition sit under vendorProject: "VMware"; newer ones, including vCenter Server and Aria Operations entries, sit under "Broadcom". A filter that matches only vmware silently misses new vCenter KEVs. The same class of problem applies to renamed products: the Cisco FMC entry above helpfully notes "formerly known as Firepower Management Center" in its description, but nothing forces future entries to do that.

Second, vague product strings. Entries like Zyxel's product: "Multiple Products" match no sensible product keyword. If you filter on product names alone, these vanish.

Third, your inventory lies. Matching the feed is the easy half; the hard half is knowing that the thing in the entry actually exists on your network, including the appliance someone racked in 2019 that never made it into the CMDB.

Practical rules that keep the approach honest: match on the concatenation of vendor and product, not product alone; include acquirer names alongside legacy vendor names (VMware and Broadcom, SolarWinds and N-able, and so on); treat your keyword list as config that gets reviewed when the catalog surprises you; and once a week, eyeball the full list of new additions regardless of matches, which at current volume (172 additions so far in 2026) is a two-minute skim. The keyword filter is a tripwire, not a coverage guarantee. If you need a guarantee, that is what a scanner with CPE-based matching is for, and even those disagree with each other.

A ranking rule: KEV, then EPSS, then the vendor advisory

The KEV answers exactly one question: is this being exploited? It says nothing about how likely exploitation of everything else is, and nothing about how bad exploitation would be for you. So combine three signals, in this order:

1. KEV membership is a gate, not a score. Anything in the KEV that exists in your estate goes to the front of the queue, full stop. Within that set, order by dueDate and put knownRansomwareCampaignUse: "Known" entries first. Exposure decides the calendar: for internet-facing assets, treat CISA's due date as your due date; for internal-only assets, the next scheduled window is usually defensible. That is exactly the spirit of BOD 26-04's exposure variable.

2. EPSS ranks everything the KEV is silent on. The Exploit Prediction Scoring System from FIRST estimates the probability a CVE will be exploited in the next 30 days, and the free API is one GET request per CVE. It complements the KEV precisely because it is predictive where the KEV is confirmatory. Know its blind spot at the seam, though: brand-new KEV entries often have no meaningful EPSS score yet. On the day CVE-2026-20316 hit the catalog, EPSS had no score for it at all, while the 2008-vintage Cisco IOS entry scored 0.33, higher than 98 percent of all CVEs. KEV first, EPSS second is not just a slogan; the ordering is load-bearing.

3. The vendor advisory decides what you actually do. Every KEV entry links its advisory in the notes field. The advisory tells you the fixed version, whether a workaround exists, and whether your specific configuration is affected. In a Cisco shop, the KEV tells you FMC is under active attack; only the Cisco advisory tells you whether your release train has a fixed build and what the mitigation is until your window opens.

As a one-line policy: KEV match on an exposed asset means patch now on CISA's clock; KEV match internal-only means next window, ransomware-flagged first; no KEV match means rank by EPSS and severity and handle in normal cadence, with the vendor advisory as the source of truth for the fix itself.

Honest limitations

The KEV is the best free signal in vulnerability management, and it will still fail you in specific, predictable ways.

It lags by design. Evidence of in-the-wild exploitation has to exist and reach CISA's bar before an entry appears. For a zero-day being exploited before the patch exists, criterion three blocks listing until a fix ships, and by the time the entry lands you may be days behind attackers. The KEV can never be your early-warning system for your crown-jewel products; vendor PSIRT feeds and emergency advisories own that window. It also lags in the other direction: that Cisco IOS entry added in July 2026 is CVE-2008-4128, an eighteen-year-old vulnerability. Exploitation evidence arrives when it arrives.

It carries no severity or applicability context. Entries are not scored, and the due date reflects CISA's risk model for federal networks, not your exposure. Two entries with identical due dates can differ wildly in what they mean for you. The catalog cannot know whether you have the product, whether it is reachable, or whether a compensating control already blocks the exploitation path. It is an input to prioritization, not a prioritization.

Some entries are dead weight, and rarely one is just dead. A catalog that only grows accumulates entries for products that went end-of-life years ago; those still matter if the EOL gear is still racked, but they clutter naive dashboards. And the evidence bar, while high, is not infallible: CISA removed CVE-2022-28958 from the catalog in December 2023 after the D-Link "vulnerability" was found not to exist at all and the CVE was rejected. Removals are rare enough to be news, which is itself a good sign, but sync deletions, not just additions, if you mirror the feed into anything downstream.

None of this argues against the catalog. It argues against treating it as a complete risk picture rather than what it is: a short, high-confidence list of proven attacker behavior, refreshed almost daily, in a format a sysadmin can consume with thirty lines of code. Most organizations have not done even that. Be the one that has.

---

Adam Lewandowski is a network and security engineer (CompTIA Security+, CCNA, VMware VCP-DCV) working with Cisco FTD/FMC/ISE, Windows Server, MECM, and VMware environments. Connect on LinkedIn.

I write The Patch Window, a free 5-minute weekly brief on which enterprise patches can't wait - Cisco, Windows Server, VMware. Subscribe: https://the-patch-window.beehiiv.com