How to Protect Servers You Can't Patch

Updated October 27, 2026: added primary sources and corrected how this post described the letter's signatories and CISA advisory AA26-231A.

Here's a sentence more than a hundred organizations put their names to on August 27, 2026: where a system cannot be patched without disrupting essential services, apply and verify compensating controls.

The list of signatories has grown since launch. It includes Microsoft, Google, AWS, Cisco, IBM, Oracle and SAP, many of the largest security vendors and financial companies such as Citi, Capital One, U.S. Bank, Visa and Mastercard. The letter is a call for collective action on cyber defense, and it opens with a line worth reading twice: "We have a limited window to strengthen cyber defenses."

Read the compensating controls sentence again, because it's a specification. It names a problem most enterprises have and states the constraint that makes it hard. Then it asks for a specific kind of answer. The rest of this piece is about what that answer requires.

What does the open letter ask for?

The letter isn't vague about what it wants. Under "Every organization," it asks you to "Fix the highest-risk weaknesses, verify results without disrupting essential services, and raise the security bar for what you buy, build, and deploy, including AI-generated code." Three sentences later comes the line that matters most for anyone running systems that can't easily go down: "Where a system cannot be patched without disrupting essential services, apply and verify compensating controls."

One honest note before going further. As Axios reported, the signatories made no commitments, deadlines or specific investments. This is a statement of principles, not a funded program. That's worth keeping in view, and it doesn't weaken the point. When a hundred organizations that compete with each other agree on what the requirement is, the requirement is real even if the letter naming it is non-binding.

Why is it hard to protect a server you can't patch?

The compensating controls sentence contains three constraints. Each is manageable alone. Together they rule out most of the usual answers.

First, the control has to work on systems that can't be patched. That's the whole premise. If patching were an option, you'd patch.

Second, it can't disrupt essential services. The reason the system can't be patched is that taking it down, or changing it, breaks something that has to keep running. A control that needs downtime or a reboot to deploy has the same problem the patch had.

Third, the results have to be verifiable. Apply and verify are two verbs. The letter asks you to prove the control is doing what you think, per system, not to assert it.

The standards say the same. NIST's patch management guide calls these unpatchable assets and tells organizations to "plan to implement multiple types of long-term risk mitigation methods besides patching to protect vulnerable assets" (NIST SP 800-40 Rev. 4). CIS Safeguard 2.2 allows unsupported software only with a documented exception "detailing mitigating controls and residual risk acceptance" (CIS). CISA's Known Exploited Vulnerabilities catalog tells agencies to apply mitigations per vendor instructions or stop using a product when mitigations are unavailable.

For OT systems, CISA and its partners write that "The focus should shift to isolating vulnerable systems and applying compensating controls when patching cannot be promptly performed" (CISA and partners). Their asset inventory guidance asks owners to keep exploring controls for vulnerabilities "that cannot be patched immediately or are end of life" (CISA and partners), and CISA lists unsupported software in critical infrastructure among its Bad Practices.

Now walk the usual compensating controls against those three. Network segmentation reduces blast radius, but it doesn't verify that any single system is protected. WAF and IPS rules can block an exploit, but they need a rule for the vulnerability first, which leaves exploits nobody has analyzed uncovered. Detection tooling tells you something happened and acts on what it recognizes. Against a change it doesn't recognize, it has nothing to act on. Faster patching doesn't help at all, because the constraint was never patch speed. It was that patching disrupted operations.

Most compensating controls fail at least one of the three. The letter is asking for one that passes all three.

What does the bulk-power executive order add?

The day before the letter, the White House gave the abstract problem a physical example. On August 26, the President signed an Executive Order declaring a national emergency over foreign-produced bulk-power system electric equipment (White House). Be precise about what this is. It's a supply-chain and foreign-interference action under the International Emergency Economic Powers Act and the National Emergencies Act. It generally prohibits or conditions the purchase and installation of certain foreign-made grid equipment, "including associated critical software and digital capabilities" that could pose cybersecurity or operational risks. It isn't a declaration about AI-enabled attacks, and anyone who reads it as one will lose the thread.

