How should security teams secure connected OT devices without relying on the old air gap?

Why This Matters for Security Teams

The old air gap is no longer a dependable control for connected OT because modern plants, utilities, and building systems increasingly share monitoring, maintenance, and vendor access paths with enterprise IT. Once that boundary is softened, the real security question becomes whether a device can prove who it is and whether it can be contained if it misbehaves. That is why device identity and segmentation matter more than assumptions about physical isolation.

Security teams also need to account for the way compromise spreads through trusted operational tooling. A single unmanaged controller, remote support session, or exposed protocol can turn a narrow device issue into a broader production event. The guidance in NIST Cybersecurity Framework 2.0 emphasises asset visibility and access control as foundational outcomes, but in OT those outcomes must be implemented with strong operational constraints, not IT-style defaults.

NHIMG research on the The State of Non-Human Identity Security shows how often organisations struggle to maintain confidence in non-human identity controls, especially when access sprawl grows faster than governance. In practice, many security teams discover the air gap has failed only after a vendor connection, maintenance pathway, or compromised credential has already bridged the environment.

How It Works in Practice

Securing connected OT devices starts with treating each device as a distinct workload identity, not just a network endpoint. PKI-based device certificates give security teams a cryptographic way to verify the device before it connects, while segmentation constrains what that device can reach after it is admitted. This is not a replacement for OT engineering controls, but it is a stronger trust model than assuming the network itself is isolated.

In practice, teams should combine:

• Device identity at enrollment, using certificates or similar cryptographic proof of identity.
• Short-lived trust where possible, so credentials are rotated and revocation is operationally realistic.
• Microsegmentation or zone-based segmentation to limit lateral movement between controllers, sensors, historians, and remote access services.
• Allowlisting for protocols and destinations, especially where legacy OT devices cannot support modern controls.
• Continuous monitoring for unexpected communications, because OT compromise often shows up as abnormal east-west traffic before it becomes an outage.

For identity design, the key idea is to shift from perimeter trust to explicit verification. That is consistent with Zero Trust thinking in the NIST Cybersecurity Framework 2.0, and it aligns with the practical lessons documented in NHIMG coverage of the Schneider Electric credentials breach, where trust boundaries around vendor access and credential handling are central concerns. The operational goal is simple: if one device is compromised, segmentation should make the blast radius small and visible.

These controls tend to break down when legacy OT assets cannot support certificates, when flat networks remain in place for operational convenience, or when remote vendors retain broad access that segmentation cannot realistically contain.

Common Variations and Edge Cases

Tighter device identity and segmentation often increases operational overhead, requiring organisations to balance containment against uptime, maintenance speed, and engineering supportability.

There is no universal standard for every OT environment yet, so implementation has to reflect protocol limits and safety requirements. Some devices cannot terminate TLS, some sites rely on serial-to-IP gateways, and some plants need carefully brokered vendor access for emergency support. In those cases, security teams may need compensating controls such as jump hosts, session recording, and strict maintenance windows rather than a pure certificate-first design.

The DeepSeek breach is not an OT case, but it reinforces a useful lesson: once trust is assumed rather than verified, lateral movement becomes easier than teams expect. For OT, the same principle applies with greater consequence because availability and safety are often tied to the same connected pathways.

Best practice is evolving toward a layered model: strong identity for devices that can support it, segmentation for everything, and explicit exceptions for legacy equipment. That approach is more durable than trying to recreate the old air gap with policy statements alone.

Related resources from NHI Mgmt Group

• How should security teams secure over-the-air updates for connected devices?
• How should security teams secure database access without relying on VPN trust?
• How should security teams phase out TLS 1.0 and 1.1 without breaking key services?
• How should security teams secure GitLab access from CI/CD pipelines?