Zero Trust for OT Networks: A Practical Implementation Guide

  By Dustin Guttadauro, Product Line Manager - Telecom & Fiber, Infinite Electronics  

Key Takeaways 

•   Zero trust for OT networks means applying 'never trust, always verify' to every device, user, and session in the industrial environment — including legacy PLCs and RTUs that cannot authenticate themselves. For devices that can't participate in modern identity frameworks, the network enforces their identity instead. 

•   The practical challenge in OT zero trust is not the software — it's the 30-year installed base of devices that were designed for reliability, not authentication. A phased adoption roadmap that starts with inventory and visibility before attempting identity management prevents the most common implementation failure: trying to apply certificate-based authentication to devices that don't support it. 

•   Physical controls are the zero-trust foundation for the physical layer. A locked enclosure with a tamper switch is a physical 'verify' control. Fiber optic isolation at zone boundaries enforces micro segmentation physically, not just logically. Surge protection on field device ports protects the hardware whose integrity zero-trust policies depend on. 

•   The comparison between traditional perimeter security and zero trust OT is not primarily a technology comparison — it's a trust model comparison. Perimeter security assumes internal traffic is safe; zero trust assumes it isn't and requires evidence of authorization at every access point. 

For decades, industrial networks were designed around a simple assumption: once a device or user was inside the network perimeter, it could generally be trusted. That model worked when operational technology (OT) systems were isolated from corporate networks and remote connectivity was limited. Today, Industrial Internet of Things (IIoT) devices, cloud connectivity, remote maintenance, and IT/OT convergence have fundamentally changed that assumption, making implicit trust an increasingly significant security risk.  

Zero trust architecture replaces the traditional "trust but verify" approach with continuous verification for every user, device, and connection. While applying zero trust principles to industrial environments presents unique challenges—including legacy equipment, long equipment lifecycles, and strict uptime requirements—it provides a practical framework for reducing risk without compromising operational continuity. This guide explains how zero trust can be adapted for OT networks and outlines a phased approach for implementation. 

What does zero trust mean for OT and ICS environments?What does zero trust mean for OT and ICS environments? 

Zero trust is a security model defined in NIST SP 800-207 that eliminates implicit trust based on network location. In a traditional perimeter model, a device inside the corporate network or OT environment is assumed to be trustworthy simply because it's inside. Zero trust rejects that assumption: every access request — from any device, any user, any network position — requires explicit verification before it's granted. 

Applied to OT environments, this means three things: 

1.    Never trust, always verify: every device connection and user session must be authenticated and authorized, regardless of whether it originates from inside or outside the OT network perimeter 

2.    Least privilege: every device, user, and process gets access only to the specific resources it needs, not to the network broadly 

3.    Assume breach: design the network on the assumption that some devices are already compromised, and limit what a compromised device can reach 

The challenge in OT environments is that these principles collide directly with how industrial control systems were built. A PLC from 2004 running proprietary firmware has no concept of certificate-based authentication. A safety instrumented system cannot be rebooted to apply a software update without shutting down the process it protects. Availability is not just a business requirement in OT — it's often a safety requirement. 

Zero trust in OT is therefore not a direct port of the enterprise zero trust model. It's an adaptation that applies to the principles where devices can support them and enforces equivalent controls at the network level for devices that can't. 

How does zero-trust OT differ from traditional perimeter security? 

The table below compares the two models across 11 dimensions. The column headers frame the comparison in terms that matter security architecture decisions, not marketing positioning. 

The physical layer row in this table is the dimension of most zero trust OT discussions skip. Traditional perimeter security treats physical access as a facilities problem, separate from cybersecurity. Zero trust collapses that separation: if a network port is physically accessible to an unauthorized person, the logical controls upstream of it are irrelevant. Physical access controls, cable integrity, and surge protection are part of the zero-trust model — they are the 'verify' layer for the physical infrastructure. 

How does zero trust handle legacy OT devices that can't authenticate?  

Legacy device handling is the most common reason for OT zero-trust projects to stall or produce incomplete implementations. A security architect who has designed zero trust for a corporate IT environment approaches OT and immediately encounters devices that have no concept of certificate-based authentication, no ability to run an agent, and no tolerance for the latency that some identity verification processes introduce. 

