When our team talks to engineers at industrial sites about cybersecurity, one thing comes up almost every time. Not ransomware. Not nation-states. Time.
Specifically, the sheer age of the equipment they’re trying to protect.
Legacy OT systems are everywhere. Manufacturing floors, energy facilities, water treatment plants. Many of these environments are running PLCs and HMIs that were installed before the internet was a household word, and they’re still running because they work.
A controller that’s been reliably executing the same logic for 25 years isn’t a failure. It’s an engineering success story. The problem is that reliability and security are two very different things, and for a long time, industrial operators only needed one of them.
What “Legacy” Actually Means Out Here
In IT, legacy usually means something a few generations behind. In OT, legacy can mean Windows XP running an HMI that communicates over a protocol that predates TCP/IP, connected to a PLC that the vendor stopped supporting a decade ago. It means flat networks where every device can reach every other device because that’s how the plant was designed in 1994.
It means protocols like Modbus, DNP3, and BACnet that were engineered for deterministic performance over serial lines, not for an environment where someone might try to intercept or spoof your traffic.
Replacing any of this is harder than it sounds. You’re not just swapping out a server. You’re potentially taking down a production line, rewriting custom ladder logic, retraining operators, and hoping nothing breaks during commissioning.
The cost and disruption are real, and for a lot of organizations, the risk calculus has historically favored leaving things alone.
That calculus is changing.
The Air Gap Nobody Actually Has
Our team hears “we’re air-gapped” more times than we can count, and it almost never holds up under scrutiny. Maintenance laptops get plugged in. Vendors get remote access to troubleshoot equipment.
Historians push production data up to corporate dashboards. Someone grabs a USB drive from the office to transfer a config file. Every one of those is a potential entry point.
Truly isolated OT networks exist, but they’re rare, and they require constant discipline to maintain. Most facilities have some form of connectivity they either know about and have accepted, or don’t know about at all.
The latter is the more dangerous category. Once you assume your network can be reached, you start designing defenses that actually account for that reality.
Designing around the assumption of isolation just means the first time someone gets in, you have no way to see them.
Getting Control of a Problem You Can’t Replace
The practical answer for most operators isn’t a full infrastructure refresh. It’s building enough visibility and structure around what you already have that you can actually manage the risk.
That starts with knowing what’s on your network. Not the asset list from the commissioning binder that nobody’s updated since 2008, but a current, accurate picture of what’s actually communicating, what protocols it’s using, and what behavior is normal for each device.
In legacy environments, that kind of baseline is enormously valuable because it gives you something to measure against. When a PLC starts doing something it’s never done before, you want to know.
Network segmentation matters too. A flat network where everything can talk to everything is a gift to an attacker who’s already inside.
Separating OT zones from IT, controlling what can reach the control network, and limiting lateral movement don’t require replacing your old equipment. They require thoughtful architecture and the discipline to enforce it.
Remote access is another weak point worth addressing directly. Shared credentials, unmanaged VPN accounts, and vendor connections that were set up for a one-time job and never closed are all common in industrial environments.
Replacing those with controlled, audited access paths reduces exposure without touching the underlying systems.
Why Visibility Is Harder in OT Than People Think
Most security tools assume a certain baseline. They expect to run agents on endpoints, perform active scans, or rely on modern logging infrastructure. Legacy OT systems don’t cooperate with any of that. You can’t install an agent on a 30-year-old PLC. You can’t scan a production network without risking disrupting the process it controls. And many of these devices don’t generate logs in any format that a conventional SIEM was built to parse.
This is why OT-specific monitoring matters. Valkyrie is built around this problem. Rather than relying exclusively on network traffic, it collects telemetry from the hosts, engineering workstations, and control devices that are actually running the process. That gives you visibility into things that never show up on the wire, like malware sitting on an engineering laptop, unauthorized changes to device configurations, or undocumented assets that have been quietly living on the network for years.
It can also establish behavioral baselines for systems that can’t be probed or scanned, so when something genuinely deviates from normal, you get an alert that means something rather than noise. For environments that mix decades-old controllers with newer connected assets, having a single platform that can work across that range matters a lot in practice.
The Bottom Line
Legacy OT systems aren’t going away. The economics don’t support it, and frankly, a lot of them don’t need to go away. What needs to change is the assumption that age and isolation are a substitute for security. The air gap has eroded. Corporate and control networks are more connected than most organizations fully understand. And attackers who specialize in industrial targets know exactly which old protocols to exploit and which flat networks to traverse once they’re in.
The path forward isn’t about forcing legacy infrastructure into an IT security model it was never designed for. It’s about building visibility and controls that work within the real constraints of operational environments, giving defenders enough information to catch problems early and respond without taking the plant offline to do it. That’s the work our team does every day, and it’s why tools like Valkyrie exist.
