Here's a sentence more than a hundred organizations put their names to last week: where a system cannot be patched without disrupting essential services, apply and verify compensating controls.
The signatories include Microsoft, Google, AWS, Cisco, IBM, Oracle, and SAP. Every major security vendor: CrowdStrike, Palo Alto Networks, Fortinet, SentinelOne, Zscaler, Check Point, Darktrace, Tenable. Most of the largest US financial institutions: Citi, Capital One, Visa, Mastercard, U.S. Bank. 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, states the constraint that makes it hard, and asks for a specific kind of answer. The rest of this piece is about what that answer actually requires.
What the letter asks for
The letter isn't vague about what it wants. Its first instruction, under "Every organization," reads: 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. Then 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 this is harder than it sounds
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 a maintenance window 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.
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 to know the exploit first, which fails against anything new. Detection tooling tells you something happened. It reports, it doesn't prevent, and reporting after the fact isn't a compensating control for a system you couldn't afford to let change. 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.
The order that made it concrete
The day before the letter, the White House gave the abstract problem a physical example. On August 26, the administration signed an Executive Order declaring a national emergency over foreign-produced bulk-power system electric equipment. Be precise about what this is. It's a supply-chain and foreign-interference action under the International Emergency Economic Powers 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 is not 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, while 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 simply 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 is exactly the situation the compensating controls sentence describes.
What an enforcement control does 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. It cannot work against an exploit it has never seen, because there's nothing to match. The CISA advisory Axios cited, AA26-231A, describes an attack on US water systems using an apparent AI-generated exploitation script. An AI-generated exploit has no prior signature. It's new by construction. Against that, a control that depends on recognizing the attack has already lost.
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. Anything outside that state doesn't execute, whether it's a known exploit, a novel one, or an AI-generated script no one has catalogued. The difference isn't a matter of degree. Against a threat with no signature, it's the difference between a control that can work and one that can't.
Measuring one control against the requirement
Mimic builds known-good enforcement at the kernel. A system is profiled in its authorized operational state, and every subsequent change is evaluated against that baseline before it executes. Virtual Patching is the capability that maps to the letter's sentence. Measure it against the three constraints.
- ✓ Applies to systems that can't be patched. Virtual Patching intercepts the system calls an exploit needs to reach a vulnerable application, so it can protect software with no patch available yet, and software that will never get one. That includes end-of-life platforms and third-party code with no fix coming. The system doesn't need to change for the control to cover it.
- ✓ Doesn't disrupt essential services. Rules deploy without a maintenance window. Before enforcing, the platform can run in audit mode to record what would have been blocked, and candidate rules are backtested against the environment's own profiled behavior, so you see the effect before it's live. Rules apply as policy, so one can be withdrawn in seconds if it's wrong. Nothing about deploying the control requires taking the protected system down.
- ✓ Verifiable. The platform produces per-host, per-CVE, per-timestamp records automatically. Apply and verify becomes a report you can hand to an auditor or a board, per system, rather than an 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 to 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.
What compensating control covers each one today? Not in principle. Actually 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. The window it describes is measured in months.
The industry named the requirement. More than a hundred organizations agreed on what apply and verify compensating controls has to mean. The only question left is whether yours can do it today.
Compensating controls, answered.
What is a compensating control in cybersecurity?
+A compensating control is a safeguard you put in place when you can't fix a weakness directly, usually because patching or replacing the system would disrupt essential operations. It reduces the risk the weakness carries without requiring the underlying fix. The 2026 collective cyber defense open letter asks organizations to apply and verify compensating controls wherever a system can't be patched without disrupting essential services.
What does the collective cyber defense open letter ask organizations to do?
+The open letter, signed by more than 100 organizations including Microsoft, Google, AWS, CrowdStrike, and Visa, asks every organization to fix its highest-risk weaknesses, verify results without disrupting essential services, and raise the security bar for what it buys, builds, and deploys, including AI-generated code. Where a system cannot be patched without disrupting essential services, it asks organizations to apply and verify compensating controls.
How do you secure a system that cannot be patched without disrupting operations?
+You apply a compensating control that protects the system without changing it. The control has to meet three conditions the open letter implies: it works on systems that can't be patched, it doesn't disrupt the essential service, and its results are verifiable per system. Virtual patching meets these by intercepting the system calls an exploit needs, deploying without a maintenance window, and recording per-host results.
What is virtual patching and how does it work?
+Virtual patching protects a vulnerable application without modifying it, by intercepting the system calls an exploit needs to reach or manipulate that application. It can deploy within hours of a vulnerability's disclosure, before a vendor patch exists, and it covers software that will never receive a fix, including end-of-life platforms. Because it applies as policy, a rule can be withdrawn in seconds if needed.
Can you verify that a compensating control is working?
+Yes, and the open letter requires it: the instruction is to apply and verify. Verification means proving the control works per system, not asserting it in general. A control that records per-host, per-CVE, per-timestamp results gives you evidence you can hand to an auditor or board for a specific machine. Controls that only reduce risk broadly, like network segmentation, can't verify protection on any single system.
How do you defend against AI-generated exploits with no known signature?
+With a control that doesn't depend on recognizing the attack. Detection matches activity against known threats, so it can't catch an exploit it has never seen, and AI-generated exploits are new by construction. Enforcement asks a different question: was this change authorized? Anything outside the system's authorized state is blocked, whether the exploit is known, novel, or AI-generated. A 2026 CISA advisory documented an AI-generated script against US water systems.
What is kernel-level enforcement and how does it differ from detection?
+Kernel-level enforcement evaluates changes at the operating system's core, before they execute, against a profile of the system's authorized state. Detection works differently: it watches activity and flags what matches known-bad patterns, after the fact. The distinction is prevention versus reporting, and prior knowledge versus none. Enforcement stops an unauthorized change without needing to have seen the attack before, which is what makes it effective against novel exploits.
How do you protect end-of-life systems that will never receive a vendor patch?
+You wrap them in a control that doesn't need the vendor to ship a fix. Virtual patching protects end-of-life platforms and unsupported third-party software by intercepting the system calls an exploit would use, rather than correcting the vulnerable code. The unsupported system keeps running unchanged, and the control carries the risk the missing patch would have addressed. This is often the only option when replacement isn't feasible.
What did the August 2026 bulk-power system executive order change?
+On August 26, 2026, the White House declared a national emergency over foreign-produced bulk-power system electric equipment. The order prohibits or conditions the purchase and installation of certain foreign-made grid equipment, including associated critical software, and lets the Secretary of Energy impose conditions on equipment already in use. It's a supply-chain and foreign-interference action, not a declaration about AI attacks, though it highlights the risk of deployed critical systems that can't be removed.
Does an enforcement control replace EDR?
+No. Enforcement and detection answer different questions and work well together. EDR watches for known-bad activity across endpoints and gives your team visibility and response. Kernel-level enforcement prevents unauthorized changes before they execute, including changes with no known signature. One reports and responds, the other blocks. Most organizations run both: detection for coverage and investigation, enforcement for the systems that can't absorb a successful change.