The resolution is to separate the question 'Can this device authenticate itself?' from the question 'Can we verify access to this device? ' Legacy devices can't authenticate themselves — but network-level controls can enforce equivalent restrictions without requiring device-side participation. 

The safety-critical category at the bottom of this table is worth emphasizing. For safety instrumented systems — burner management systems, emergency shutdown systems, high-integrity pressure protection systems — the OT security principle is that availability and safety take absolute priority. No authentication mechanism should be applied to a safety system if its application could interfere with the system's ability to execute a safety function. Physical isolation, dedicated management paths, and passive monitoring are the correct approaches. 

Physical isolation for safety-critical devices meanssecure SCADA enclosures with access logging, dedicated cable runs that don't share conduit with general OT network infrastructure, andmakes fiber optic isolation at the boundary between the safety system and the process control network. No shared copper path means no electrical coupling — the fiber boundary enforces isolation that logical controls alone can't guarantee. 

What is a realistic, phased roadmap for OT zero trust adoption? 

The five phases below represent a sequence, not a menu. Each phase creates the foundation that the next one depends on. Organizations that skip Phase 1 and attempt Phase 3 — deploying certificate-based identity before they know what devices are on the network — consistently encounter the same failure: they find devices they didn't know existed, running protocols they didn't account for, communicating in ways their policy doesn't address. 

Phase 1: Asset inventory and network visibilityPhase 1: Asset inventory and network visibility 

You cannot apply zero-trust policies to assets you don't know exist. The first phase is pure discovery: understanding what devices are on the network, what protocols they use, what they communicate with, and what their current security posture is. 

In OT environments, this must be done passively. Active scanning — sending probe packets to devices to discover open ports and services — can disrupt OT devices that aren't designed to handle unexpected network traffic. A network scan that crashes a PLC or triggers a safety system fault is worse than not scanning. OT-aware passive monitoring platforms — Dragos, Claroty, and Nozomi Networks — all support passive discovery — identify devices by analyzing the traffic they generate, not by probing them. 

The output of Phase 1 is a device register with an IP address, MAC address, device type and model, firmware version, protocols used, communication peers, and a preliminary zone assignment. This register becomes the input to zone design in Phase 2 and identity management in Phase 3. 

Phase 2: Network segmentationPhase 2: Network segmentation 

Phase 2 implements the zone-and-conduit architecture that micro segmentation in Phase 4 will refine. A flat network cannot support zero trust — if every device can reach every other device, there is no boundary to enforce policy at. Zone segmentation creates those boundaries. The practical implementation is covered in detail in our guide onnetwork segmentation in manufacturing. 

From a zero-trust perspective, Phase 2 segmentation is a least-privilege network topology: devices are grouped by function and trust level, and inter-zone communication requires explicit authorization at a firewall or gateway. This is not yet zero trust — it's still network-level control rather than identity-level control — but it's the prerequisite for everything that follows. 

Fiber optic isolation at zone boundaries is a Phase 2 decision, not a Phase 4 refinement. Installing makes fiber optic isolation solutions at IT/OT and zone-to-zone boundaries during the segmentation phase means the physical boundary is established at the same time as the logical one — and it doesn't need to be retrofitted later when the physical infrastructure is already in place. 

Phase 3: Identity management for devices and usersPhase 3: Identity management for devices and users 

Phase 3 assigns verifiable identities to devices and users — the prerequisite for 'always verify'. For users, this means eliminating shared credentials, deploying MFA on all human access paths, and implementing privileged access management (PAM) for OT system access. For devices, the approach depends on capability, as shown in the legacy device table above. 

Device identity in OT zero trust takes three forms depending on device capability: certificate-based identity for modern devices that support it; network-enforced identity (dedicated port, IP, VLAN, and firewall rule scoped to that device) for legacy devices that can't authenticate; and gateway-mediated identity for serial devices where an Ethernet gateway acts as the identity-capable proxy. 

