The Systems You Cannot Patch: Compensating Controls That Hold

Every company has one: the system that runs something important and cannot be patched. The vendor stopped shipping fixes. The application breaks under a newer operating system. The validation cost of an update exceeds the risk budget for the year. It sits on the risk register, meeting after meeting, with no exit date.

'We cannot patch it' is not a strategy, but neither is pretending the system will be replaced next quarter for the fourth year running. The honest middle path is compensating controls: changes around the system that make it harder to reach and less useful to an attacker while the replacement is planned for real.

Done properly, compensating controls are named, owned, tested, and time-bound. Done casually, they are a note in a spreadsheet that nobody verifies.

Key takeaways

• Inventory every unpatchable system explicitly; do not let them hide inside the general estate.

• Shrink who and what can reach each unpatchable system: network, accounts, protocols.

• Watch it harder than the rest of the estate, because prevention is weaker there.

• Every compensating control needs an owner, a test, and an expiry tied to a replacement plan.

• Report the list upward with residual risk, not just a count.

Step 1: Build the named list

Start with a complete inventory of systems that cannot receive security updates, with the reason for each: vendor end of support, application dependency, validation freeze, or hardware constraint. 'Old' is not a reason; the reason is why the patch path is blocked.

For each entry, record what the system does, what data it touches, and who owns the business process it serves. The owner is usually not IT. It is the person who would explain an outage of that system to a customer.

Step 2: Reduce what can reach it

The strongest compensating control is isolation. Put the system in its own network segment, reachable only from the specific machines and accounts that need it. Remove its route to the internet where one exists. Kill protocols it does not need.

Then tighten identity: dedicated accounts for that system, no shared logins, no reuse of credentials from the wider estate. If the system is compromised, its credentials should open nothing else.

NIST's zero trust architecture guidance describes exactly this pattern: policy enforcement as close to the resource as possible, with access granted per session rather than per network.

Step 3: Watch it harder

Where prevention is weak, detection has to be strong. Point your monitoring at the segments and accounts around unpatchable systems and set a lower bar for investigation than you would elsewhere.

This fictional example shows one manufacturer's compensating-control stack for an unpatched scheduling server. It is an illustration, not a prescription.

Layer	Control	Check
Network	Dedicated VLAN, no internet route, three allowed source machines	Quarterly firewall rule review
Identity	Two named service accounts, no interactive logins	Monthly account audit
Detection	All logons and file changes alerted	Weekly alert review
Recovery	Nightly export to isolated storage	Monthly restore test

Step 4: Give every control an expiry

A compensating control without an expiry date becomes the permanent architecture. Tie each one to a replacement or retirement plan with a date, even a rough one, and review both together.

The review question is simple: is the exit plan still real? If the replacement slipped a year, the compensating controls deserve fresh scrutiny, because the risk they suppress did not slip.

The go/no-go framing in the discussion of legacy system replacement is the right companion for forcing that exit decision.

The related discussion of legacy system replacement is worth your time alongside this one. The related discussion of backup is not recovery is worth your time alongside this one.

Frequently asked questions

How long can a system run on compensating controls?

There is no universal number. The honest test is whether the controls are tested, the risk is accepted in writing at the right level, and a funded exit exists. Years of indefinite deferral is a risk decision nobody made.

Is isolation enough on its own?

Usually not. Isolation reduces reachability, but the allowed paths still exist and the system is still unpatched. Pair isolation with identity controls, monitoring, and a tested recovery path.

Who should own the list?

Security or IT can maintain it, but acceptance of the residual risk belongs to the business owner of each system, with visibility at the executive level for anything customer-facing or safety-relevant.

A Defensible Next Step

Ask for the named list of systems that cannot be patched, with the compensating controls and expiry dates beside each. If the answer is a shrug or a single line on the risk register, start the inventory this quarter. Book a Decision-Clarity Call if you want help structuring it.