The Three-Day Patch Window Breaks Your Change Process

CISA now gives federal agencies three calendar days to remediate the highest-risk vulnerabilities. Not fourteen. Three. The directive that sets that clock, Binding Operational Directive 26-04, names its own reason: AI-assisted vulnerability discovery has collapsed the gap between disclosure and weaponised exploitation. If your change advisory board meets weekly, it now sits outside the window a regulator has publicly called reasonable.

This is not a US federal problem you can file away. Nobody is going to fine a German Mittelstand manufacturer for missing an American deadline. What will happen is quieter and more expensive: when an auditor, an insurer or a NIS2 assessor needs a number to put behind the phrase "without undue delay," they will reach for the most specific published figure available. As of June 2026, that figure is three days.

What BOD 26-04 actually changes

The directive was issued on 10 June 2026 and binds Federal Civilian Executive Branch agencies. It replaces the flat clock that the Known Exploited Vulnerabilities catalogue used to imply, where KEV membership alone set urgency and every listed CVE got the same treatment. Urgency is now a function of four variables:

• Publicly exposed. Is the asset reachable from outside the network on a routable address?
• In the KEV catalogue. Is exploitation already confirmed in the wild?
• Automatable. Can an adversary automate every step of exploitation, from target discovery to payload?
• Technical impact. Does successful exploitation yield total control of the system, or only partial?

Those four produce a tiered clock. A KEV vulnerability granting total control gets three days with forensic triage. A vulnerability that is publicly exposed, automatable and grants total control gets three days even if it is not yet in the KEV catalogue, which is the genuinely new idea in the document. Most other KEV entries get fourteen days, lower-risk combinations get sixty, and anything matching none of the criteria is fixed on the next system upgrade.

The rationale CISA gives is worth reading straight. Remediation effectiveness has been falling: only 26 percent of KEV vulnerabilities were remediated in 2025, down from 38 percent the year before. Meanwhile AI-driven discovery keeps shortening the interval between a published advisory and a working exploit. The directive is not asking anyone to work harder. It is conceding that the old interval no longer exists.

The old clock and the new clock

The last row is the one that costs money. Everything above it is a policy edit. That row is an operating-model change.

Three days is shorter than most approval cycles

Walk the arithmetic on a real organisation. A vendor publishes an advisory on a Friday afternoon, which is when vendors publish. Your change advisory board sits on Tuesday. You are at day four before anyone has approved anything, and that is assuming the ticket was raised the same afternoon and the right engineer was not on leave.

The emergency path exists, of course. Most enterprises have one. In practice it requires a named approver who can be reached, an agreed maintenance slot, a rollback plan, and somebody willing to own an unplanned availability event on a Saturday. That is a process designed to be used two or three times a year. BOD 26-04 describes conditions that will fire considerably more often than that.

So the directive does not really say "patch faster." It says the decision has to be made in advance. If the four variables are met, the change is already approved, and the record gets written around it rather than before it. That is a different governance shape from the one most organisations run, and it is the same shape we have argued for in emergency firewall change management: the emergency path is only credible if it was designed calmly, months earlier, by people who were not under pressure.

The vCenter campaign proved the clock is real

If the three-day number sounds theoretical, July and August supplied the counterexample. Broadcom disclosed CVE-2026-59310 on 29 July, a directory-traversal flaw in the VMware vCenter Syslog server leading to remote code execution, rated CVSS 9.8, patched alongside four other defects in the same advisory cycle.

Exploitation began roughly five days after disclosure. The German incident-response firm Quirso found the campaign during an engagement and published on 10 August: 361 victim IP addresses across 47 countries, with more than half concentrated in Germany, the United States, Turkey, Iran and France. The attackers established persistence with a cron job running an open-source reverse SSH tool, and in at least one observed case followed up with ransomware. CISA added the CVE to KEV on 18 August; under BOD 26-04, federal agencies had until 21 August.

