In August 2026, more than 150 organizations — Anthropic, Microsoft, Google, AWS, Cisco, banks, governments, and cybersecurity firms from around the world, including our own team at Faraday — signed an open letter led by OpenAI that resolves a dilemma every critical-infrastructure security team knows well:
“Where a system cannot be patched without disrupting essential services, apply and verify compensating controls.”
A hospital can’t take down the system controlling infusion pumps to apply a patch mid-surgery. A water treatment plant can’t reboot its SCADA system during peak hours. But “I can’t patch it” can’t be synonymous with “I do nothing.” This guide is about that third option.
What a compensating control is (and isn’t)
A compensating control is a measure that reduces the risk of a vulnerability without eliminating the vulnerability itself. It’s not a patch in disguise. It’s not “we’ll just monitor more and call it a day.” It’s a deliberate layer designed to make exploitation difficult, detectable, or low-impact even though the underlying bug is still there.
Concrete example: you have a legacy system with a known insecure deserialization vulnerability (a CVE with a public exploit), and you can’t update the library because it breaks compatibility with 15-year-old industrial hardware. The patch isn’t viable this week. The compensating control is.
Step 1 — Classify why it can’t be patched
Not all “can’t patch” situations are the same, and the control strategy depends on the cause:
- Unacceptable downtime (24/7 mission-critical systems) → focus on network controls and detection.
- Technical incompatibility (the patch breaks another dependency) → focus on isolation and input validation.
- Vendor no longer supports it (EOL, no updates) → focus on full segmentation and planned replacement with a firm date.
- Regulatory certification (recertifying the system after the change takes months) → focus on temporary controls with an explicit expiration date.
Step 2 — The four families of compensating controls
- Isolation and segmentation
- Dedicated VLAN with no direct internet access.
- Firewall with strict allowlist rules (not denylist) between the vulnerable system and the rest of the network.
- Data diode if the system only needs to send data, never receive it.
- Reinforced access control
- Mandatory jump host / bastion for any administrative access.
- MFA at the entry point, even if the legacy system itself doesn’t natively support it.
- Session recording for later audit.
- Filtering and virtual patching
- IPS/WAF with a signature specific to the known exploit (virtual patching) — blocks the attack pattern without touching the system.
- Reverse proxy that sanitizes input before it reaches the vulnerable system.
- Accelerated detection and response
- Monitoring specific to indicators of exploitation for that particular CVE (not generic monitoring).
- Response runbook with more aggressive reaction times than standard, given there’s no patch as a backstop.
Step 3 — Verify, don’t assume
This is the step most teams skip, and the one the letter explicitly calls for (“apply and verify“). A compensating control without verification is a promise, not a defense:
- Targeted penetration test: try to exploit the original vulnerability through the compensating control. If your red team gets through anyway, the control doesn’t work.
- Bypass simulation: what happens if the attacker already has access to the isolated VLAN through another route (e.g., a compromised device inside the segment)? The control must survive that scenario too.
- Periodic review: a compensating control isn’t “set and forget.” Review it whenever the environment changes (new device on the network, firmware change, etc.).
Step 4 — Document with an expiration date
A serious and common mistake: compensating controls become permanent by default because nobody put a date on them. Each control should record:
- The vulnerability it compensates for (CVE or description).
- Implementation date and owner.
- Mandatory review date (at most every 6 months for critical infrastructure).
- A real replacement plan (when the system will actually be patchable or migrated).
Without this, today’s compensating control is tomorrow’s technical debt — exactly what post #1 in this series will be auditing, three years from now.
Checklist
- ☐ Classify the root cause of why the system can’t be patched
- ☐ Choose control family(ies) based on that cause
- ☐ Implement isolation/segmentation as a minimum baseline
- ☐ Add virtual patching if an IPS/WAF is available
- ☐ Run a targeted penetration test against the implemented control
- ☐ Document with an expiration date and replacement plan
- ☐ Schedule periodic review (don’t leave it open-ended)
Part of a series on how to put into practice the principles from OpenAI’s open letter on collective cyber defense (August 2026). Back to the full guide.
