Legacy PLCs are not going away. Shield them.

“Replace the legacy equipment” is not advice. A controller installed in 2006 may have fifteen good years left in it, a validated process built around it, and a replacement bill that includes a qualification campaign and a shutdown nobody has scheduled. It stays.

Anyone who has walked a plant knows the cabinet: a PLC with a firmware version the vendor stopped supporting years ago, a programming port that accepts any connection, no notion of a user account. It runs the granulator, or the clean-in-place skid, and it runs it well. The security assessment flags it in red, and the conversation stops there.

It should not stop there.

The standards expect this situation

IEC 62443 does not assume that every component can meet every requirement on its own. IEC 62443-3-3, the system-level requirements, has a clause on compensating countermeasures (4.3): when a component cannot provide a security capability itself, the system around it can. The controller cannot authenticate the engineering station; the network in front of it can decide which station is allowed to talk to it at all. NIST SP 800-82 Rev. 3 takes the same line for legacy OT devices.

What you can do instead

In practice, shielding an old controller comes down to five things.

• Give it its own zone, sized to the consequence. The PLC that runs a sterilisation cycle does not share a flat network with the canteen badge readers. Group it with the equipment it actually works with, and nothing else.
• Put a protective device in front of it and allow only what the process needs. An industrial firewall with a short rule set: the HMI, the historian collector, one engineering station. Where the device can read the industrial protocol, block programming commands from anywhere except that station.
• Take the engineering workstation off general duty. The laptop used to download the program is not the one used for email and supplier documents. A dedicated, hardened station, kept in the cabinet room or locked away, removes the commonest way in.
• Log what talks to it. Passive network monitoring on that segment gives you a baseline. When something new appears, a different station, a program download at 3 a.m., it stands out.
• Write down why it stays, who accepted the residual risk, and when that decision is looked at again.

None of this touches the controller itself, so none of it reopens the process validation. The firewall and the monitoring are changes to the infrastructure, handled under change control in their own right.

The part that matters at audit

An unpatched PLC behind a documented compensating control, with a residual risk accepted by a named person on a known date, is a managed situation. The same PLC with nothing written down is a finding. The technical work is often identical. What differs is whether anyone can explain it a year later, when the engineer who set it up has moved to another site.

So the file should hold: the reason replacement is deferred (cost, qualification, vendor support), the compensating measures and how to check they are still in place, the residual risk and who accepted it, and a review date. Tie the review to something that happens anyway, the periodic review of the computerised system or the next planned shutdown, or it will slip.

Old equipment is not the vulnerability. Undocumented old equipment is.

References

• IEC 62443-3-3:2013, System security requirements and security levels, clause 4.3, compensating countermeasures: webstore.iec.ch.
• NIST, SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security, September 2023: csrc.nist.gov.