How should security teams apply zero trust to OT without disrupting operations?

Why This Matters for Security Teams

zero trust in OT is not a slogan. It is a change in how access is verified, limited, and observed without disturbing safety-critical control loops or uptime requirements. The practical risk is that teams over-apply IT-style controls, then discover they have broken maintenance workflows, vendor support paths, or time-sensitive plant operations. NIST’s NIST SP 800-207 Zero Trust Architecture makes clear that policy must be continuously evaluated, but OT environments also require staged enforcement and strong rollback. NHIMG’s Ultimate Guide to NHIs — Standards is especially relevant here because OT networks depend heavily on machine identities, service accounts, and secrets that are often long-lived and poorly visible.

The biggest mistake is treating segmentation as the finish line. Segmentation helps, but OT zero trust also needs identity inventory, asset-to-process mapping, and a realistic view of what “normal” machine communication looks like before policies are tightened. Without that baseline, the team cannot distinguish a legitimate PLC-to-HMI exchange from a lateral movement attempt. In practice, many security teams encounter unstable enforcement only after operations has already lost trust in the programme, rather than through intentional pilot design.

How It Works in Practice

The safest path is incremental. Start by inventorying all human and non-human identities that touch the OT environment, including vendor remote access, engineering workstations, service accounts, certificates, API keys, and any agent-like automation used for monitoring or orchestration. Then map those identities to the minimum set of assets, protocols, and time windows they truly need. That is the operational core of zero trust in OT: verify the requester, limit the action, and log the decision.

Implementation usually works best in three steps. First, establish visibility and passive monitoring so the team can observe traffic, authorisation events, and maintenance patterns without blocking anything. Second, introduce least privilege and segmentation boundaries that respect safety zones, with tighter controls around jump hosts, vendor access, and privileged sessions. Third, move toward stronger verification such as Guide to SPIFFE and SPIRE for workload identity and short-lived credentials, paired with policy enforcement at request time rather than static allowlists. Where credentials are involved, short TTLs and rapid revocation reduce exposure if a device or service account is compromised.

• Use baseline behaviour to define acceptable OT communication paths before enforcing blocks.
• Apply JIT access for maintenance and vendor sessions instead of standing privilege.
• Separate identity policy from network routing so safety logic keeps running if policy changes need rollback.
• Log both allow and deny decisions so changes can be validated against process impact.

This guidance breaks down in brownfield plants with undocumented dependencies, where a single legacy controller may require opaque broadcast traffic or hard-coded trust relationships that cannot be quickly segmented.

Common Variations and Edge Cases

Tighter zero trust often increases operational overhead, requiring organisations to balance stronger assurance against maintenance speed, vendor friction, and the risk of delayed response during incidents. That tradeoff is real, and current guidance suggests there is no universal standard for how aggressively OT should be segmented on day one. In high-availability plants, the first priority is usually to eliminate standing access and uncontrolled secrets, not to force every legacy protocol behind a perfect policy engine.

One common edge case is remote vendor support. The safer pattern is just-in-time access with approval, session recording, and expiry, rather than permanent VPN credentials. Another is safety-related automation, where intent matters more than identity alone. If a system can initiate actions autonomously, the team should consider whether the control objective is to authorise the device, the workload, or the specific intent at runtime. That is where OT zero trust begins to overlap with broader NHI governance and, increasingly, with workload identity design.

For teams modernising carefully, the best reference point is not a single product but a control model. NHIMG’s Schneider Electric credentials breach illustrates how credential exposure can become an operational issue, not just a security event. Combined with NIST’s architecture guidance, the lesson is straightforward: reduce implicit trust, shorten credential lifetime, and prove that each control change can be reversed without interrupting safe operations.

Related resources from NHI Mgmt Group

• How should security teams implement zero trust for workloads?
• How should NHS security teams reduce privileged access risk without disrupting clinical operations?
• How should security teams apply zero trust to SaaS environments?
• How should security teams start Zero Trust without creating tool sprawl?