The 3-Day Patch Clock: What CISA's BOD 26-04 Means for Your MSP Contracts

A US directive should not, on paper, keep a Nottingham accountancy firm awake at night. And yet the phone calls have already started.

On 10 June 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) issued Binding Operational Directive 26-04. It shortens the window for remediating critical, actively-exploited vulnerabilities to three days for federal civilian agencies. Not 30 days. Not two weeks. Three days from the moment a flaw lands on the Known Exploited Vulnerabilities catalogue.

That rule binds American government bodies, not British SMEs. But if you sell software, run a portal, process data, or sit anywhere in a chain that eventually touches a US federal buyer — or a UK department mirroring the same logic — the clock is coming for your contracts. And it will arrive dressed as a clause in a Statement of Work, not a technical spec.

This post is about the paperwork, not the patching. Because the paperwork is where the money and the risk actually live.

How a federal rule reaches a Derby manufacturer

Contractual obligations flow downhill. A large defence contractor in the US supply chain gets told it must meet BOD 26-04 timelines. It cannot meet them if its own suppliers take a fortnight to patch. So it pushes the requirement down to those suppliers. Those suppliers push it to theirs. Eventually a mid-sized engineering firm in the East Midlands, three tiers removed from anything American, finds a new remediation clause in its renewal contract.

We have seen this pattern before. Cyber Essentials started as a UK government procurement requirement and quietly became a baseline that private buyers now demand from anyone they work with. The NIS Regulations did something similar for operators of essential services. A rule aimed at one sector becomes the price of doing business with anyone who touches that sector.

The sectors most exposed here are predictable:

• Government supply chain. Anyone bidding for public work, or subcontracting to a prime that does.
• Healthcare. NHS trusts and their software vendors already face tight expectations after the fallout from past ransomware incidents. A three-day norm gives procurement teams a ready-made benchmark.
• Finance. The FCA and PRA expect firms to manage third-party and technology risk closely. A widely-cited three-day standard becomes a useful stick for auditors and a difficult one to argue against.

If you fall into any of these, expect the language to appear in your next renewal. The question is whether your MSP contract can actually deliver it.

Pull out your current SLA and read the patch clause

Most MSP agreements written before 2024 contain patch windows that now look leisurely. The common phrasing runs something like: "Critical security updates applied within 14 days of vendor release; high-severity within 30 days." Some are vaguer still, promising only that patching happens "during scheduled maintenance windows," which might be monthly.

Hold that language against a three-day expectation and the gap is obvious. Worse, many contracts measure the clock from vendor release, whereas BOD 26-04 starts it from the point of known exploitation. Those are different triggers, and the second one is far less predictable. A vulnerability can sit dormant for months and then jump onto the exploited list overnight, restarting a three-day countdown you did not see coming.

So the first job is an audit. Go through every managed services contract and record four things:

1. The remediation window for each severity tier.
2. The trigger event — vendor release, discovery, or exploitation.
3. What counts as "applied" — pushed, installed, or verified across the estate.
4. The exceptions — reboots, change freezes, legacy systems that cannot be patched at all.

That last point matters more than people expect. A three-day commitment is meaningless if a third of the estate runs software the vendor no longer updates. Someone owns that risk, and the contract needs to say who.

The commercial reality: faster patching costs more

Here is the part boards need to hear plainly. Compressing a 14-day window to three days is not a stroke-of-the-pen change. It has a price.

Emergency patching outside scheduled windows means out-of-hours work, more testing capacity, and the acceptance that occasionally a patch will break something and need rolling back at speed. It means better asset inventories, because you cannot patch in three days what you cannot see. It often means paying for tooling that automates deployment and reporting rather than relying on manual effort.

An MSP that agrees to a three-day SLA without adjusting its price is either absorbing a cost it will resent, or making a promise it cannot keep. Neither serves you. A grown-up conversation about the commercials now is far cheaper than a breach-of-contract dispute after an incident later.

If you are the buyer, expect a fair MSP to ask for more money or a narrower scope in exchange for tighter timelines. If you are the MSP, be honest about what three-day remediation actually requires and price it properly. The firms that get burned are the ones that sign the clause to win the deal and hope the awkward vulnerability never comes.

Risk-based triage is the sane middle ground

A blanket three-day rule across every system is neither realistic nor sensible. Your internet-facing VPN gateway and a printer on an isolated VLAN do not carry the same risk, and pretending they do wastes effort on the wrong things.

The defensible position — and the one boards understand — is risk-based triage. That means:

• Three-day remediation for internet-facing and business-critical systems where an exploited flaw could cause real harm.
• Longer, tiered windows for lower-risk internal systems, documented and justified.
• A named process for exceptions, with sign-off and compensating controls, so that "we couldn't patch it" becomes a decision on record rather than an accident.

This framing lets you meet the spirit of BOD 26-04 where it counts, without committing to an impossible standard everywhere. It also gives your board something concrete to approve. "We patch our exposed systems within three days and accept a longer window for isolated internal ones, with the following exceptions" is a sentence a director can sign. "We patch everything as fast as we can" is not.

What to do before December 2026

There is a second date to watch. Beyond the June directive, the wider compliance milestone many contracts are pegging to falls in December 2026. That gives you roughly a renewal cycle to get your house in order. Use it.

• Audit every MSP SLA now against the four questions above.
• Map which of your clients or contracts sit in government, healthcare or finance supply chains, because those are where the clauses land first.
• Open renegotiation conversations early, before renewal, so timelines and pricing are agreed calmly rather than under pressure.
• Write your triage policy down and get board approval, so you have a documented risk position to point to.
• Fix your asset inventory, because no patch SLA survives contact with unknown devices.

The organisations that scramble in November 2026 will pay a premium for it. The ones that treat the next few months as a planning window will renegotiate on their own terms.

BOD 26-04 was written for Washington. But contracts do not respect borders, and neither do the vulnerabilities they are trying to contain. The three-day clock is already ticking in the drafts being written for your next renewal. Read the clause before you sign it.