Someone in your organisation signed a policy that says critical vulnerabilities get patched within 30 days. It is probably in a spreadsheet, or a Confluence page nobody has opened since the ISO audit. It feels responsible. It is also slower than the deadline the US government sets for its own agencies.
CISA's Known Exploited Vulnerabilities catalogue is the closest thing the industry has to a list of vulnerabilities that are actually being used against real systems. Pulling the feed on 29 October 2026 returns 1,764 entries. Of those, 1,025 carry a remediation deadline of exactly 21 days from the date they were added. Another 149 get three days. The median across the whole catalogue is 21 days.
Read that against the rows in your SLA table. Critical: 30 days. High: 90 days. The federal deadline for a vulnerability that is being exploited right now is a third of that, and for the ones that hand over a network edge device it is sometimes counted in hours.
What the federal clock actually looks like
The deadline distribution in the catalogue is not a smooth curve. It clusters, and the clusters say something about how CISA thinks.
1,025 entries were given 21 days. That is the standard window for a vulnerability on a federal asset where exploitation is confirmed but the blast radius is contained by other controls. 283 got 14 days. 149 got 3 days. And 238 got 181 days, which is not a deadline so much as an acknowledgement that some of this stuff sits in places nobody can reach quickly, like firmware on a device with a ten-year support contract.
The recent additions are the ones worth staring at. On 29 October, GitLab Community and Enterprise Edition went on the list with a due date of 1 November. So did Cisco Secure Firewall ASA and FTD. Three days. On 26 October, the PHP Group appeared twice, memory corruption and a stale internal request-state bug, both due 29 October. Also three days. If you run a Laravel or WordPress estate, or a Magento storefront, PHP is not a dependency you can schedule around. It is the thing your application is made of.
Three days is not a realistic patch window for most companies, and that is exactly why the deadline exists. The federal government is not assuming patching is fast. It is saying that being exploited while you plan a change window costs more than the change window does.
Volume is the part nobody budgets for
The catalogue has grown 280 entries in calendar 2026, against 245 in 2025. In the 30 days before that pull, 35 new vulnerabilities were confirmed as exploited in the wild. In 90 days, 108.
Volume explains most of the mismatch. A quarterly authenticated scan produces 300 to 600 findings across servers, endpoints, network gear and whatever the marketing team installed on a subdomain. Those findings go into a spreadsheet sorted by CVSS score. Someone marks the top twenty as "in progress". The other 400 stay open until the next scan replaces them with 400 slightly different ones.
Nothing about that process is dishonest. It is just decoupled from the thing that actually determines risk, which is whether someone is exploiting the flaw today. A CVSS 9.8 in an internal Java library that no internet path reaches is less urgent than a CVSS 7.5 in an internet-facing appliance that appeared on the KEV list this morning. Most teams already know this. Their SLA table does not.
Severity scores don't tell you who gets hit
CVSS measures what happens if a vulnerability is exploited. It does not measure whether anyone is trying. That gap is where SLAs go wrong, because the score is fixed at publication and the exploitation is not.
Command injection is a useful lens. Across the whole catalogue, CWE-78, OS command injection, appears 106 times, and 16 of the 2026 additions carry it. That class of bug is popular because it converts any reachable input field into a shell, and a lot of the affected software sits on the perimeter. Network and edge vendors, the Ciscos and Ivatis and SonicWalls and Fortinets of the world, account for 301 entries, about 17% of the catalogue. Microsoft alone accounts for 390, Cisco 102, Apple 95, Adobe 83.
The e-commerce side shows up too. Adobe Commerce and Magento were added on 27 October with an unrestricted file upload bug. If you run that platform, the flaw that matters to you this quarter is not the one your scanner rated highest. It is the one that lets an unauthenticated person drop a PHP file into a media directory.
Ransomware is the other axis. 361 entries, 20.5% of the catalogue, are flagged as used in known ransomware campaigns. That share has fallen from 24% of the 2024 additions to 10% of the 2026 additions, which sounds like good news and probably is not. It more likely means extortion crews have moved to vulnerabilities they do not have to disclose as ransomware, or that the flagging lags the campaigns.
A tiering model that survives an audit
A defensible SLA ties the deadline to evidence rather than to a score. Four tiers cover almost everything, and none of them use the word critical.
- Tier 1 gives you 72 hours. The vulnerability is on KEV or has confirmed exploitation, and the asset is reachable from the internet with remote code or command execution. Mitigation counts here: disable the feature, put the admin interface behind a VPN, apply the vendor's WAF rule. What does not count is a ticket with a due date and no owner.
- Tier 2 gives you 14 days. Same exploitation evidence, but the asset sits behind segmentation or needs credentials the attacker does not have yet. The word "yet" is doing real work in that sentence, so the tier assumes the segmentation was tested rather than drawn on a diagram.
- Tier 3 gives you 30 days. No known exploitation, but EPSS sits above roughly 0.1, or CVSS is 9 and up on a reachable service. Most of the genuinely fixable work lives here.
- Tier 4 has no deadline. It gets the next maintenance window. Saying "this will be addressed in the normal release cycle" out loud is more honest than a 90-day SLA that nobody tracks.
Record the tier and the reason for it on every finding. Auditors rarely fail a company for having open vulnerabilities. They fail companies that cannot show a decision was made. An exception register with an owner, an expiry date and a compensating control will carry you further than a clean scan ever will.
Most patches don't ship because nobody owns the deploy
The reason a critical patch sits open for 45 days is rarely that the security team did not know about it. It is that applying it requires a deploy nobody has the authority, the test coverage or the rollback plan to perform. The blockers repeat in the same order every time. There is no staging environment that matches production, so the patch is tested nowhere real. There is no rollback path, so a failed upgrade becomes an outage with no exit. The application pins an old PHP minor version because a plugin breaks on anything newer. One person knows how the appliance is configured and they are on holiday. Change freeze is in effect for month-end, which for a retailer means half the quarter.
None of those are security problems. They are software delivery problems that security inherited. Which means the fix is not a stricter policy. It is making the deploy cheap enough that a three-day window is plausible: a real staging environment, an automated rollback, dependency versions that are not pinned three years back, and a rule that someone other than one person can rebuild the box.
Companies that can deploy on a Tuesday afternoon do not need a 72-hour SLA tier. They just patch. Companies that cannot deploy without a change advisory board meeting will miss every deadline they write down, no matter how the table is formatted.
Measure four numbers, not one
If you are going to report on this, report on the four things that would actually change behaviour. Report time to remediate by tier as a rolling 90-day median, because one forgotten finding drags an average into nonsense. Count exposure days per asset, meaning the days an asset was both internet-reachable and carrying a known-exploited vulnerability, since that number is the actual window an attacker had. Track exception aging, and specifically the oldest exception past its expiry date, because a register that is never audited stops being a register. And measure verification coverage: how many closed findings were confirmed closed by a rescan of the same asset and the same check. Ticket status is not evidence. The patch landing and the scanner agreeing is evidence.
All four are computable from data you already have. None of them require buying another platform. They require putting the asset inventory, the scanner output and the deployment log in the same place, which is usually a week of scripting and a decision about who owns the join.
Where these numbers come from
Every figure above was counted from CISA's public KEV JSON feed, catalogue version 2026.10.29, published 29 October 2026 at 19:09 UTC. The 1,764 total, the deadline distribution, the vendor counts, the 280 additions in 2026 and the 361 ransomware-linked entries all come from that file rather than from a vendor blog. The definition of the network and edge vendor group (301 entries) is the set of appliance and edge-security vendors named in the catalogue, which is a judgement call, not a CISA classification. Anyone can repeat the count: the feed is a single download, no key, refreshed most weekdays, and it changes every week. Re-run it before quoting the totals in a board deck.
What to do first
Start by pulling the CISA KEV feed. It is a public JSON file, updated most weekdays, no key needed. Join it against your asset inventory on CVE, not on product name, because product name matching fails the moment a vendor renames a component.
Take the intersection, the assets that are both on KEV and reachable from the internet, and treat that list as the only true priority queue you have. In most mid-size environments it is short, often under a dozen items, and it is frequently not the top of the CVSS-sorted list.
For each one, write down either the patch date or the mitigation. A mitigation with a named owner and a review date is a legitimate answer. Silence is not.
Then fix the delivery path for the one asset that would be hardest to patch under time pressure. It is usually the appliance nobody wants to touch, or the storefront with the fragile plugin stack. Getting that one to the point where a three-day patch is possible is worth more than tightening the SLA table for everything else.
Finally, change the policy language. Replace "critical vulnerabilities within 30 days" with deadlines that reference exploitation evidence and asset exposure. It is a shorter document, it is easier to defend in an audit, and it has the advantage of describing something your team might actually do.
