Zero Trust for OT Networks: A Practical Implementation Guide

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

Zero Trust gets thrown around a lot in IT security circles. In OT, the reaction is often skepticism — and understandably so. Zero Trust frameworks were designed for environments where every endpoint runs a modern OS, agents can be deployed freely, and the network can tolerate authentication overhead. OT environments have none of these properties. 

But the skepticism undersells what Zero Trust actually is. It's a design philosophy, not a product. The core principle — don't assume anything inside the network perimeter is trustworthy; verify every access request explicitly — is more applicable to OT than to IT, because OT networks have been operating on implicit trust for decades, and that's exactly how attackers exploit them. 

What Is Zero Trust, and Does It Actually Apply to OT Networks? 

Zero Trust is a security model defined by three core principles: verify explicitly (authenticate and authorize every access request, every time); use least-privilege access (grant only the permissions required for the specific task); and assume breach (design the network as if an attacker is already inside and limit what they can reach). 

The term was coined by John Kindervag at Forrester Research around 2010 and formalized in NIST SP 800-207, published in 2020. It's most commonly associated with IT environments: replacing VPN-based perimeter security with identity-aware access controls, micro segmented networks, and continuous authentication. 

Applied to OT, the same principles hold — but the implementation constraints are different enough that 'Zero Trust for OT' deserves its own treatment rather than borrowing IT playbooks wholesale. 

Why Traditional Perimeter Security Fails OT Networks 

The dominant OT security model for most of the last 30 years has been perimeter security: build a wall between the OT network and everything else and assume everything inside is trusted. This worked when the perimeter was physical air gaps and serial cables. It stopped working when OT networks connected to IT networks, vendor remote access, and cloud platforms. 

The problem with perimeter-only security in OT is that once the perimeter is breached — through a phishing email that lands on an IT workstation, a compromised vendor VPN credential, or a USB drive plugged into an engineering workstation — there's nothing to slow lateral movement inside the OT network. Flat OT networks with implicit trust give an attacker who crosses the perimeter immediate access to every PLC, HMI, and SCADA server on the network. 

The Dragos annual OT threat report consistently finds lateral movement within OT networks as a key stage in ICS incidents. Zero Trust addresses this at the architectural level: even if an attacker gets inside, they hit enforcement points at every zone boundary and every access request. 

How Do You Implement Micro segmentation in an OT Network? 

Micro segmentation is the zero-trust control that has the most direct OT analogue — it's essentially a more granular version of the zone-and-conduit model in IEC 62443. The principle is the same: group devices by function and risk profile and enforce explicit rules about which groups can communicate with which other groups. 

 Start With the Zone-and-Conduit Model 

IEC 62443 defines zones as groups of OT assets with similar security requirements, and conduits as the controlled communication paths between zones. A SCADA server zone, a PLC zone, a historian zone, an engineering workstation zone, and a safety system zone are typical. Conduits are where firewalls and gateways enforce traffic rules. 

This is the foundation of OT micro segmentation. If you don't have it, start here before pursuing more advanced Zero Trust controls. A well-implemented zone-and-conduit architecture addresses the most impactful OT security risks — lateral movement, safety system exposure, and IT/OT boundary crossing — with controls that are practical to implement today. 

Apply Least-Privilege at the Network Level 

Once zones are defined, least privilege at the network level means a device in one zone can only reach devices in another zone if there's an explicit, documented reason for that communication. Not 'the subnet is allowed to talk to that subnet' — 'this specific IP on port 502 Modbus TCP can talk to that specific IP in that direction only.' 

This level of granularity requires protocol-aware firewalls that understand OT traffic, not just port-based rules. A gateway between the SCADA zone and the PLC zone that permits Modbus read commands but blocks write commands from anything other than the engineering workstation — that's least-privilege at the network layer. 

Industrial wireless gateways with deep packet inspection for OT protocols are the enforcement hardware for this control. The PLC doesn't need to understand Zero Trust — it just sits behind a gateway that does. 

Handle Legacy Devices Through Gateway-Level Enforcement 

The most common objection to Zero Trust in OT is the legacy device problem: a PLC from 2003 can't run an authentication agent, can't participate in a certificate infrastructure, and can't be patched to support modern security protocols. This is real. 

The answer is network-level compensation. The legacy PLC doesn't need to authenticate — the gateway in front of it does. Any entity that wants to communicate with that PLC must authenticate to the gateway, which enforces access policy and logs the session. The PLC sees only the traffic that the gateway permits. 

