When should organisations prioritise Zero Trust for OT over perimeter upgrades?

Why This Matters for Security Teams

OT environments fail differently from enterprise IT. A perimeter upgrade can improve remote connectivity, but it does not change the underlying trust model if engineers, vendors, and maintenance tools still move through broad network paths. zero trust becomes the better priority when the organisation needs to limit lateral movement, reduce shared access assumptions, and make each session, device, and user prove intent before reaching control systems. The practical shift is from “can the traffic get in?” to “should this exact request be allowed now?”

This matters because OT compromise rarely begins with a dramatic perimeter failure. It often starts with over-permissive remote access, reused credentials, or a third-party connection that was treated as temporary but became permanent. NIST SP 800-207 Zero Trust Architecture frames the core principle clearly: access decisions should be based on context, policy, and continuous verification rather than network location alone. In OT, that thinking is especially valuable where uptime pressures make blanket lockdowns unrealistic.

In practice, many security teams encounter the weakness of perimeter-first thinking only after an engineer’s convenience path has already become the attacker’s path.

How It Works in Practice

Prioritising Zero Trust for OT does not mean replacing every legacy control overnight. It means sequencing the work so that identity, segmentation, and policy enforcement reduce exposure before the next perimeter refresh. The first step is to map which users, services, jump hosts, and vendors can reach critical assets, then remove standing trust wherever possible. That usually includes replacing broad VPN access with session-specific access, tightening administrative pathways, and making remote connections land in controlled brokered zones rather than directly on the control network.

Security teams should focus on a few practical moves:

• Separate IT and OT access decisions so a user’s corporate permissions do not automatically imply OT reachability.
• Use device posture, user identity, and session context to decide whether a connection is allowed.
• Segment critical zones so a compromise in one part of the environment does not expose the entire plant.
• Log and review vendor access paths, especially where maintenance accounts or shared credentials still exist.
• Keep safety and availability requirements explicit, because OT controls must respect process uptime and operational tolerance.

Current guidance suggests anchoring these changes to a Zero Trust roadmap rather than a pure technology swap. The NIST SP 800-207 Zero Trust Architecture model is useful here because it supports policy-based access without assuming that the network edge is trustworthy. For OT, that aligns well with staged implementation: brokered remote access first, stronger segmentation next, and deeper policy enforcement as asset visibility improves. The key is to reduce implicit trust before extending connectivity. These controls tend to break down when OT asset inventories are incomplete and remote vendor workflows are undocumented, because policy engines cannot make precise decisions without knowing what is being accessed and by whom.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance blast-radius reduction against maintenance speed and plant uptime. That tradeoff is real in OT, where emergency changes, legacy protocols, and vendor support windows can make strict enforcement harder to sustain. Best practice is evolving, but there is no universal standard for how quickly a mature OT environment should move from perimeter-centric controls to full Zero Trust.

Some environments still need perimeter investment first, particularly when the immediate problem is exposed remote entry points, unsupported firewalls, or a complete lack of network hygiene. In those cases, the perimeter upgrade is a stabilising step, not the end state. Once basic containment exists, the organisation should shift priority to explicit trust decisions, because perimeter hardening alone still leaves internal movement largely unconstrained.

Where OT and IT are tightly converged, the decision also depends on governance. If identity management, privileged access, and vendor onboarding are already weak, Zero Trust should be prioritised because it forces those weaknesses into view. If the organisation cannot yet distinguish between human operator access, service account access, and third-party maintenance access, the first Zero Trust gains often come from policy segmentation and stronger authentication rather than from deeper packet inspection. For implementation guidance on broader identity and access principles, NIST’s identity guidance remains relevant alongside Zero Trust Architecture, especially when remote administration is the main exposure path.

Related resources from NHI Mgmt Group

• When should organisations prioritise Zero Standing Privilege for non-human identities?
• When should organisations prioritise Zero Trust over SASE?
• Why do non-human identities complicate zero trust architecture?
• Why do non-human identities increase zero trust risk?