How do you secure legacy operational technology (OT) systems you can’t easily patch, replace or take offline?
Legacy OT systems still play a critical role across many operational environments. They were built for reliability, long life and stable control.
What they weren’t built for was constant connectivity.
That’s changed. Many legacy OT assets are now integrated into broader IT and vendor networks to enable telemetry, reporting and remote access. They also sit inside workflows where minutes matter and mistakes are expensive. That connectivity brings better reporting and operational insight, but it also changes what needs to be governed.
The opportunity isn’t to slow progress down. It’s to keep the value of connectivity while putting sensible guardrails around the parts that create exposure.
Why legacy OT doesn’t respond well to the usual fixes
It’s easy to say legacy systems should be upgraded or replaced. What’s harder is doing that in a live environment where those systems still support day-to-day operations.
In many cases, patching can introduce instability. Upgrades may require downtime the business can’t absorb. Some systems are tied to vendor constraints, ageing hardware or warranties. These factors limit what can safely be changed. Others still run on outdated platforms with limited support and few built-in security features. In some environments, logging, encryption and access controls are minimal or missing altogether.
So, teams end up balancing two real risks at the same time: the risk of leaving something as-is, and the risk of changing it and disrupting production. That’s not a failure of intent. It’s the reality of OT environments.
The win here is progress that operations can live with. Not perfect modernisation overnight, but iterative processes that reduce exposure and make decisions easier.
The biggest issue is usually the environment around the system
A legacy device on its own may be manageable. The same device inside a flat, weakly segmented network is a very different story, because small issues are harder to isolate and recover from.
Without clear boundaries, a compromise can travel further than it should. A weakness that could have stayed local becomes harder to control when it shares access with critical assets or remote pathways across the production environment. That’s when a technical issue becomes an operational one.
If you want this to feel more manageable, shift the focus from “how old is it?” to “what can reach it, and what depends on it?”
A practical way to do that is to pressure-test the basics:
- What does this system connect to, and what connects to it?
- What depends on it for production, quality or safety?
- Who can access it, and through which pathway?
- What would you need to isolate first if something went wrong?
- What would be impacted if you tightened access or segmentation?
These questions reduce surprises and help teams make safer decisions faster, especially when changes need to happen under pressure.
A safer path is to reduce exposure in stages
Large-scale replacement programs take time, budget and planning. Production doesn’t pause while that happens.
For many organisations, the more practical approach is to reduce exposure around what exists today. That might mean ring-fencing high-impact systems, tightening access paths, improving monitoring, and introducing boundaries that limit how far an issue can spread.
This isn’t about doing “more security” for its own sake. It’s about making the environment more predictable. That predictability supports uptime, safer change, and easier recovery when something goes wrong.
And there’s real value in that. When the environment is easier to govern, teams can move faster with more confidence, instead of defaulting to delay because change feels too risky.
Start with visibility before you tighten boundaries
Reducing exposure only works when teams understand what they’re reducing. Otherwise, it’s easy to introduce rules that create friction, or worse, accidental downtime.
Before segmentation is tightened or access rules are changed, there needs to be a clearer view of traffic flows, dependencies and normal patterns across the environment. Which systems talk to each other? Which ones need external access? Which ones don’t? Which vendor pathways are still active?
This is where clarity pays off. It turns “we think this will be fine” into “we know what this change will impact”.
Focus on controls that lower risk without creating downtime
Once visibility improves, the next steps tend to be clearer. The best starting points are usually quiet, low-disruption changes that reduce exposure and make the environment easier to govern.
That might include:
- Ring-fencing critical systems and separating them from less sensitive areas
- Blocking unnecessary inbound and outbound internet access
- Applying time-based access rules so exposure is lower outside support windows
- Tightening vendor pathways so remote access is controlled and easier to review
- Checking operating system support and patch levels to understand what’s realistic
- Working with vendors where possible to confirm safe configuration and change options
None of this needs to be a big-bang project. The goal is steady progress: fewer unknowns, clearer pathways, and more confidence when change is unavoidable.
Legacy OT can still be secured sensibly
Legacy systems aren’t going away overnight. For many organisations, they’ll remain part of the operational environment for years to come.
That doesn’t mean teams are stuck. It means the approach needs to be realistic.
In legacy OT, progress usually comes from improving visibility, reducing exposure and strengthening boundaries around what can’t yet be replaced. The aim isn’t to make old systems perfect. It’s to make them safer, more manageable and less likely to create wider disruption when something goes wrong.
Want the broader context? Read the full Think Forward report for more practical insights on visibility, legacy risk and operational resilience in operational technology environments.