This is exactly how Zero Trust handles legacy IT systems that can't be modernized — envelop them in policy enforcement infrastructure rather than trying to make the devices themselves secure. The approach translates directly to OT. 

How Do You Control Identity and Access in an OT Environment? 

Identity in OT is more complex than in IT because 'identity' applies to three distinct categories: human users (operators, engineers, and vendors), machines (PLCs, RTUs, SCADA servers, and historian databases), and applications (HMI software, engineering tools, and OPC-UA clients). Zero Trust requires explicit authentication and access control for all three. 

Human Identity: MFA and Role-Based Access 

Every human accessing OT systems — operators logging into HMIs, engineers connecting to PLCs, vendors doing remote support — should authenticate with MFA and access only the systems their role requires. This sounds straightforward; in practice, it runs into several OT-specific friction points. 

Control room operators work under time pressure. An MFA prompt that adds 15 seconds to every login is operationally unacceptable in environments where operators respond to alarms. The implementation answer is context-aware MFA: require step-up authentication for sensitive actions (PLC logic downloads and safety system access) but allow smoother authentication for routine operator tasks within an established session. 

Vendor access is the higher-risk scenario. Vendor sessions should go through a purpose-built OT remote access platform (Tosibox, Secomea, or Claroty xDome) that enforces MFA, records sessions, and provides just-in-time access scoped to specific systems for specific time windows. 

Machine Identity: Device Authentication at the Gateway 

Machine identity in OT means ensuring that a device claiming to be a specific PLC actually is that PLC, and not a spoofed device or a compromised endpoint. For modern OT devices that support certificates or 802.1X authentication, this is a standard configuration. For legacy devices that support neither, the enforcement falls to the gateway. 

Industrial managed switches with 802.1X port authentication can enforce that only known, pre-registered MAC addresses connect to specific ports. It's not certificate-based identity — but it means an unknown device plugged into the network doesn't silently join the OT subnet. An OT asset inventory is a prerequisite for machine identity enforcement. You can't enforce 'only known devices' if you don't have a complete, current list of what the known devices are. 

 Application-to-Application Communication 

OT environments have significant machine-to-machine communication that has no human in the loop: a SCADA server polling PLCs on a 500 ms cycle, a historian pulling process data every second, and an OPC-UA server aggregating data from multiple controllers. Zero Trust applied to this traffic means these communication paths should be explicitly authorized, documented, and enforced — not just assumed to be legitimate because they originate inside the OT network. 

Protocol-aware firewall rules at zone boundaries provide this control for most OT communication patterns. Where higher assurance is needed — such as applications with write access to controllers — certificate-based mutual authentication between the application and the controller is the stronger control, though it requires modern devices and more implementation effort. 

What Does Continuous Verification Look Like in OT? 

Continuous verification in IT means things like re-authentication when risk signals change, device health checks before each resource access, and real-time policy evaluation. In OT, applying these mechanisms directly to control traffic would be operationally catastrophic — a 500ms Modbus poll cycle can't tolerate a re-authentication handshake on every packet. 

The OT translation of continuous verification is behavioral anomaly detection on the network traffic itself. Rather than re-authenticating individual packets, you establish a baseline of normal communication patterns — which device talks to which device, at what frequency, using which protocol, in which direction — and alert when behavior deviates from that baseline. 

Building a behavioral baseline 

Passive OT network monitoring tools (Claroty, Nozomi Networks, Dragos Platform) automatically build communication baselines from observed traffic. After 2–4 weeks of passive observation, the tool has a model of normal behavior for every device on the network. 

Deviations from baseline — a PLC that suddenly starts communicating with a new IP address, a historian server that starts initiating connections to field devices, Modbus traffic appearing on a port it's never used before — are flagged for investigation. These anomalies are the OT equivalent of continuous verification: the network is constantly checking whether observed behavior matches authorized behavior. 

The Role of Physical Connectivity Hardware in Continuous Verification 

Passive monitoring requires network visibility — the ability to see all traffic without injecting packets into the control network. This is typically achieved through SPAN ports on managed industrial switches, which mirror traffic to a monitoring sensor. 

The cable plant matters here. A monitoring sensor connected via unreliable cabling to a SPAN port will miss traffic intermittently — creating gaps in the behavioral baseline that make anomaly detection less reliable. Industrial-rated connectivity, proper fiber runs for longer distances, and ruggedized patch infrastructure are not optional for a monitoring architecture that needs to be continuously reliable. 

