Legacy on the factory floor: securing Windows XP and 7 systems you cannot patch

Industrial equipment is bought for fifteen to thirty years. The operating system under it lives far less. So on real factory floors the control PCs still run on Windows XP and 7, dropped from support long ago, with no more security updates coming. The question "why don't you just update" is useless here: often you genuinely cannot. A routine security patch can void the vendor's warranty on the installation, or crash a carefully tuned process. Both are a real cost, not an excuse.

So the task has to be framed differently. The goal is not a patched XP, which does not exist, but an isolated and controlled node with defense built around it.

Why you cannot just update

There are two reasons, and both are real.

The first is warranty and certification. The control PC is part of a certified installation. Touch its software and the vendor drops support, and sometimes the equipment's certification lapses with it. For regulated manufacturing that is not a small thing.

The second is the process itself. The software is validated against a specific OS build. An untested patch shifts timings, breaks a driver, stops the line. The engineer who refuses to push an update onto a running mill is more often right than lazy.

So the inability to patch is worth accepting as a permanent design constraint, not a temporary embarrassment about to be fixed. The equipment will outlive two or three more versions of Windows. Plan from that fact.

Changing the question: not patch it, but wrap it

If you cannot remove the node's own vulnerability, you remove its reachability and its blast radius. The security question moves from "how do we patch the host" to "how do we make sure a vulnerable host cannot be reached and cannot drag everything else down with it." Compensating controls around it instead of chasing patches.

The same logic by which a cyberattack on the IT network can halt physical infrastructure is worked through on the example of Colonial Pipeline. A legacy node is exactly the case where that boundary decides everything.

What to do in practice

1. Start with an inventory. You cannot protect what you do not know exists. A map: where the unsupported systems sit, what each one controls, what it connects to, who has access to it. Usually that map frightens people more than the XP boxes themselves.

2. Segmentation and isolation. The legacy node goes onto a separate network segment, cut off from the internet, with a tightly limited or one-way flow of data out. An infection must not be able to reach it from the office network, and must not be able to spread out of it. This is a principle of segmentation, not a one-off measure: more in zero trust in practice.

3. Lock down removable media and remote access. In practice malware reaches an isolated XP box not from the internet but from an engineer's USB stick or a contractor's laptop. That is the main vector, and it is the first thing to control.

4. Put compensating controls at the boundary. A modern firewall or a data diode in front of the legacy segment, traffic monitoring, virtual patching and IPS signatures for the known un-closable vulnerabilities. The defense moves off the host itself and onto whatever stands in front of it.

5. Turn on application allowlisting on the node itself. Even XP and 7 can restrict execution to a pre-approved list of programs. Nothing off the list starts. That is more reliable than chasing patches that will never come.

6. Keep a tested recovery image and a runbook. Assume that sooner or later the node will be hit. Then the whole question is how fast you bring it back. A golden image and a documented restore order beat hoping it will be fine.

7. Put end-of-life into the plan and the budget. "We cannot patch it" is not only a security matter, it is a capital-planning one. It is worth discussing a supported migration path or extended support with the vendor, and putting a real decommissioning date for the legacy, with money behind it, onto the roadmap.

Honest caveats

• Isolation is not invulnerability. A determined insider or a compromised contractor laptop will still reach it. Compensating controls lower the risk, they do not zero it. On the underestimated contractor door I have a separate note: contractor and vendor access.

• If this is critical infrastructure, "just isolate it" is no longer enough. Regulatory requirements come into play, and the defense has to be a compliance-grade program, not a set of improvised measures. On that, critical infrastructure security under 187-FZ.

• Hardware is mortal too. At some point the control PC dies and spare boards for it are no longer made. The real solution is a planned migration, and pretending it will not happen just stockpiles a bigger bill for later. I say honestly which nodes it is enough to wrap and which ones it is time to plan out of service. On how to assess the risk of that transition, a risk map for legacy modernization.

In short

• Industrial equipment outlives its OS by decades, so XP and 7 on control PCs is the norm, not sloppiness.
• You often genuinely cannot update: the patch tears the vendor warranty or crashes the process. These are real constraints.
• Since the host's vulnerability cannot be removed, you remove its reachability and blast radius: isolation plus compensating controls instead of chasing patches.
• In practice: inventory, segmentation, control of USB media and remote access, a firewall or diode and virtual patching at the boundary, allowlisting on the node, a recovery image, a decommissioning plan with a budget.
• Isolation lowers the risk, it does not zero it. For the oldest nodes the real solution is a planned migration, not endless wrapping.

If your factory runs PCs that are frightening to touch and impossible to update, that is exactly the situation you can bring under control without stopping the process. The place to start is an honest map of what sits where. Feel free to get in touch; the first conversation commits you to nothing. </content>