When You Can't Patch It, the Network Is Your Only Control

Most security advice assumes you can fix the thing: apply the patch, update the library, rotate the key. But some systems can’t be fixed at all. The vendor no longer exists, the runtime is a decade past end-of-life, and the flaws are structural — there is no patch, and there never will be one. I had to assess a system exactly like that, and it forced a useful shift in thinking: when you can’t change the system, the only security control you have left is what’s allowed to reach it. The network becomes the whole game.

Unpatchable is a real category, and it’s growing

We tend to treat “vulnerable” as “not yet patched.” But there’s a separate, harder category: software that cannot be remediated. An appliance whose vendor was acquired and shut down. A runtime so old the fix was never backported to it. An app that breaks if you so much as change its libraries. For these, the entire vulnerability-management playbook — scan, prioritize, patch, rescan — has no final step. You can scan it forever; there’s nothing to apply.

Pretending otherwise wastes everyone’s time. The honest first move is to name the system as unpatchable and stop looking for a patch that doesn’t exist. That reframes the question from “how do we fix it?” to “how do we contain it?”

If you can’t change what the system is, the only lever left is what can talk to it.

Segmentation is the compensating control

When the system itself can’t be hardened, security collapses onto a single principle: strictly limit what can reach it, in both directions. That’s not a consolation prize — for an unpatchable system it’s the highest-value control you have, and often the only one that actually works.

Concretely, that meant:

• Put the system on its own tightly firewalled segment, not the general network.
• Allow only the specific peers that genuinely need it, to only the specific ports they need — an allow-list, default-deny everything else.
• Never expose it to broad networks or the internet; reach it through a controlled path only.
• Restrict and monitor egress too, because a compromised unpatchable box is a launch point, not just a target.

You’re not making the box safe. You’re shrinking the set of things that can take advantage of the fact that it isn’t.

Know which “trusted” peers aren’t

The subtle part: segmentation assumes you can cleanly divide “allowed to reach it” from “not.” But the things on the allow-list are exactly the things that can hurt you if they get compromised. The most realistic attack on the system I looked at wasn’t a stranger — it was one of its own legitimate peers being compromised and abusing access it was supposed to have. The allow-list is necessary, but it’s not a force field; the peers inside it deserve their own scrutiny, because they sit on the trusted side of your only control. Treat them as semi-trusted, monitor their behavior toward the protected box, and don’t assume “on the allow-list” means “safe.”

Make the invisible visible

Unpatchable systems are often also un-instrumented — old, quiet, no real logging. That’s dangerous when the network is your only control, because you can’t see when the control is being tested. So part of containment is monitoring the boundary: alert on connections from anything that isn’t a known, expected peer, and watch the system for the actions that would matter most if it were compromised. You may not be able to stop an attempt at the application, but you can at least see it at the network edge and respond.

Containment buys time; it doesn’t retire the risk

The last honest point: segmentation contains the risk, it doesn’t remove it. The unpatchable system is still unpatchable behind its firewall. So containment should come paired with a plan to replace or retire the thing — funded, time-boxed, owned — because the network control is a holding action, not a destination. The move is “isolate it now, and use the breathing room to get rid of it,” not “isolate it and forget it.”

That’s the whole reframe: for systems you can’t fix, security migrates from the host to the network, and segmentation does the work patches normally would. It pairs with treating security as architecture, not decoration and with the honest triage that vulnerability management really is — some findings have no patch, only a boundary. If you’ve had to wrap a firewall around something you couldn’t fix, tell me how you contained it.