How should security teams enforce Zero Trust in OT environments with machine-to-machine communications?

Security teams should pair continuous machine identity with threat detection so every machine connection is verified before it is trusted. In OT, that means authenticating devices, limiting which systems can initiate or maintain sessions, and enriching detections with identity context. This reduces blind trust in east-west traffic and gives responders clearer evidence for containment and recovery.

Why This Matters for Security Teams

zero trust in OT cannot rely on network location or a trusted plant segment alone, because machine-to-machine traffic often carries the exact commands that can halt production, corrupt process state, or trigger unsafe conditions. NIST SP 800-207 Zero Trust Architecture makes the core point clearly: access decisions must be continuously evaluated, not assumed from the source network. In OT, that means each device, controller, and workload needs a verifiable identity and a policy decision at the moment of communication.

This is where teams still get caught out. Legacy OT designs were built for availability and deterministic communications, while Zero Trust adds identity, policy, and telemetry requirements that many plants never instrumented. NHIMG research shows that 90% of IT leaders say properly managing NHIs is essential for a successful zero-trust implementation, which aligns with the OT reality that unmanaged service accounts, hard-coded keys, and shared credentials undermine segmentation before detection can even start. See the Ultimate Guide to NHIs and the Guide to SPIFFE and SPIRE for the identity side of this problem.

In practice, many security teams discover that a machine-to-machine trust chain is already broken only after a maintenance account, controller credential, or partner integration has been abused to move laterally.

How It Works in Practice

Enforcing Zero Trust in OT starts with shifting the trust anchor from the subnet to the workload identity. For machine-to-machine communications, that usually means authenticating each device or service with cryptographic proof, then authorising the specific action at runtime. The goal is not just to know that a session came from an industrial PC or PLC, but to know what that entity is allowed to do, under what conditions, and for how long. NIST SP 800-53 Rev. 5 supports this model through access control, audit, and system integrity controls that can be mapped to OT zones and conduits.

In mature environments, teams combine:

• Mutual authentication between systems using workload identity rather than shared passwords.
• Short-lived certificates or tokens tied to a narrow task, not a standing credential.
• Allowlisting for command types, source systems, and protocol paths.
• Policy evaluation at connection time, with logging that preserves identity context for response.
• Monitoring that distinguishes expected machine chatter from anomalous east-west movement.

That architecture is easier to operate when identity issuance and revocation are automated. The Guide to SPIFFE and SPIRE is relevant because it frames workload identity as a cryptographic primitive, which is a better fit for service accounts, edge gateways, and OT data brokers than static secrets stored in engineering laptops or PLC scripts. For broader control mapping, the NIST SP 800-207 Zero Trust Architecture remains the clearest baseline.

These controls tend to break down in brownfield OT environments where vendor-maintained systems, proprietary protocols, and safety constraints prevent per-connection identity enforcement without an integration layer.

Common Variations and Edge Cases

Tighter Zero Trust controls often increase operational overhead, requiring organisations to balance stronger verification against plant uptime, vendor access, and maintenance windows. That tradeoff is especially visible in OT because some systems cannot easily accept modern agents, certificate rotation, or inline policy enforcement. Current guidance suggests using compensating controls where direct enforcement is not yet possible, but there is no universal standard for this yet.

Common edge cases include legacy PLCs that only speak unauthenticated protocols, shared jump hosts used by integrators, and emergency access paths that must remain available during outages. In those cases, security teams should isolate the exception, bind it to a named machine identity where possible, and log every session with enough context to support containment. NHIMG’s Ultimate Guide to NHIs is useful here because it ties identity lifecycle management to Zero Trust execution, while the Schneider Electric credentials breach shows why exposed credentials can become a production risk, not just an IT issue.

Where segmentation is static, vendor access is shared, or identity telemetry is absent, Zero Trust degrades into perimeter theatre rather than enforceable policy.

Related resources from NHI Mgmt Group

• How should security teams govern machine identities in zero trust environments?
• How should security teams enforce just-in-time access in Zero Trust environments?
• How should security teams use PKI to support Zero Trust in mixed human and machine environments?
• How should security teams automate response when zero trust detections confirm an attack in progress?