CISA issued BOD 26-04, "Prioritizing Security Updates Based on Risk," on June 10, 2026. It replaced BOD 22-01, the directive that created the KEV catalog's patch deadlines, and BOD 19-02. Instead of one clock for everything in the catalog, remediation windows now depend on risk: whether an asset is publicly exposed, whether exploitation can be automated, how much control an attacker gains, and whether exploitation is already happening. The top tier gets three days, with forensic triage. Lower tiers get fourteen or sixty days, or wait for the next scheduled upgrade.
The directive binds federal civilian agencies, which have until December 7, 2026 to meet its timelines. But the KEV catalog is public, and many private-sector vulnerability programs use it as their exploitation signal. So I wanted to see what the catalog itself looks like under the new rules.
I pulled the KEV data (catalog version 2026.10.16) and looked at every entry added from June 11, 2026, the first day an entry references BOD 26-04, through October 16. That is 131 vulnerabilities.
The clock got shorter, and it got specific
Through February 2026, most KEV entries carried the same 21-day gap between the date added and the due date. Fourteen-day windows start to appear in March. Since June 11, the picture is different.
- 108 of 131 entries (82%) carry a three-day window.
- 23 (18%) carry fourteen days.
- 87 (66%) are flagged for forensic triage. The first of those flags appears on June 25, and every flagged entry is on a three-day clock.
Three days is not a patch cycle. It is an incident response timeline, and that is the point: for the top tier, the question is not only "is it fixed?" but "was it used before we fixed it?"
Where the three-day entries land
I grouped the 131 entries into five product classes. The grouping is mine, not CISA's.
| Product class | Entries | On a 3-day window |
|---|---|---|
| Network edge and security appliances | 43 | 41 (95%) |
| Business and web applications | 45 | 38 (84%) |
| Operating systems, browsers and mobile | 17 | 9 (53%) |
| Developer, CI/CD and AI tooling | 16 | 10 (62%) |
| Remote access, IT management and backup | 10 | 10 (100%) |
Two patterns stand out.
Edge and remote access dominate the short clocks. Firewalls, VPN gateways, application delivery controllers, SD-WAN managers, email gateways and routers make up a third of all additions, and almost all of them land in the three-day tier. Remote support, management and backup tools (ScreenConnect, BeyondTrust Remote Support, SimpleHelp, N-able N-central, vCenter, Acronis and Ahsay backup) are fewer, but every one of them is on a three-day clock. These are systems that face the internet or hold the keys to everything else, which is exactly what the exposure factor in BOD 26-04 is built to catch.
Endpoints and browsers get more time. Client-side bugs, such as the Chromium V8 entries and Apple's multi-product fixes, mostly carry fourteen days. They are exploited and they matter, but my read is that they usually need a user to open a page or a file, and most organizations already push browser and OS updates through a weekly channel.
The AI and developer stack shows up
Sixteen entries hit developer and data platforms: artifact repositories (JFrog Artifactory, four times), source control (GitLab, Gitea), CI (TeamCity), workflow orchestration (Kestra) and AI and ML infrastructure: Langflow (three entries), MLflow, Ray and the LiteLLM proxy.
These systems are often stood up quickly by engineering teams, run with broad credentials, and sit outside the inventory the security team scans. If an exposure management program cannot say where its AI tooling runs, the KEV catalog is now a good reason to find out.
Old CVEs keep coming back
Twenty-one of the 131 entries (16%) carry CVE IDs from before 2026. The oldest, CVE-2008-4128 in Cisco IOS, was added on July 13. On October 8, five more arrived at once (ProFTPD, ISC BIND, Apache Struts, ONLYOFFICE Docs and Strapi), tied to activity consistent with Flax Typhoon. I wrote about that batch separately.
A KEV listing for an old CVE does not mean the bug is new. It means someone is using it now.
What I take from it
- Exposure first. The same CVE is a three-day problem on an internet-facing appliance and a much smaller one on an isolated lab host. Know which assets are publicly reachable before the next KEV update lands, not after.
- Inventory the edge and the admin plane. Nearly half of the three-day entries (51 of 108) are edge appliances or remote management and backup tools.
- Plan for forensic triage, not just patching. Two thirds of new entries now come with a triage flag. Decide ahead of time who preserves logs and who looks for prior compromise, so a three-day clock does not turn into "patch and hope."
- Count old CVEs as live risk. Age is not a mitigation. Long-forgotten services are what wide, automated scanning finds first.
- Let evidence set the order, not CVSS. The catalog does not carry a CVSS score at all. Its clock now encodes exposure and exploitation, which is the core of threat-informed prioritization.
Method
Data: the CISA KEV catalog JSON, version 2026.10.16, from CISA's kev-data repository on GitHub. Window: every entry with a dateAdded from 2026-06-11 to 2026-10-16. The remediation window is the due date minus the date added. Product classes are my own grouping by vendor and product. I keep a small script that reproduces every number in this post from the raw catalog, and I rechecked all of them on October 17, 2026 against catalog version 2026.10.16 (1,748 entries) with a second, independent count.