The identity management tooling used in enterprise zero trust — Zscaler, Palo Alto Networks, Illumio — all have OT-specific variants or partner integrations with OT security platforms. Xage Security is a purpose-built OT identity platform that handles the legacy device gap explicitly. The tooling matters less than the principle: every access event should be tied to a verified, logged identity, even if that identity is a network-enforced device identifier rather than a certificate. 

Phase 4: Micro segmentationPhase 4: Micro segmentation 

Micro segmentation extends zone-level segmentation to the device or cell level. In Phase 2, the granularity was: field zone, control zone, DMZ, enterprise zone. In Phase 4, the granularity is: PLC A in production line 1 can communicate with the SCADA server on port 502; PLC A cannot communicate with any other device. This is the 'assume breach' principle implemented architecturally — a compromised PLC can only reach the specific devices it's authorized to reach, limiting the blast radius of a lateral movement attempt. 

Software-defined perimeters and device-level firewall policies are the tools for Phase 4. OT deep packet inspection — filtering Modbus function codes, not just ports — is applied at this phase. The computational and configuration overhead is higher than zone-level segmentation, which is why it comes after the foundation is established rather than at the start. 

Not every device in every environment will reach full Phase 4 micro segmentation. Safety-critical systems that are physically isolated, devices on fully air-gapped segments, and legacy serial devices behind protocol gateways may be addressed adequately by the lower phases. The goal is to identify which devices carry the highest consequence of compromise and apply micro segmentation there first. 

Phase 5: Continuous monitoring and responsePhase 5: Continuous monitoring and response 

Zero trust is not a state you reach — it's an operational posture you maintain. Phase 5 is the ongoing monitoring, alerting, and policy review that keeps the zero trust architecture current as the environment evolves. 

OT-aware intrusion detection systems operate at this phase, providing the 'continuous verification' that the zero trust model requires. They monitor device behavior against the baseline established in Phase 1, alert on new device connections, anomalous protocol behavior, and unexpected communication paths. A PLC that starts communicating with a new IP address is a zero-trust violation — either the policy needs to be updated to reflect a legitimate change, or the communication needs to be investigated. 

Quarterly policy review is the operational discipline that prevents zero trust from drifting back toward permissive. New devices, retired equipment, updated vendor access requirements, and topology changes all affect policy accuracy. Without scheduled review, the policy that was correct at deployment gradually diverges from the network it's supposed to describe. 

How do physical controls implement zero trust principles at the infrastructure layer? 

The software and network controls described in the five phases above sit on physical infrastructure — cables, enclosures, switches, connectors — that can be compromised, damaged, or bypassed regardless of what logical policies are configured above it. Zero-trust architecture that ignores the physical layer has a gap that logical controls can't close. 

Physical Controls for Zero Trust 

1. Install locked industrial enclosures to prevent unauthorized physical access.  

1. Deploy fiber optic isolation between IT and OT zones.  

1. Protect field devices with Ethernet surge protectors.  

1. Use shielded industrial Ethernet cables in high-EMI environments.  

1. Apply tamper-evident seals to critical cable connections.  

1. Review and inspect physical security controls during scheduled maintenance. 

Locked enclosures as 'always verify' physical controlsLocked enclosures as 'always verify' physical controls 

An unlocked network enclosure on a production floor is a physical bypass of every logical control in the network. Anyone with physical access can plug into the switch inside, connect to an OT device port, or remove a fiber uplink.Secure industrial enclosures with keyed access and tamper switches wired to SCADA inputs create a physical 'verify' layer: access to the enclosure is logged, alerts are generated when the door opens, and the access event is tied to a scheduled maintenance record or flagged as unauthorized. This is 'always verify' applied to the physical layer — the same principle as MFA for users, applied to door access for network hardware. 

Fiber isolation as physical micro segmentationFiber isolation as physical micro segmentation 

Fiber optic cables carry no electrical current between their endpoints. This property makes fiber optic isolation at zone boundaries a physical enforcement of the logical micro segmentation implemented in Phase 4. A voltage transient, ground loop current, or surge event on the enterprise side of the network cannot propagate through a fiber boundary to OT equipment. The fiber link is not just a cable choice — it's a physical boundary that enforces zone separation in a way that logical firewall rules cannot. A misconfigured firewall rule can create an unintended path; no misconfiguration allows electrical energy to travel across a fiber optic link. 

