There’s a rule in operational technology: if a control threatens uptime or safety, it probably won’t be implemented.  

That doesn’t mean teams ignore cyber risk. It means uptime and safety still come first. 

In OT environments, disruption has immediate consequences. Production can stop, safety risks can increase and recovery can become expensive very quickly. That’s why OT security must be practical and shaped around how the site actually runs. The controls that last are the ones teams can apply, govern and sustain without adding unnecessary operational risk. 

If you’re working through the question of accountability first, start with our related article on Where OT Security Ownership and the visibility gap across IT and OT.

So if patching is limited, legacy systems are common, and maintenance windows are tight, what does good security actually look like? 

Build security that works in live OT environments

Most security strategies make sense on paper. In OT, controls have to work in a live environment. In practice, that usually means working with a wide range of constraints, including: 

• Validation and testing requirements 
• Vendor guidance and support limits 
• Maintenance windows and production schedules 
• System stability and warranty constraints 
• Safety requirements and change approvals 

Patching is the clearest example. Historically, in OT environments, patching happens once or twice a year at most, and only when the business case justifies the effort and risk. Teams still have to weigh maintenance windows, vendor guidance, validation and system stability. 

That’s why effective OT security doesn’t rely on patching alone. It focuses on reducing exposure in ways teams can apply safely, without increasing downtime risk or creating safety concerns. 

The same principle applies to broader frameworks. They’re useful reference points, but they need to be adapted to the environment. When security is shaped around operational reality, it becomes easier to apply consistently, easier to govern, and more likely to stick over time. 

Reduce exposure, detect early, contain fast

A stronger approach is to start with what the environment can actually support, then make steady progress from there. That gives teams a practical starting point, clearer priorities and more confidence in where to act first. 

In practice, that means reducing exposure, detecting issues early and containing problems quickly. It also means choosing controls that improve resilience without forcing unnecessary change into fragile or highly constrained systems. 

Logging, monitoring and anomaly detection are good examples of this. They improve visibility, help teams spot unusual behaviour earlier and strengthen response without adding unnecessary friction.  

Earlier warning shortens response time and helps keep small issues small. Where patching isn’t viable, segmentation becomes more important, and if a problem can’t always be prevented at the source, containment becomes the priority, so the effected radius stays limited.

Controls that work quietly in the background often deliver the most lasting value. They strengthen resilience steadily, are more likely to stick, and are easier to run as part of normal operations. 

Make vendor access safer and easier to manage

Vendor remote access is often one of the clearest opportunities to reduce risk without disrupting operations. 

In many OT environments, third-party access has expanded over time. Different vendors use different pathways, and access set up for valid reasons is not always reviewed again. That creates unnecessary exposure and slows response when something goes wrong. 

A practical approach doesn’t need to be heavy-handed. Practical improvements include: 

• Standardise entry pathways where possible 
• Apply least privilege access 
• Limit access to defined time windows 
• Log and review sessions 
• Maintain clear internal visibility of who’s connecting, when and why 

This reduces complexity, strengthens accountability, and makes support easier to manage. 

Build confidence with tested recovery

Backups often follow the same pattern as patching. On paper, they exist. In practice, recovery can be less certain than people assume, and that uncertainty is what turns incidents into extended downtime. 

Testing can be irregular, and recovery steps often rely on manual work. Keeping backups consistent can be difficult where environments include older infrastructure, vendor-managed assets or multiple sites. The real risk is not simply having no backup. It is recovery that is slow, incomplete or carried out in the wrong order. 

The real test isn’t whether backups exist. It’s whether recovery will work when needed. Tested recovery builds confidence because it replaces assumptions with a process teams can follow under pressure. 

The key questions are simple: can systems be restored reliably, can they be recovered in the right order, and can the business tolerate the time it takes? 

Security that supports uptime, not competes with it

At the centre of all this is a rule many teams already understand: if uptime or safety are undermined by an OT security control, it won’t survive long in production. 

That means accepting that some controls will always be harder to implement in OT than in corporate IT. Resilience comes from practical improvements made steadily over time: better logging, stronger monitoring, tighter access control, more disciplined vendor access, tested recovery, and security awareness that becomes part of day-to-day operations. This is what sustainable OT security looks like: clearer governance, fewer surprises, and controls that support operations. 

Viewed this way, the goal isn’t to force a perfect security model onto the environment. It’s to make steady decisions that reduce risk without turning security into a source of disruption. 

_________

Want the broader context? Read the full Think Forward report for more practical insights on visibility, legacy risk and operational resilience in OT environments. 

If you’re reviewing OT security controls, RES. Business IT helps organisations prioritise practical improvements that reduce risk, support uptime and bring more clarity to security decision-making.