Fiber optic connectivity solutions provide the interference-immune, high-bandwidth backbone that OT monitoring infrastructure depends on in electrically noisy industrial environments. 

 What Are the Hardware Requirements for Zero Trust Enforcement in OT? 

How Do You Build a Zero Trust Roadmap for an OT Environment? 

Zero Trust in OT is not a six-month project. It's a multi-year architectural evolution. The organizations that succeed treat it as a program with defined phases, not a project with an end date. Here's a practical sequencing that works in real manufacturing environments. 

Phase 1: Know What You Have (Months 1–3) 

You can't enforce least-privilege without knowing what devices exist and what communication they legitimately need. Phase 1 is entirely about visibility: 

•       Deploy passive OT network monitoring to build an asset inventory and communication baseline 

•       Document all remote access paths — VPNs, vendor connections, jump servers, direct RDP 

•       Map zone boundaries and conduits — even informally, before any formal segmentation is implemented 

This phase produces the foundation that every subsequent phase depends on. It also tends to surface surprises: undocumented devices, forgotten remote access paths, and communication patterns that no one knew existed.  

Phase 2: Enforce the IT/OT Boundary (Months 3–9) 

The IT/OT boundary is the highest-leverage enforcement point and the most impactful single Zero Trust control in most OT environments. Phase 2 implements it: 

•       Deploy an industrial firewall with a DMZ between IT and OT networks 

•       Migrate historian servers and data transfer systems into the DMZ — they don't belong on either side of the boundary 

•       Require MFA for all remote access; close any direct vendor connections that bypass a monitored jump server 

•       Implement session recording for all remote sessions into OT systems 

 Phase 3: Internal OT Micro Segmentation (Months 9–24) 

Once the external boundary is enforced, Phase 3 applies segmentation inside the OT network. This is where the communication baseline from Phase 1 pays off — you know who needs to talk to what, so you can write accurate zone rules without guessing. 

•       Segment OT zones by function: SCADA/DCS, field devices, engineering workstations, safety systems, historian 

•       Deploy industrial firewalls or managed switches with VLAN segmentation at zone boundaries 

•       Write protocol-aware least-privilege rules for each conduit 

•       Isolate safety instrumented systems — data diode rather than firewall where the highest isolation is warranted 

 Phase 4: Device Identity and Behavioral Monitoring (Months 18–36+) 

With segmentation in place, Phase 4 raises the assurance level through device identity enforcement and mature behavioral monitoring: 

•       Deploy 802.1X port authentication on managed switches — only registered devices can connect 

•       Implement certificate-based identity for modern OT devices where supported 

•       Tune behavioral anomaly detection based on accumulated baseline data — reduce false positive rates, sharpen detection of real anomalies 

•       Integrate OT monitoring alerts into the SOC alongside IT alerts — a correlated view of the environment 

 Zero Trust vs. Traditional Perimeter Security: The OT Comparison 

Supporting Secure and Connected OT Environments 

Zero Trust strategies depend on visibility, segmentation, and reliable connectivity across the industrial network. From industrial Ethernet and fiber infrastructure to industrial wireless networking and connectivity solutions, L-com helps organizations build resilient OT environments that support secure communications, operational reliability, and long-term network performance. 

Frequently Asked Questions (FAQs) 

What is Zero Trust for OT networks? 
Zero Trust is a security approach that requires every user, device, and communication request to be verified before access is granted. In OT environments, this helps reduce the risks associated with implicit trust and flat network architectures. 

Can Zero Trust work with legacy OT equipment? 
Yes. Many legacy PLCs, RTUs, and other industrial devices can participate in a Zero Trust architecture through network-level controls such as gateways, firewalls, segmentation, and access policies, even if the devices themselves lack modern security features. 

How is Zero Trust different from traditional OT security? 
Traditional OT security often relies on a strong perimeter and assumes trusted activity within the network. Zero Trust assumes that threats may already be present and applies verification and access controls throughout the environment. 

What is micro segmentation in an OT network? 
Micro segmentation divides the network into smaller zones and restricts communication between them based on specific operational requirements. This helps limit lateral movement and reduces the impact of a potential compromise. 

Where should manufacturers start with Zero Trust? 
Most organizations begin by creating an asset inventory, improving network visibility, documenting communication flows, and implementing segmentation between IT and OT environments before expanding to more advanced controls. 

How does Zero Trust relate to IEC 62443? 
The two approaches are highly complementary. IEC 62443's zone-and-conduit model provides a strong foundation for many Zero Trust principles, including segmentation, controlled communications, and least-privilege access.