PatchDay Alert
Analysis · 9 min read · 1,708 words By operations-desk

When breaking the maintenance window is cheaper than waiting

The change board exists to make change safer, not slower. Here's the operational math for when the window has to move.

When breaking the maintenance window is cheaper than waiting

It’s 9:14 on a Wednesday and the threat intel feed just lit up. A network-edge product you have twelve of is in CISA’s KEV catalog as of this morning, with a two-week deadline. Your maintenance window is Saturday night. The change board meets Thursday at 2pm. The vendor has a workaround in the advisory.

You have a decision to make, and it’s not the triage call. Triage already told you this is critical. The decision is mechanical: does this go in tonight as an emergency change, does it ride to Saturday, or does the vendor’s workaround buy you the four days?

That decision is what this post is about. The triage layer — what makes a CVE worth caring about in the first place — is its own conversation. Once triage says “this matters,” the window question is a separate calculation, and it’s one most teams haven’t formalized.

What the maintenance window is actually buying you

The window is a risk-pooling mechanism. Changes get batched, reviewed, rehearsed, and rolled together so that the cost of any one failure is absorbed by a process that’s prepared for failure. Rollback rehearsal happens. Stakeholder comms get sent. The on-call rotation knows the change is landing.

Break the window and you’re not skipping a formality. You’re moving the change into a worse part of the week, one where the help desk is staffed for a normal Wednesday, where the rollback playbook is in someone’s head instead of in the ticket, and where post-deploy validation gets done by whoever happens to be at their laptop at 10pm.

The DORA 2024 State of DevOps report is fairly direct about this. Only 19% of surveyed engineering teams hit the elite-level 5% change failure rate with under-an-hour recovery. The middle of the curve sits at 10-20% failure rates with recovery measured in days. DORA’s own framing: “when organizations depend on shortcuts to get emergency fixes deployed, they tend to introduce more problems than they solve.” Emergency changes are the textbook shortcut. They get deployed with less testing, less peer review, and less rollback rehearsal, because that’s what makes them emergency.

The “patch the patch” tax is the operational receipt for this. Microsoft’s January 2024 update KB5034441 was meant to fix CVE-2024-20666, a BitLocker bypass via the Windows Recovery Environment. The fix promptly started failing with error 0x80070643 on any machine whose WinRE partition was under 250 MB. Microsoft pulled and replaced the broken updates in August 2024, seven months after release. Every team that pushed KB5034441 outside their normal window absorbed seven months of failed-update tickets, rollback work, and partition-resize procedures, for a fix they could have waited on.

That’s not an argument against emergency patching. It’s an argument that the cost is real and you should know what you’re buying.

What you’re buying if you wait

Waiting has a price too, and the price is clearer than it was. VulnCheck’s analysis of 2024 KEV additions found that 23.6% of CVEs added to KEV in 2024 were exploited on or before the day they were publicly disclosed, down from 27% in 2023. Another 29.5% saw exploitation within a month. The trend on disclosure-day exploitation is slightly down year-over-year, but for roughly a quarter of the CVEs that ever get exploited, the maintenance window is already irrelevant by the time you read the advisory.

Mandiant’s M-Trends 2025 report put the median 2024 zero-day weaponization window at about five days from disclosure to first observed in-the-wild use. For one 2024 vulnerability disclosed on April 12 with proof-of-concept code public on April 13, Mandiant tracked more than a dozen separate threat groups exploiting it within two weeks. The top 2024 exploited CVEs Mandiant flagged were heavily weighted toward network-perimeter and remote-access gear: PAN-OS CVE-2024-3400, Ivanti Connect Secure CVE-2023-46805 and CVE-2024-21887, and Fortinet FortiClient EMS CVE-2023-48788.

This is the shape of the calculation. For a network-edge product with a working exploit in the wild, the bet that you have until Saturday is worse than even money. For everything else, the median says days not weeks, but the long tail says a meaningful fraction never get weaponized at all. The data does not support “patch everything tonight.” It supports “the assumption that you have a week is wrong often enough that you need a real reason to make it.”

What the frameworks expect

Auditors are more permissive of emergency change than the paperwork suggests, as long as the change is documented.

PCI-DSS 4.0.1, which fully replaced PCI-DSS v4.0 on December 31, 2024, governs requirement 6.3.3: critical-severity vulnerabilities must be patched within 30 days of release. The 4.0.1 revision narrowed this back from PCI v4.0’s broader “critical and high” to “critical only,” matching PCI v3.2.1. For PCI scope, a 30-day clock and a routine monthly window usually line up. You don’t need an emergency change in most cases unless the CVE is also actively exploited.