The number that matters in that paragraph is not 9.8 and it is not 361. It is five. Five days between a public advisory and the first intrusions is shorter than the interval most organisations need simply to schedule the work. Many of the victims were not negligent. They were still in the queue.

Germany took the largest share of that campaign, which makes this a domestic governance argument rather than an imported American one.

What it does to firewall change governance specifically

Look at which assets actually satisfy the three-day criteria and the picture narrows fast. Publicly exposed, automatable, total technical impact: that is the edge. Firewalls, VPN concentrators, load balancers, reverse proxies, hypervisor management planes. The devices in the three-day tier are, disproportionately, the devices your firewall team owns.

That creates a second problem the directive does not address, because it is not CISA's problem. Patching a perimeter appliance is rarely a self-contained act. It implies an availability event, usually a failover, sometimes a temporary policy change to keep traffic moving while a node is out. A three-day clock on the patch is also a three-day clock on all of that, which is why failover testing you have actually rehearsed stops being a maturity nicety and becomes the thing that decides whether you can meet the deadline at all.

It also assumes you can answer one question at any hour: which rules, objects and dependencies reference the affected device? An organisation running its rule base out of a spreadsheet cannot answer that inside three days, and the spreadsheet fails the audit for exactly the reason it fails the deadline. It is a record of intent, not a queryable model of state. The prerequisite work is ordinary and boring: a current, reviewed rule base, per a real rule-audit discipline, and drift detection so that what you think is deployed matches what is deployed, per policy drift detection. None of that is new advice. What is new is that the deadline now punishes its absence directly.

Europe will inherit the number without adopting the directive

NIS2 Article 21 and DORA both require timely handling of vulnerabilities and neither names a figure. That vagueness was comfortable while nobody had published a specific one. It is less comfortable now.

The mechanism is not legal, it is evidentiary. An assessor asking a KRITIS operator to demonstrate that its remediation timelines are appropriate has, until now, had to negotiate what appropriate means. From June 2026 there is a published, reasoned, four-variable model from a national cyber-defence agency sitting in the public record. It will be cited, in insurance questionnaires before it appears in regulation. Organisations already building NIS2 firewall evidence or working through KRITIS obligations should assume the question changes from "do you patch promptly" to "what is your defined clock, and where is the evidence you met it."

Four things to change this quarter

• Write the standing exception before you need it. Encode the four-variable trigger in the change policy itself, name the person who owns the decision at two in the morning, and define what evidence gets captured after the fact. A pre-authorisation nobody has written down is not a control.
• Build the exposure map in advance. You need to go from "vendor X published an advisory" to "these seven devices, these rules, this blast radius" in hours. That mapping is a data problem you solve on a quiet Tuesday, not during an incident.
• Rehearse the failover, not just the patch. If the appliance is in a high-availability pair, the deadline is met by the failover working, not by the binary being available. Test it on your own schedule, or discover it on someone else's.
• Capture the evidence at the same speed. The audit answer is never "we patched." It is "we patched on day two, here is the trigger that fired, the approval it inherited, the configuration diff, and the verification." Evidence produced weeks later is a reconstruction, and reviewers can tell. Automated verification checks against the device are what turn a claim into a record.

Why it matters

The three-day window is not an aspiration a committee talked itself into. It is a measurement of the adversary, published by an agency that watched its own remediation rate fall while exploitation accelerated. The organisations that will struggle with it are not the ones with slow engineers. They are the ones whose approval process was designed for a human attacker who needed a week to write an exploit, and who no longer exists in that form.

The fix is not urgency. Urgency is what you spend when the process failed. The fix is deciding, in advance and in writing, which changes are already approved, who owns them, and what evidence gets written down while the work happens. That is change management doing the job it was always supposed to do, at the speed the deadline now requires.

Want to know whether your current change process could survive a three-day clock? Run the free NIS2 Readiness Check and get a written view of where your firewall evidence stands today.