Why Zero Trust for OT Is Different
Zero Trust architecture was conceived as a response to the failures of perimeter-based security in IT environments — the assumption that anything inside the network boundary is trustworthy. Its core mandate, "never trust, always verify," is implemented through strong identity, continuous validation, and least-privilege access control. Cloud-native environments, modern SaaS platforms, and enterprise workforces are reasonably suited to this model. Operational technology environments are not.
The fundamental assumptions that underpin Zero Trust in IT break systematically when applied to OT. Industrial devices — programmable logic controllers (PLCs), remote terminal units (RTUs), distributed control system (DCS) components — were designed in an era when isolation was the security model. These devices have no native identity stores, run proprietary firmware on update cycles measured in years, and communicate via protocols (Modbus, DNP3, PROFIBUS, EtherNet/IP) that include no authentication layer whatsoever. Many cannot be patched at all without voiding vendor support agreements or triggering regulatory re-certification.
More critically, the operational risk calculus is inverted. In IT, a security control that causes a brief service disruption is acceptable. In OT, unauthorized process interruption can mean physical damage to equipment, environmental releases, or loss of human life. A safety instrumented system (SIS) that fails to execute an emergency shutdown because a security policy blocked a network communication is not a security win — it is a catastrophic failure. This fundamental tension between Zero Trust's "never interrupt, always verify" requirement and OT's "never interrupt, always available" mandate defines the entire challenge of applying Zero Trust to industrial environments.
The applicable standards recognize this. ISA-62443-3-3 (System Security Requirements and Security Levels) defines security controls specifically for IACS environments, explicitly accounting for the reliability and availability requirements that conflict with pure IT security approaches. NIST SP 800-82 Rev 3 (Guide to OT Security) similarly acknowledges that OT environments require compensating controls and adapted implementations rather than direct application of IT security frameworks.
The practitioner's challenge, then, is not whether to apply Zero Trust to OT — regulators and threat actors have resolved that debate — but how to apply its principles in a way that achieves genuine security improvement without introducing operational risk.
The Purdue Model and Zero Trust Segmentation
The Purdue Model (formally the Purdue Enterprise Reference Architecture, or PERA) provides the foundational framework for understanding OT network structure. Developed in the 1990s, it organizes industrial systems into five hierarchical levels, each with distinct functions, device types, and communication requirements. Despite its age, the model remains the reference architecture used by most critical infrastructure operators and the basis for zone-based segmentation requirements in IEC 62443 and NERC-CIP.
╔══════════════════════════════════════════════════════════════╗
║ LEVEL 4/5 — ENTERPRISE / SITE BUSINESS PLANNING ║
║ ERP, MES Integration, Corporate IT Network ║
║ Zero Trust: Full IT ZT controls apply; strict DMZ ║
╠══════════════════════════════════════════════════════════════╣
║ ↑↓ OT DMZ / IDMZ ║
║ Data diodes | Jump servers | RBAC-gated relay ║
╠══════════════════════════════════════════════════════════════╣
║ LEVEL 3 — SITE MANUFACTURING OPERATIONS ║
║ Historians, SCADA servers, Engineering Workstations ║
║ Zero Trust: PAM for EWS; microsegmentation; MFA ║
╠══════════════════════════════════════════════════════════════╣
║ LEVEL 2 — SUPERVISORY CONTROL ║
║ HMIs, DCS Operator Stations, SCADA Front-End ║
║ Zero Trust: RBAC for HMI access; session recording ║
╠══════════════════════════════════════════════════════════════╣
║ LEVEL 1 — BASIC CONTROL ║
║ PLCs, RTUs, Safety Systems (SIS) ║
║ Zero Trust: Network segmentation; read-only monitoring ║
╠══════════════════════════════════════════════════════════════╣
║ LEVEL 0 — FIELD DEVICES ║
║ Sensors, Actuators, Field Instruments ║
║ Zero Trust: Physical controls; passive monitoring only ║
╚══════════════════════════════════════════════════════════════╝
Zero Trust controls map differently across Purdue levels because the security and reliability tradeoffs shift at each tier. At Levels 0 and 1 — field devices and basic control — direct security enforcement is rarely feasible. PLCs and RTUs cannot authenticate network traffic. The Zero Trust implementation here is passive: comprehensive asset visibility through network traffic analysis tools that operate without injecting packets into control network segments, physical security for panel access, and network segmentation that prevents lateral movement from Level 1 into Level 2.
At the Level 2/3 boundary — between supervisory control and manufacturing operations — microsegmentation becomes both feasible and essential. This is where engineering workstations live, where SCADA servers process telemetry, and where historians collect operational data for enterprise consumption. Controls at this boundary include privileged access management (PAM) for engineering workstation access, firewall policies that enforce communication directionality between zones, and vendor remote access management platforms that replace ad-hoc VPN credentials with session-brokered, time-limited, audited access.
The OT DMZ (sometimes called the Industrial DMZ or IDMZ) sits between Level 3 and Level 4/5. This is the most critical Zero Trust control point in most OT architectures. Data replication from OT historians to enterprise systems should flow through this zone via relay servers or data diodes — unidirectional security gateways that physically prevent return traffic from enterprise networks into the OT environment. For legacy PLCs and RTUs that cannot be upgraded to support authentication, unidirectional gateways at Level 1/2 boundaries serve as compensating controls that satisfy IEC 62443 zone separation requirements without requiring firmware modification.
The Five Zero Trust Pillars Applied to OT
CISA's Zero Trust Maturity Model defines five pillars: Identity, Devices, Networks, Applications/Workloads, and Data. Each has direct application in OT environments, though the implementation differs substantially from IT practice.
Identity
In IT, identity means user accounts in a directory service. In OT, human identity is only part of the picture — machine identity for devices is equally critical. For engineering workstations and SCADA operator stations that can support it, implement MFA through PAM platforms. For PLCs and RTUs that communicate without authentication, implement certificate-based machine identity at the network layer using OT-aware PKI solutions. Vendor remote access is the highest-risk identity surface: every vendor support technician accessing a DCS or SCADA system over an unmanaged VPN is an uncontrolled identity. Replace ad-hoc credentials with purpose-built vendor access management platforms that enforce least-privilege, time-bounded, fully audited sessions.
Devices
Asset inventory is the foundational Zero Trust device control — and in OT, it is genuinely difficult. Active scanning is generally prohibited in OT networks because control systems can fail or behave unpredictably in response to unexpected network traffic. Asset discovery must be passive: deploy network traffic analysis platforms that build an asset inventory by observing traffic rather than probing devices. Firmware integrity verification is increasingly supported by OT security platforms and provides a compensating control for devices that cannot run endpoint agents. The bar for device trustworthiness in OT is not endpoint detection and response (EDR) — it is network-based behavioral baselining that detects deviations from established communication patterns.
Networks
Network segmentation is the highest-impact Zero Trust control available in most OT environments. Zone-based segmentation aligned to the Purdue Model, enforced by next-generation firewalls with OT protocol awareness, provides defense-in-depth even when device-level controls are not feasible. The OT DMZ architecture described above is the primary network-level control for IT/OT convergence points. East-west traffic visibility within OT zones — not just north-south traffic to/from enterprise networks — requires OT-specific network traffic analysis tools capable of parsing Modbus, DNP3, IEC 61850, and other industrial protocols.
Applications / Workloads
Application-layer controls in OT center on two surfaces: SCADA HMI access and vendor remote access. SCADA HMIs should implement role-based access control (RBAC) that maps operator roles to specific process areas — a water treatment operator should not have access to the electrical substation HMI on the same network. Vendor remote access is best managed through privileged access workstations (PAWs) or dedicated vendor access management platforms that broker sessions without exposing network credentials, record sessions for audit purposes, and enforce time-limited access windows aligned to approved maintenance windows.
Data
OT data has two distinct security profiles. Operational telemetry flowing from PLCs to historians is generally not sensitive in isolation, but in aggregate reveals process parameters that could inform attacks. More sensitive is the configuration data stored in engineering workstations — ladder logic, PLC programs, process setpoints — which represents the intellectual property of the process and the attack surface for malicious manipulation. Data classification for OT should identify configuration files and tag them for additional access controls. Data diode architectures are the gold standard for protecting historian data as it moves from OT networks to enterprise analytics environments: hardware-enforced unidirectionality ensures that even a fully compromised enterprise environment cannot inject traffic back into the OT network.
Implementation Sequencing
Organizations starting a Zero Trust OT program from near-zero should follow a phased approach that prioritizes risk reduction while respecting operational constraints. Attempting to implement all controls simultaneously is operationally dangerous and organizationally unsustainable.
Phase 1 (0–90 Days): Asset Discovery
You cannot protect what you cannot see. Deploy passive OT network monitoring sensors at key network segments to build a comprehensive asset inventory: device types, firmware versions, communication patterns, open ports, and external connectivity. This baseline is a prerequisite for every subsequent control. Expect to discover devices that IT had no knowledge of — shadow OT assets connected without authorization are common in complex plant environments. The output of Phase 1 is a prioritized risk register: assets that are internet-facing, unpatched, running end-of-life firmware, or communicating with unexpected destinations.
Phase 2 (90–180 Days): Network Segmentation
Using the asset inventory from Phase 1, implement or validate Purdue-aligned network segmentation. Establish an OT DMZ with relay servers for historian data replication. Deploy OT-aware firewalls at Level 2/3 and Level 3/4 boundaries. Implement unidirectional gateways for the highest-sensitivity process areas. Audit and restrict all remote access paths — VPN credentials, jump server access, and vendor support channels. The goal at the end of Phase 2 is that no path exists from the enterprise network to the OT control network without passing through an actively monitored, policy-enforced control point.
Phase 3 (180–365 Days): Identity and Access Controls
With the network perimeter hardened, turn to identity controls. Deploy PAM for all privileged access to Level 3 assets: engineering workstations, historian servers, SCADA application servers. Implement vendor access management to replace ad-hoc credentials. Enforce MFA for all human access to Level 3 and above. Implement RBAC on SCADA HMIs based on the asset inventory and role analysis conducted in earlier phases. Where PKI infrastructure exists, begin issuing machine certificates to devices that support them.
Phase 4 (Year 2): Continuous Monitoring and SOC Integration
The most mature Zero Trust OT implementations integrate OT telemetry into the enterprise security operations center (SOC). OT network monitoring platforms should forward alerts and telemetry to the SIEM/XDR platform. OT-specific detection rules — deviations from communication baselines, unauthorized PLC program changes, unexpected vendor access sessions — should be developed in partnership between OT operations staff and the SOC team. This integration closes the loop from visibility to detection to response, completing the Zero Trust architecture.
Key Standards and References
- ISA/IEC 62443 Series — The primary international standard for industrial automation and control system (IACS) security. Organized into four series covering general concepts, policies and procedures, system-level requirements, and component-level requirements. Security Levels 1–4 define the rigor of controls required based on threat profile.
- NIST SP 800-82 Rev 3 — NIST's guide to OT security, covering ICS, SCADA, DCS, and other OT environments. Rev 3 (2023) substantially expanded coverage of cloud-connected OT, remote access, and supply chain risk. Mandatory reference for federal agencies and their contractors.
- NERC-CIP Standards — Mandatory cybersecurity standards for bulk electric system (BES) owners, operators, and users in North America. CIP-002 through CIP-014 define specific technical and procedural requirements. Violations carry penalties up to $1 million per day per violation.
- CISA Zero Trust Maturity Model — CISA's framework for federal agency Zero Trust adoption, organized across five pillars (Identity, Devices, Networks, Applications, Data) with three maturity levels. Increasingly used as a reference architecture by critical infrastructure operators outside the federal sector.
- TSA Pipeline Security Directives — Mandatory cybersecurity requirements for pipeline operators, issued following the 2021 Colonial Pipeline attack. SD-02D (2022) mandates network segmentation, access management, and continuous monitoring controls that directly align with Zero Trust architecture.
- EU NIS2 Directive — The European Union's updated network and information security directive, in force since October 2024. Covers 18 critical sectors and over 160,000 entities, including non-EU companies providing services to EU critical infrastructure. OT security controls are explicitly required.