Overview
On April 29, 2026, CISA released “Adapting Zero Trust Principles to Operational Technology” — a 28-page joint guidance document developed in collaboration with the NSA and international cybersecurity agencies including the UK’s NCSC, Canada’s CCCS, and Australia’s ASD. The document represents the most operationally specific guidance to date on implementing zero trust in industrial environments, and it addresses the central problem that has made previous zero trust frameworks nearly useless for OT teams: the IT-focused assumptions that underpin most zero trust architectures do not translate directly to environments with 20-year-old PLCs, safety-critical uptime requirements, and protocols designed for reliability rather than security.
The guidance is not theoretical. It is structured around the real constraints that OT operators face and provides a tiered implementation approach designed to allow progress without forcing unsafe changes to production systems.
Why Standard Zero Trust Frameworks Fail in OT
The core zero trust principle — “never trust, always verify” — works in IT because every endpoint has an identity, can run modern authentication software, and can tolerate the latency of verification exchanges. OT environments regularly violate all three assumptions:
Legacy devices cannot run agents. A Modbus RTU master from 2003, a legacy PLC running proprietary firmware, or a distributed control system installed under a 15-year maintenance contract cannot install an endpoint agent, participate in a certificate-based identity exchange, or authenticate to an identity provider. Any zero trust framework that requires software-based identity verification on every endpoint immediately excludes a significant portion of OT infrastructure.
Uptime requirements preclude normal change management. An electric transmission substation or a continuous chemical process cannot accept a rolling restart cycle to apply configuration changes. Changes to network policy, authentication requirements, or monitoring infrastructure must be staged, tested offline, and implemented during planned maintenance windows — often months apart. Zero trust architectures designed for cloud-native IT environments assume rapid policy iteration that OT simply cannot accommodate.
OT protocols are inherently implicit-trust designs. Modbus, DNP3, and legacy PROFIBUS have no authentication layer. Any device on the network segment can issue commands. Applying zero trust at the protocol level requires either replacing the protocol (often not feasible) or inserting compensating controls — firewalls, diodes, protocol-aware proxies — that can enforce policy without modifying device firmware.
Safety and availability trump security controls. In an OT environment, blocking a command because an authentication check failed can be more dangerous than allowing it. The guidance explicitly acknowledges that availability must take precedence in certain contexts, and security controls must be designed with failure modes that fail open — allowing operations to continue — rather than fail closed, as many IT security tools do.
The CISA Framework: Five Zero Trust Pillars Adapted for OT
The guidance structures its recommendations around five pillars, adapted from NIST SP 800-207 (Zero Trust Architecture) and aligned with both NIST CSF 2.0 and ISA/IEC 62443:
1. Identity
For OT, identity extends beyond users to include devices, services, and processes — but must account for devices that cannot participate in standard identity management.
For devices with identity capability (modern PLCs, historian servers, HMIs running Windows): enrol in a centralised identity management system, issue device certificates with limited validity periods, and enforce certificate-based authentication for all remote access.
For legacy devices without identity capability: assign identity at the network level rather than the device level. A legacy PLC is identified by its MAC address, IP, and the port and protocol combination it communicates on. Policy enforcement happens at the network boundary — the gateway or industrial DMZ — rather than on the device itself.
User identity for OT access should follow the principle of least privilege with just-in-time provisioning. Engineers requiring remote access to OT systems should activate access for a defined maintenance window, with all activity logged and time-bounded credentials that automatically expire.
2. Devices
OT device security cannot rely on continuous patching cycles, but operators can establish a baseline asset inventory and track deviations. The guidance recommends:
- Passive network monitoring for asset discovery — active scanning is contraindicated in most OT environments because it can disrupt sensitive devices or trigger unintended process responses
- Configuration baseline management for devices that can be baselined — capturing the expected communication patterns, firmware versions, and configuration states, and alerting on deviations
- Hardware root of trust for new device procurement — any new OT equipment purchased from 2026 onwards should meet hardware security baseline requirements
The connection to the EU Cyber Resilience Act is direct: new OT devices placed on the EU market must meet CRA security requirements from December 2027. Operators integrating new equipment should include CRA compliance evidence in their procurement criteria now.
3. Networks
Network segmentation is the pillar where OT operators can make the most immediate progress regardless of device constraints. The guidance recommends a zone-and-conduit model consistent with ISA/IEC 62443-3-2, structured around:
Zones by function and criticality:
- Enterprise/IT zone (corporate network)
- Industrial DMZ (the interface layer between IT and OT)
- Supervisory zone (SCADA, historian, HMI)
- Control zone (PLCs, RTUs, field devices)
- Safety zone (safety instrumented systems — isolated and never internet-connected)
Conduits as controlled paths between zones. No direct communication between the enterprise zone and the control zone. All data flow between corporate IT and OT must traverse the industrial DMZ, where a protocol-aware firewall or data diode enforces one-way or strictly controlled bidirectional flows.
Micro-segmentation within the control zone. Where feasible, separate PLCs and controllers by process function — isolate the water treatment process from the SCADA historian from the remote access jump server. A compromised HMI should not have a flat network path to every PLC in the facility.
For environments already using the Purdue Model, the guidance provides a mapping of zero trust controls to each Purdue level — operators familiar with the existing framework can use this as a translation layer rather than a wholesale replacement.
4. Applications and Workloads
OT applications — SCADA software, historian platforms, HMI interfaces — require the same access controls as IT applications but with OT-specific constraints:
- Application allowlisting on engineering workstations and HMIs: only approved executables can run. This is particularly effective because OT workstations have defined, narrow software requirements that rarely change.
- Remote access controls: third-party vendor access to OT systems is a persistent high-risk vector. All vendor access should go through a vendor-specific remote access solution with session recording, time limits, and multi-factor authentication. No persistent VPN tunnels for vendor access.
- Software supply chain controls: the Trivy supply chain compromise (CVE-2026-33634) and similar incidents demonstrate that OT software update pipelines are an increasingly targeted attack surface. Verify integrity of software updates before installation in OT environments — hash verification at minimum, vendor-signed packages where available.
5. Data
Data protection in OT focuses on protecting configuration files, process data, and historian records from unauthorised access and tampering:
- Historian and process data databases should be access-controlled with role-based permissions — not all OT staff need read/write access to all process data
- Configuration files for PLCs and controllers should be version-controlled and access-restricted — unauthorised configuration changes are a primary persistence technique for OT-targeting malware
- Data flows leaving the OT environment (to cloud historians, vendor monitoring portals, corporate business intelligence systems) should be encrypted in transit and logged
Implementation Priorities: Where to Start
The guidance acknowledges that implementing all five pillars simultaneously is not feasible for most OT operators. It recommends a risk-based prioritisation:
| Priority | Action | Rationale |
|---|---|---|
| 1 | Network segmentation and industrial DMZ | Highest impact, no device changes required |
| 2 | Remove all direct IT-to-OT connectivity | Eliminate the most common lateral movement path |
| 3 | Implement vendor access controls | Third-party remote access is the leading initial access vector |
| 4 | Deploy passive OT network monitoring | Asset visibility before you can enforce policy |
| 5 | Application allowlisting on HMIs and workstations | High protection per effort in stable OT environments |
| 6 | OT-capable identity management for modern devices | Long-term: requires procurement cycle planning |
This sequence allows operators to achieve meaningful risk reduction in 6–12 months while deferring the harder device identity and segmentation work that requires maintenance windows and capital planning.
Alignment with Existing Standards
The guidance explicitly maps to existing OT security frameworks:
ISA/IEC 62443: The zone-and-conduit model is IEC 62443-3-2 native. The guidance treats IEC 62443 compliance as a compatible foundation and provides a zero trust overlay rather than a replacement.
NIST CSF 2.0: The five pillars map to the CSF’s Identify, Protect, Detect, Respond, and Recover functions. Operators already working to CSF 2.0 can align zero trust controls to their existing CSF implementation.
NERC CIP (energy sector): The guidance notes that NERC CIP compliance requirements are compatible with zero trust and that implementing zero trust controls will satisfy many CIP requirements — operators can use this guidance to pursue both simultaneously.
Practical Constraints: What the Guidance Acknowledges
The document is notable for explicitly acknowledging the limits of what’s achievable. Several statements worth quoting directly:
On legacy devices: “Operators should not attempt to force zero trust identity controls onto legacy OT devices that cannot support them. Compensating controls at the network boundary are the appropriate mechanism.”
On availability: “Security controls in OT environments must be designed with the assumption that a control failure will be handled in a way that maintains process safety and availability. Fail-open configurations are appropriate for process-critical controls; fail-closed is appropriate only for communications that can be safely interrupted.”
On timelines: “Zero trust implementation in OT environments should be planned over 3–5 year horizons aligned to capital planning cycles and maintenance window availability, not 12–18 month IT deployment timelines.”
These acknowledgements matter because they validate what OT security practitioners have been saying for years: applying IT security frameworks directly to OT without accounting for operational constraints creates security theatre at best, and operational risk at worst.
Action Items for OT Security Teams
- Download and read the full guidance: The 28-page document is available at CISA.gov and includes a detailed appendix with implementation worksheets for each pillar.
- Map your current segmentation against the zone model: Identify where you have direct IT-to-OT connections that bypass an industrial DMZ — these are your highest-priority remediation items.
- Audit third-party remote access: Document every vendor with remote access to your OT environment. Verify that each connection uses a controlled, logged, time-limited mechanism — not a persistent VPN.
- Deploy passive network monitoring if not already in place: You cannot enforce zero trust policy on assets you cannot see. Passive monitoring tools (Claroty, Dragos, Nozomi) build the asset visibility foundation that everything else depends on.
- Incorporate the guidance into your next capital planning cycle: The device identity and micro-segmentation work requires hardware and maintenance windows. Get it into the 2027–2028 budget cycle now.