How should security teams secure machine-to-machine communication in operational technology and critical infrastructure environments?

Why This Matters for Security Teams

operational technology and critical infrastructure systems depend on machine-to-machine trust that often lasts longer than the processes it protects. When those connections rely on shared secrets, flat network trust, or static allowlists, an attacker who reaches one system can often reuse that trust to move laterally. NHI security is not just an IT hygiene issue here; it is a control plane issue for physical operations, safety, and availability.

Current guidance from the CISA cyber threat advisories consistently shows that adversaries target exposed credentials, weak segmentation, and poor visibility first. NHI Management Group’s Ultimate Guide to NHIs frames the same issue from an identity perspective: every non-human connection should be traceable to a specific workload, not just a subnet or device class. For critical environments, that means treating service-to-service traffic as authenticated identity exchange, not implicit trust between machines.

A recent NHIMG survey found that only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, while lack of credential rotation was cited as the top cause of NHI-related attacks by 45% of organisations. In practice, many security teams encounter machine-to-machine abuse only after a maintenance window, vendor connection, or forgotten certificate has already become the easiest path in.

How It Works in Practice

Secure machine-to-machine communication starts with a cryptographic workload identity for each service, controller, or gateway. In mature environments, that identity is issued, validated, and revoked independently of the network location. Standards-oriented approaches such as SPIFFE and short-lived tokens help prove what the machine is at runtime, while policy engines decide what it may do based on context, task, and destination. For authorisation, many teams now combine policy-as-code with request-time evaluation so access changes with the actual operation rather than a prewritten static rule.

For OT and critical infrastructure, the practical pattern is usually layered:

• Use mutual authentication for all east-west and north-south machine traffic.
• Issue short-lived credentials per workload or per task, then revoke automatically when the job ends.
• Bind access to the minimum command, topic, API, or PLC function required.
• Log identity, certificate, and policy decisions together so operators can reconstruct trust chains.
• Rotate secrets and certificates on a schedule that matches operational risk, not human convenience.

This is also where visibility matters. The NHI Management Group State of Non-Human Identity Security research found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is a useful warning sign for OT suppliers and remote support channels as well. Best practice is evolving toward zero standing privilege and explicit session-by-session validation, aligned with the control logic in NIST SP 800-53 Rev 5 Security and Privacy Controls.

These controls tend to break down when legacy controllers cannot do mutual TLS or when vendor-managed equipment requires persistent service accounts that cannot be scoped per task.

Common Variations and Edge Cases

Tighter identity controls often increase operational overhead, requiring organisations to balance stronger isolation against uptime, vendor support, and maintenance constraints. That tradeoff is especially sharp in brownfield OT, where patch windows are scarce and protocol support can lag modern security patterns.

Where mutual TLS is unavailable, current guidance suggests compensating with gateway-based identity translation, segmented trust zones, and strict session logging rather than letting unauthenticated device traffic flow freely. For high-availability systems, certificate rotation should be staged so failover pairs do not expire together. For remote operations, separate vendor identities from plant operator identities and treat every third-party connection as a time-bound exception, not a standing relationship.

There is no universal standard for this yet, but the direction is clear: machine identity must be explicitly owned, inventoried, and governed like any other privileged access path. That aligns with ENISA Threat Landscape findings on lateral movement and with critical infrastructure expectations under the EU NIS2 Directive. In practice, teams that postpone identity modernization usually discover the gap only after a vendor tunnel, forgotten service credential, or exposed management interface has already become part of the incident path.

Related resources from NHI Mgmt Group

• How should security teams implement data-centric cybersecurity in critical infrastructure environments?
• How should security teams implement IAM for critical infrastructure environments without disrupting operations?
• How should security teams reduce risk when privileged users need remote access across multi-region environments?
• How should security teams manage upgrades across multiple identity infrastructure components without creating compatibility risk?