What are the most common objections to OT zero-trust implementation? 

'Our OT devices can't support certificate-based authentication.' 

This is accurate for most of the installed base — and it's addressed by the legacy device handling matrix. The resolution is network-enforced identity, not certificate deployment. A PLC on a dedicated port with a firewall rule scoped to its IP and function code level is operating under zero trust principles, even though it has no certificate. 'This device can't authenticate' is not the same as 'we can't apply zero trust to this device.' 

‘We can't afford the downtime to deploy segmentation.’'We can't afford the downtime to deploy segmentation.'' 

Segmentation projects at manufacturing facilities do require planned maintenance windows, and those windows are real constraints. The phased approach addresses this by sequencing passive work before changes that affect traffic. Phases 1 and 2 (discovery and segmentation design) can be completed without touching production configuration. Phase 2 infrastructure changes (fiber runs, new switches) can be staged during planned shutdowns. Phase 3 identity changes for users — MFA, PAM deployment — don't touch OT device configuration at all. The work that does require maintenance windows is limited to firewall cutover and device-level policy changes, which can be planned months in advance. 

'Zero trust is an enterprise IT concept that doesn't translate to OT.''Zero trust is an enterprise IT concept that doesn't translate to OT.' 

The objection is partially correct: enterprise zero trust tools built for Windows endpoints, and cloud applications don't translate directly to OT. The principles do translate. At least privilege access, verified identities, micro segmentation, and continuous monitoring are as applicable to a PLC as to a laptop — the implementation is different because the device is different. OT-specific zero-trust platforms (Xage Security, Claroty, Dragos) have adapted the model specifically for the constraints of industrial environments. The conceptual framework is the same; the tooling is different. 

The physical layer is the zero-trust foundation you can't configure away 

Zero-trust architectures at the software and network layer depend on the physical infrastructure beneath them being trustworthy. A network port accessible to unauthorized personnel, a cable run that introduces EMI noise into the packets your IDS is inspecting, or a surge event that damages a firewall port — each of these is a physical-layer failure that undermines logical controls regardless of how well they're configured. 

L-com's secure industrial enclosures address the physical layer gap that software-focused zero trust vendors don't cover. If your zero-trust OT architecture doesn't include a physical controls specification, it's missing a layer — and it's the layer that attackers with physical access will find first. 

Frequently Asked QuestionsFrequently Asked Questions 

Q1: What is zero trust for OT networks?Q1: What is zero trust for OT networks? 

A: Zero trust for OT (Operational Technology) networks is a security architecture that eliminates implicit trust based on network location and requires explicit verification of every device, user, and session — applied to industrial control systems, PLCs, SCADA servers, RTUs, and the networks that connect them. It adapts the NIST SP 800-207 zero trust model for OT-specific constraints: legacy devices that can't authenticate, availability requirements that limit when changes can be made, and safety systems that cannot be disrupted by security controls. 

Q2: Can zero trust be applied to legacy PLCs and SCADA systems?Q2: Can zero trust be applied to legacy PLCs and SCADA systems? 

A: Yes, with a different implementation approach than for modern devices. Legacy PLCs cannot participate in certificate-based authentication or run security agents. Zero trust is applied to them through network-level controls: dedicated network ports, IP-specific firewall rules scoped to their communication requirements, OT protocol deep packet inspection that limits what commands can reach them, and passive monitoring that detects deviations from their communication baseline.  

Q3: How long does OT zero-trust implementation take?Q3: How long does OT zero-trust implementation take? 

A: A realistic timeline for a mid-size manufacturing plant (200–500 OT devices) across all five phases is 18 to 36 months. Phase 1 (discovery) takes 6–12 weeks. Phase 2 (segmentation) takes 3–6 months, depending on how many production lines need network changes and how frequently maintenance windows are available.  

Q4: What is the difference between network segmentation and micro segmentation in OT? segmentation in OT? 

A: Network segmentation divides the OT environment into zones — field, control, DMZ, enterprise — with firewalls controlling traffic between zones. This is a zone-level control: a device in the control zone can reach other devices in the control zone without additional inspection.