CISA Binding Operational Directive 22-01 is more aggressive. Federal civilian agencies must remediate every KEV entry by its catalog-specified due date. When the directive launched in November 2021, 100 of the initial 292 KEV entries had two-week deadlines. BOD 22-01 does not apply outside federal civilian agencies, but it sets the implicit industry expectation: if it’s on KEV, two weeks is the defensible window.

ITIL-aligned shops have “emergency change” as a defined category with its own approval path through an Emergency CAB. The framework expects you to document the justification, the risk assessment, the rollback plan, and the post-deploy validation, and to back-fill that documentation if you couldn’t produce it in real time. Auditors accept the emergency. They don’t accept “we just patched it.”

The mitigation question

The most operationally interesting case is the third lane: a vendor workaround that lets the full patch land in the next scheduled window.

The cautionary tale is PAN-OS CVE-2024-3400. Palo Alto’s initial guidance in April 2024 was to disable device telemetry on affected GlobalProtect firewalls. Within days, Bishop Fox researchers demonstrated bypasses for both recommended mitigations, including a path that triggered the command injection even with telemetry off. Palo Alto subsequently revised the advisory to say disabling telemetry was no longer effective. For roughly a week, customers who took the workaround at face value had a false sense of cover while UTA0218 was dropping a custom Python backdoor on vulnerable boxes.

Same pattern hit Log4Shell. The initial recommendation to set log4j2.formatMsgNoLookups=true was found incomplete within days, and Apache shipped 2.16.0 to disable JNDI by default.

The shape is consistent. Vendor ships workaround. Researchers find bypass within days. Vendor revises guidance. The operational rule that falls out: a vendor workaround buys time, not safety. If you accept the mitigation as your patching answer, set a hard 72-hour re-validation deadline and deploy the actual patch the same week.

The decision, mechanically

Once triage says “this is critical,” the window question reduces to three inputs:

InputBreak the windowRide to next window
Exploit statusActive in-the-wild use, public PoC, or on KEV with a short deadlineNo observed exploitation, no public PoC
Asset exposureInternet-facing, edge of trust boundary, in regulated scopeInternal-only, behind another control, out of scope
Mitigation qualityNo vendor workaround, or workaround already shown bypassableVendor workaround is non-trivial to bypass and you can validate it

If two of the three columns point to “break the window,” break it. If two point to “ride,” ride it and document the decision. If one of each, the deciding factor is usually mitigation quality, because that’s the only column you have leverage over.

CitrixBleed (CVE-2023-4966) is the clearest recent test of this model. Citrix’s October 10, 2023 advisory landed for a NetScaler bug that Mandiant later confirmed had been exploited as a zero-day since late August. CISA added it to KEV on October 18. From late October through November, LockBit 3.0 affiliates used it for initial access against Boeing Distribution, ICBC, DP World Australia, and Allen & Overy. The orgs that patched within 48 hours largely avoided the post-patch exploitation wave. The orgs that scheduled it for the following window, particularly the ones that didn’t also kill existing sessions (which the bug allowed attackers to hijack), were the named victims.

MOVEit (CVE-2023-34362) is the inverse. Cl0p began exploiting the SQL injection on May 27, 2023. Progress shipped the advisory four days later, on May 31. By then CISA later estimated more than 3,000 US organizations and 8,000 worldwide had been compromised. No window decision was available to make.

What the window is for

A maintenance window is not a deadline. It’s a piece of safety equipment. It exists because the cost of a botched change is high enough that we built a process to lower the cost of failure. When the cost of waiting exceeds the cost the window is buffering against, you break the window, but you break it because the math says so, not because the advisory feels scary. And you back-fill the paperwork, because the framework reviewer next quarter is going to ask.

The window is not free. Neither is breaking it. The work is knowing which one is cheaper this morning.

PatchDay Alert’s daily digest flags which CVEs are showing exploitation in the wild, which are on KEV, and which have working workarounds. The window math is yours. The inputs we can get you before the change board meets.

Sources

Share

X LinkedIn Facebook Email
Tags #patch-management #change-management #vulnerability-management

Related field notes

One email, every weekday morning.

You're in. Check your inbox.

Get the digest

Free. Weekday mornings. Plain English CVE triage.

Check your inbox to confirm.