When you can't patch a vulnerable system, you reduce the risk around it instead. Compensating controls make the vulnerability harder to reach, harder to exploit, or quicker to detect if someone tries. The main options are isolating the system, virtual patching with a web application firewall (WAF) or intrusion prevention system (IPS), disabling the vulnerable feature or service, restricting who can access it, and adding monitoring. Whichever you choose, document it, have a named owner accept the remaining risk, and set an expiry date so the arrangement doesn't quietly become permanent.

Why can't some systems be patched?

Every organization ends up with a few systems that can't take a patch on schedule, or at all. Common reasons include:

  • End-of-life software. The vendor no longer ships security updates for that version.
  • Vendor-certified configurations. Lab instruments, building management systems and industrial equipment are often supported only in a fixed configuration.
  • No patch exists yet. A vulnerability is public, but the fix is still weeks away.
  • The patch breaks something. An update conflicts with a business-critical application that can't be upgraded at the same time.
  • Uptime constraints. Some systems can't be restarted outside rare maintenance windows.
  • Embedded devices. Firmware may be hard to update or not updatable in the field.

None of these make the risk go away. They just move the work from patching to containment.

What is a compensating control?

A compensating control is an alternative safeguard that reduces the risk a missing control would otherwise have addressed. For an unpatched vulnerability, it blocks or narrows the path an attacker would use, or makes an attempt visible fast enough to respond.

It's not a fix. The vulnerability is still there, and a compensating control that isn't maintained can fail without anyone noticing. Treat it as a managed, temporary state with an end date.

NIST describes this situation directly. NIST SP 800-40 Rev. 4, its guide to enterprise patch management planning, includes a maintenance plan scenario for unpatchable assets built around isolation and other mitigating methods.

How do you isolate and segment an unpatchable system?

Isolation is usually the most effective control, because most attacks need network access to the vulnerable service.

A practical approach:

  1. Move the system into its own network segment or VLAN, separate from general user and server networks.
  2. Default-deny traffic in both directions. Allow only the specific flows the system needs, by source, destination and port.
  3. Block direct internet access, inbound and outbound, unless it's essential. Outbound blocking also limits what an attacker could do after a successful exploit.
  4. Route administration through a jump host with its own authentication and logging, rather than allowing direct admin access from user workstations.
  5. Test the rules. Scan the system from other segments to confirm that only the intended ports respond.

Segmentation works best when you understand the system's real dependencies. Spend time with the system owner before you tighten the rules, or you'll find the missing flow at the worst possible moment.

Can virtual patching with a WAF or IPS replace a patch?

Virtual patching means using a WAF or IPS rule to block traffic that matches a known exploit pattern before it reaches the vulnerable system. It can buy valuable time, especially for internet-facing web applications and network services.

It has limits that you should plan around:

  • It only protects traffic that passes through it. Any path that bypasses the WAF or IPS, including internal traffic, is unprotected.
  • Encrypted traffic must be inspected. If the device can't see inside TLS sessions, its rules can't match.
  • Signatures can be evaded. Attackers vary their payloads, and a rule written for one variant may miss another.
  • It has to be in blocking mode. A rule set to detect-only is monitoring, not a control.

Test the rule before relying on it, and watch for false positives that disrupt legitimate use. Virtual patching is a bridge to a real fix, not a substitute for one.

When should you disable vulnerable features or services?

Many vulnerabilities live in a component you don't actually need, such as an optional module, a legacy protocol, a remote management interface or a sample application. Turning it off removes the attack surface entirely, which is often better than guarding it.

Vendor advisories frequently list these workarounds. Before you apply one:

  • Confirm with the system owner that nothing depends on the feature.
  • Apply the change through normal change management so it's recorded.
  • Verify it worked, using a configuration check or a scan.
  • Make sure configuration management or a future update won't quietly re-enable it.

How should you restrict access to an unpatchable system?

Even when a system has to stay reachable, you can usually shrink who can reach it.

  • Network restrictions: allow-list specific source addresses, or place the system behind a VPN or an access gateway rather than exposing it directly.
  • Account restrictions: remove unneeded accounts, limit administrative rights to named people, and require multi-factor authentication on the access path wherever the system or gateway supports it.
  • Credential hygiene: replace shared or default credentials, and rotate any credentials that could have been exposed.
  • Application allow-listing: where supported, allow only approved executables to run on the host.

Fewer people and systems with access means fewer chances for stolen credentials or a compromised neighbor to reach the vulnerable service.

What extra monitoring should you add?

If you can't fully prevent exploitation, make sure you'd notice it. Monitoring on an unpatchable system should be more sensitive than your baseline, because you already know where the weakness is.

Useful measures include:

  • Forwarding logs off the system, so they survive if the host is compromised
  • Alerts for new accounts, privilege changes and new services or scheduled tasks
  • Alerts for unexpected outbound connections, especially to the internet
  • File integrity monitoring on key binaries and configuration files
  • Detection rules for the specific exploit technique, where the vendor or a public advisory describes it

Monitoring only counts if someone reviews the alerts and knows what to do with them. Agree on that before you rely on it.

How should compensating controls be documented?

Documentation turns an ad hoc workaround into a managed risk. Record the following for each unpatchable system, in a register rather than scattered tickets:

Item What to record
Vulnerability and asset The finding, affected systems and their criticality
Constraint Why patching isn't possible, with supporting evidence
Controls in place Each control and the attack path it addresses
Validation How and when each control was tested
Residual risk What risk remains after the controls
Risk owner The business owner who accepts that residual risk
Expiry date When the arrangement must be reviewed
Exit plan The upgrade, replacement or decommissioning date

The expiry date matters most. A common approach is to review at least quarterly for high-risk systems, with a hard limit such as twelve months before the exception must be re-approved at a senior level.

What does PCI DSS require for compensating controls?

If the system is in scope for PCI DSS, there's a formal process. PCI DSS v4.0, which replaces v3.2.1 when the older version retires on March 31, 2024, describes compensating controls in Appendix B and provides a Compensating Controls Worksheet in Appendix C.

The PCI Security Standards Council notes that compensating controls require a legitimate, documented technical or business constraint, and can't be used to retroactively cover a requirement that was missed in the past. Your assessor evaluates each one as part of the assessment.

How do you know compensating controls are still working?

Controls drift. Firewall rules get widened during troubleshooting, WAF rules get switched to detect-only after a false positive, and disabled services come back after an update.

Retest on a schedule and after any relevant change. Repeat the segmentation scan, confirm the WAF or IPS rule still blocks a safe test request, check that disabled features are still off, and confirm alerts still reach the right people.

Frequently asked questions

Is a compensating control the same as risk acceptance?

No. A compensating control reduces the risk, and risk acceptance is the formal decision to live with whatever remains. You usually need both: controls to bring the risk down, and a named owner to accept the residual risk.

How long can a compensating control stay in place?

Only as long as your exception policy allows, with regular reviews. Controls should come with an exit plan, such as an upgrade or replacement date, rather than being renewed indefinitely.

What if a system can never be patched?

Plan to replace or retire it. In the meantime, isolate it as tightly as the business can tolerate, and make sure leadership understands the risk and the cost of replacement.

Key takeaways

  • Start with isolation and removing unneeded features. Both shrink the attack surface rather than guarding it.
  • Use virtual patching to buy time, and understand exactly what it doesn't cover.
  • Restrict access and add targeted monitoring, and make sure someone owns the alerts.
  • Document every compensating control with a risk owner, validation evidence, an expiry date and an exit plan.
  • Retest regularly, because controls weaken quietly over time.