Here's the part that connects. The order lets the Secretary of Energy impose conditions on the continued use and operation of equipment already installed, accounting for reliability, safety, availability of replacements and continuity of service. Sit with that. The federal government has identified specific deployed equipment as a national security risk, in an environment where the equipment can't be ripped out and continuity of service is an explicit constraint. That's the unpatchable critical system, stated at national scale. You can't remove it. You can't take it offline. You still have to reduce the risk it carries. That's the situation the compensating controls sentence describes.

NIST's OT security guide explains why that situation is common: "Software updates on OT cannot always be implemented on a timely basis," and outages "must often be planned and scheduled days or weeks in advance" (NIST SP 800-82 Rev. 3).

What does an enforcement control do differently?

There's a structural reason the usual controls struggle here, and it's worth naming because it points at what works.

Detection asks a question that requires prior knowledge: does this activity match something we know is bad? That model works against known attacks and starts behind an exploit it has never seen, because there's nothing to match yet. Axios tied the letter to a wave of attacks on critical infrastructure, including one on US water systems with an apparent AI-generated exploitation script, and linked CISA advisory AA26-231A. An exploit written on demand has no prior signature. Server enforcement doesn't reach controllers or field devices, which run their own firmware; the point here is the signature problem.

Enforcement asks a different question: was this change authorized? That question doesn't require knowing the attack in advance. It requires knowing the authorized state of the system. A change outside that state stops at the point of execution, whether it comes from a known exploit, a novel one or an AI-generated script no one has catalogued. Against a threat with no signature, that's the difference between a control that can act and one with nothing to match.

How does virtual patching measure up against the three tests?

Mimic Networks builds known-good enforcement at the kernel. Mimic profiles each protected server in its authorized state and checks each attempted change against that baseline before it executes. Virtual Patching is the solution that maps to the letter's sentence. Measure it against the three constraints.

• ✓ Applies to systems that can't be patched. Virtual Patching works in two forms, and both require baselining. Disruption blocks the specific mechanism an analyzed vulnerability depends on, so the exploit doesn't succeed. Containment limits what an exploit can do once it lands, so one safeguard can cover a whole family of exploits. It's part of Mimic's known-good enforcement approach. Neither form changes the vulnerable code, so it works where the patch is late or never coming, on servers running Windows Server 2016 and later or Red Hat Enterprise Linux 8 and later.
• ✓ Doesn't take the server down. Before a Virtual Patching safeguard goes live, Mimic replays it against the host's recorded behavior to show what it would block, so you see the effect first. No reboots required, and virtual patches roll back instantly. Virtual Patching deploys with Maintenance Mode, in which Mimic suspends enforcement and keeps monitoring, so plan the deployment window like any change.
• ✓ Testable on each server. Before a safeguard goes live, the replay shows what it would block on that host. That's a result for one machine, not a general assertion.

That's the whole claim in this section. The letter set the criteria. This is one control measured against them. Whether it's the right control for a given estate is a question the reader is better placed to answer than we are.

What should you do this quarter?

If you run systems that can't be easily patched, three questions are worth answering now.

Which systems in your estate can't be patched without disrupting operations? Most teams know the list informally. Write it down, with the reason each one can't be patched and who accepted the risk, as CIS Safeguard 2.2 asks for unsupported software. CISA's hardening guidance for communications infrastructure adds the habit that keeps the list short: "Monitor for vendor end-of-life (EOL) announcements for hardware devices, operating system versions, and software, and upgrade as soon as possible" (CISA).

What compensating control covers each one today? Not in principle. Deployed, right now.

Can you verify that control's results per system? If a regulator or your board asked you to prove it's working on a specific host, could you?

If those answers are uncomfortable, the letter's framing is the relevant one. By Axios's account, the signatories warned that organizations have only months to prepare. Some flaws are exploited by the day they go public: of the 491 vulnerabilities newly named as exploited in the first half of 2026, attackers were already exploiting 141 when those flaws went public, per the Zero Day Clock, read October 24, 2026.

‍