OT Zero Trust Blueprint: Adapting Federal Standards to Legacy Hardware
Zero trust for OT is not a product you buy. It is an architectural posture you build incrementally, constrained at every step by hardware that predates the concept by decades. Federal mandates from CISA and the Department of Defense have formalized zero trust requirements for industrial networks, but the guidance assumes identity-capable assets, modern authentication, and network flexibility that most OT environments do not have. This guide translates those requirements into controls that work on the hardware you actually have — including the PLCs, RTUs, and HMIs that will never support an agent, a certificate, or a modern identity stack.
What zero trust means in OT context
Zero trust is not a product category. The core principle is: never trust, always verify. No user, device, or network segment is trusted by default — access is granted based on verified identity, device posture, and least-privilege policy, and that verification happens continuously, not just at initial connection.
In IT environments, zero trust is implemented through identity providers, endpoint detection agents, micro-perimeters, and continuous authentication. In OT environments, most of those mechanisms are unavailable or unsafe to deploy.
The practical translation for OT: since you cannot verify identity at the device level on most OT assets, enforce zero trust principles at the network boundary instead. Microsegmentation, network-layer access controls, and compensating controls create virtual zero trust boundaries around assets that cannot enforce them natively.
CISA's guidance "Applying Zero Trust Principles to Enterprise Mobility" and the NSA/CISA joint advisory on OT security both acknowledge this constraint explicitly. Zero trust in OT is a matter of applying the principles at whatever layer the environment supports — not achieving the full identity-based model that cloud-native IT environments can reach.
The CISA framework translated
CISA organizes zero trust around five pillars: Identity, Devices, Networks, Applications and Workloads, and Data. Here is what each pillar means in OT practice, organized by NIST CSF 2.0 functions.
- Apply identity verification at the access layer, not the device layer. Engineers authenticate to a jump host or PAM system before reaching OT assets — the jump host enforces identity, the OT asset does not need to.
- For assets that do support authentication (modern HMIs, SCADA servers, engineering workstations), enforce MFA.
- Eliminate shared accounts. Each engineer who accesses OT assets has individual credentials, even if the asset itself uses a shared service account.
- Enforce network access control at the IT/OT boundary. Unmanaged devices connect to a quarantine VLAN and reach OT assets only through the jump host.
- Maintain an asset inventory with classification. A device not in the inventory should not be able to communicate on OT segments.
- Accept that legacy OT assets will fail any posture check. Compensating controls — microsegmentation, protocol filtering — substitute for posture verification on those assets.
- Start with the IT/OT boundary. A single well-enforced firewall between IT and OT is more valuable than attempting full microsegmentation of a flat OT network.
- Use the Purdue model as the segmentation framework. Level 3 should not communicate directly with Level 1. Each level boundary is a microsegmentation target.
- For environments that cannot tolerate a network redesign, software-defined microsegmentation platforms (Elisity and similar) enforce policy at the software layer without physical changes.
- Data diodes at high-consequence asset boundaries enforce unidirectional communication as the strongest possible network-layer zero trust control.
- Implement application-layer controls where the platform supports them. SCADA and DCS systems with role-based access should enforce least-privilege — operators cannot access engineering functions, engineers cannot access historian configurations they do not own.
- For vendor remote access, enforce application-layer controls at the jump host. The vendor reaches only the specific asset and protocol required for their work.
- Log all application-layer access. What you cannot prevent, you can detect and audit.
- Classify OT data by sensitivity: process telemetry (low), asset configuration files (medium), compliance evidence and network diagrams (high).
- Apply access controls to configuration file repositories. Engineering workstations that do not require access to PLC configuration files should not have it.
- Historian data leaving the OT network via a data diode is already protected by the diode's unidirectionality. Apply access controls on the IT-side historian to prevent unauthorized access to the extracted data.
Compensating controls for legacy assets
Legacy assets that cannot support zero trust natively require compensating controls that enforce the principles at the network layer. The control stack below applies to the majority of OT environments.
Segment assets by function and criticality. A safety instrumented system should not be on the same network segment as a historian. A PLC that controls a physical process should not be reachable from the corporate network.
| Constraint | Segmentation approach |
|---|---|
| Can tolerate network changes | Physical VLAN segmentation with firewall enforcement at each boundary |
| Cannot tolerate physical changes | Software-defined microsegmentation (Elisity, Cisco ISE) enforcing policy over existing infrastructure |
| Highest-consequence assets | Data diode — hardware-enforced unidirectional boundary, no policy to misconfigure |
For environments that cannot deploy traditional firewalls at every segment boundary, identity-based edge fabrics enforce communication policy at the switch level. Devices are authenticated at network entry and assigned to policy groups — a PLC in the control group can only communicate with assets in the same group and with explicitly permitted assets in adjacent groups.
Industrial firewalls with OT protocol awareness enforce least-privilege communication at the protocol level. A firewall rule that permits Modbus TCP from a specific historian IP to a specific PLC IP on port 502 — and blocks all other Modbus traffic — is a zero trust control that does not require the PLC to support modern identity.
A PAM system deployed at the IT/OT boundary enforces zero trust principles for human access to OT assets, regardless of the asset's native authentication capability. All engineer and vendor access is authenticated, authorized, time-limited, and recorded at the PAM layer — the OT asset itself does not need to support any of those controls natively.
Identity for machine actors at Levels 1 and 2
The hardest zero trust problem in OT is machine-to-machine communication at the lower Purdue levels. Level 1 (basic control) and Level 2 (supervisory control) contain the assets least capable of supporting modern identity — and the assets where a compromised communication path has the most direct physical consequence.
A PLC communicating with a historian, a SCADA server polling an RTU, an HMI sending setpoints to a controller — none of these communications carry verifiable identity. If an attacker inserts a device that mimics the PLC's IP address and sends malicious setpoints, most OT networks have no mechanism to detect the impersonation.
Define the complete set of legitimate communication pairs for your environment. Every communication pair that is not on the allowlist is blocked at the network layer. This is not identity verification — it is communication pattern verification — but it achieves a similar security outcome for assets that cannot support identity.
OT monitoring platforms (Dragos, Claroty, Nozomi) baseline normal communication patterns and alert on deviations. A new device sending Modbus commands to a PLC that has never received commands from that source is flagged. This is detective, not preventive, but it closes the gap that communication allowlisting leaves open.
Modern PLCs and IEDs from vendors including Siemens, Rockwell, and Schneider increasingly support certificate-based authentication for engineering access. Where supported, deploy it. The installed base of legacy assets that will never support it is large — but future procurement should require it.
For Level 1 assets that support no network-layer identity verification, physical access controls are the zero trust backstop. A PLC in a locked cabinet with tamper detection, on a network segment accessible only through a PAM-enforced jump host, is a more defensible posture than the same PLC on a flat network with no access controls — even if the PLC itself cannot verify the identity of anything communicating with it.
Implementation sequence
Zero trust in OT is a multi-year program. This sequence prioritizes the controls with the highest risk reduction per unit of operational disruption.
- Deploy or harden the IT/OT boundary firewall. Enforce default-deny with explicit permit rules.
- Implement a jump host or PAM system for all engineer and vendor access to OT assets.
- Eliminate shared accounts for human access to OT systems.
- Complete asset inventory and classification. You cannot segment what you have not mapped.
- Segment OT networks by Purdue level. Start at the Level 3/2 boundary.
- Deploy OT monitoring in passive mode. Build the communication baseline.
- Build communication allowlists from the baseline data. Begin blocking unauthorized communication pairs.
- Extend microsegmentation to Level 2/1 boundaries for highest-consequence assets.
- Deploy data diodes at SIS and protection relay boundaries where bidirectional access is not operationally required.
- Implement certificate-based authentication for newly procured OT assets.
- Review and formalize procurement standards — new OT assets must support specified identity and authentication capabilities.