CISA's New Patching Directive and Why It Matters

CISA published Binding Operational Directive 26-04 yesterday, and told US federal agencies to switch from "patch everything" to risk-based patching driven by Stakeholder-Specific Vulnerability Categorization (SSVC). Most of the noise so far is about the three-day deadline for the worst vulnerabilities, and three days across a large estate is a tough ask. The paradigm shift matters more, though, and the line that best captures it sits near the bottom of the timeline table: "fix on system upgrade." As in, patch it whenever you next happen to rebuild the box. Could be next month. Could be never. That single phrase tells you where vulnerability management is heading.

What actually changed

For years, federal agencies patched on two blunt rules. BOD 19-02 said that if the CVSS score was high enough, you fixed it fast; BOD 22-01 said that anything on the Known Exploited Vulnerabilities (KEV) catalog had to be remediated. BOD 26-04 retires both. CVSS now appears exactly once in the whole directive, as an analogy for technical impact, which is quite a demotion for the score we've all hung our patching SLAs on. The replacement is SSVC, a decision tree which asks sensible questions about each vulnerability:

• Is the affected asset internet-facing?
• Is it on CISA's KEV catalog? i.e., known to have been exploited in the wild?
• Can an attacker automate the exploit?
• How much control does the attacker get if it works, partial or total?

Answer positively to enough of those and the remediation target gets tighter. By CISA's own summary, a vulnerability that ticks three or more of these boxes must be fixed in three days; from there it steps out to 14 days, then 60, then "fix on system upgrade" for the low-risk majority. The deadlines are measured in calendar days, so a clock that starts on a Wednesday means somebody is patching over the weekend.

Exploitation in the wild is only one input. An internet-facing asset with a vulnerability that hands an attacker total control gets 14 days even if nobody has been seen exploiting it, and if the exploit can be automated, that drops to three days.

Two of these changes deserve more attention than they're getting. Internal assets now carry hard deadlines, where the old directives mostly waved through anything not facing the internet as long as it didn't have a KEV vulnerability. And the worst bugs come with a new demand: alongside the patch, you have to run a forensic check to confirm nobody has already used the hole to get onto your network. Fix it, then prove you weren't too late. Plenty of organisations don't have that forensic capability in-house, and the requirement reaches internal assets in some cases too. The number of vulnerabilities needing this treatment should be small but the real pain will arrive when one of them is found in software deployed on a large part of your estate.

The "automate the exploit" question is where AI is changing the picture. More vulnerabilities are likely to become automatable as AI tooling improves, pushing them into the shorter remediation buckets, and the same tools are cutting the time it takes to develop an exploit in the first place. That's probably one of the drivers behind the ambitious timescales. CISA says as much: defenders can't afford to spend weeks on something that can be exploited autonomously, at scale.

Most vulnerabilities will land in that bottom "fix on upgrade" tier. That's CISA saying "stop spreading yourself thin, and put the effort where the risk actually is".

Why this affects you too

BOD 26-04 only binds US Federal agencies, but CISA's advice tends to spread. The KEV catalog began as a 2021 federal mandate and is now a standard prioritisation input far beyond government, across the private sector and internationally. This risk-based model looks set to follow it, because the old approach has stopped working.

Verizon's 2026 Data Breach Investigations Report found that organisations patched just 26% of the weaknesses on CISA's known-exploited list last year, down from 38% the year before, while the median time to fully patch a vulnerability stretched to 43 days, up from 32. The attackers, by contrast, have trimmed their side to days, sometimes hours.

When the challenge is so big, "patch everything" is impossible. CISA estimates that, with the new model, only about 1% of vulnerability instances needed the three-day treatment, and more than 60% could wait for the next system upgrade.

That 1% also softens the scariest number in the directive. Three days is brutal if you apply it to your whole estate today, because you're clearing years of backlog in one go. Once you're on top of the existing backlog, the flow of newly published vulnerabilities that tick three or more boxes in any given week is small, and a three-day turnaround on a handful of genuine emergencies is a very different proposition.

The fix-on-upgrade trap

Here's where I'd advise caution. "Fix on system upgrade" is a deliberate trade, defer the low-risk majority so you can throw everything at the genuine fires. The problem is that the categorisation is based on a snapshot, and a vulnerability in that least urgent bucket can turn urgent two ways. The obvious one is that your environment changes. The box gets exposed to the internet causing the deadline to jump to 14 or 60 days, or the vulnerability lands in KEV and 14 days applies. The quieter one is that the vulnerability turns out worse than first thought, when a new technique makes it automatable (60 days) or it grants more control than the original rating assumed. CISA can shorten the timeline. Can you keep track of these changes? If not, "fix on upgrade" quietly becomes "fix never," and attackers have exploitable vulnerabilities that they can target.

There's another failure mode. "Fix on system upgrade" assumes you actually upgrade on a schedule. Plenty of organisations have servers that haven't been rebuilt in years and, for them, deferring to the next upgrade is just a way of saying "leave it broken." If you use this tier, you need to build in a time limit by which everything gets patched regardless of score. That, along with re-running the triage as the facts change, is what stops the long tail rotting forever.

You should build your own version of CISA's table that works for you. As Michael Roytman, co-founder of Empirical Security and a co-creator of the Exploit Prediction Scoring System (EPSS) model put it, the table reflects the average risk across the federal government rather than your environment. The directive binds federal civilian agencies, whose internet-facing systems CISA scans itself and whose internal posture it sees through its continuous-monitoring dashboards. An internal box on your flat, unsegmented network is a very different risk to the same box sitting on a closely monitored federal network.

What the KEV list doesn't tell you

One of the four decision points of the model is the KEV catalog, which is backward-looking by design. A vulnerability is only added to the catalog after someone has been caught exploiting it.

Roytman estimates KEV captures only about 8% of observed exploitation, roughly 1,600 CVEs against the 17,800 his team has seen exploited, and around 82% of entries are over a year old. Excellent evidence of what hurt people last year; a weak guide to what's about to hurt you this week.

Then there's the timing. Of the vulnerabilities that do get exploited, VulnCheck found about a third were hit on or before the day they were publicly disclosed. Your three-day clock doesn't even start until CISA adds the entry or you spot it yourself, so on the fastest-moving bugs the attacker already has a head start.

One tooling shift is worth watching. For the CVEs it assesses, CISA publishes three of the four decision points, KEV status, whether the exploit is automatable, and the technical impact, through its Vulnrichment programme. The fourth, whether the asset is exposed, only you can answer, because it depends on your network rather than the bug. Coverage isn't complete, though. The enrichment leans toward newer and higher-risk CVEs, its scope has already been trimmed once, and it tags far fewer CVEs than commercial trackers do. Treat it as a strong free input rather than the whole picture. Even so, it's becoming a de-facto source of vulnerability intelligence, free to anyone who wants to add it as an input to their prioritisation process.

So, will they tighten 60 days?

My bet is that CISA squeezes the 60-day target down. The steps from 3 to 14 to 60 are steep, and AI is helping attackers move faster every month. The directive commits CISA to a "formal, data-driven reassessment" of these timelines.

But I'd push the point one step further. Shrinking the back end from 60 days to 30 is the obvious move, and the less important one. The bigger gap is at the front. The clock starts only when a bug hits a retroactive list, in a world where exploitation increasingly happens before the list updates. Tightening 60 days does nothing for the exploit that owned you on day zero. Watch the three-day deadline. If offensive AI keeps compressing the gap between discovery and exploitation, three days of exposure may itself turn out to be too long, and the only realistic answer at that point is automating remediation of the most severe vulnerabilities.

So the smarter response goes beyond patching faster. Stop treating a public catalog as your early-warning system. Predictive signals like EPSS, and your own environmental context showing what's exposed, will tell you where the fire is likely to start before KEV confirms it already has.

The real message of BOD 26-04 is understand your estate, and keep on top of the small percentage of vulnerabilities that matter this week.