Zero Trust for OT and ICS Guide: Applying Zero Trust Without Breaking Safety

Zero trust was designed for offices and data centres, and copying IT zero trust controls straight into a plant can stop a process, trip a safety system or lock an operator out of the HMI they need in an emergency. Operational technology still needs the core idea: no implicit trust for a laptop because it sits on the control network, no standing vendor access, and every flow between zones justified and watched. This guide shows how to apply zero trust to industrial control systems in a way that respects availability and safety, using the US Department of War (formerly DoD) Zero Trust for OT activities, the joint government secure connectivity principles and IEC 62443 as the frame. It is for OT security engineers, control system owners and the IT security teams who work with them. For the DoD framework itself, see the DoD Zero Trust Strategy and Reference Architecture Guide.

Key takeaways

• Safety outranks enforcement. Every zero trust control in OT must fail in a way that keeps the process safe, which usually means alerting or queuing for a human rather than blocking automatically.
• Split the estate into two layers. The Department of War OT activities treat the operational layer (servers, HMIs, historians, workstations) differently from the process control layer (Purdue levels 0 to 2, field devices and safety instrumented systems), and so should you.
• Most of the gain is at the boundaries. Identity-aware remote access, a brokered IT/OT DMZ and deny-by-default conduits deliver more risk reduction than trying to authenticate every PLC.
• Legacy devices get compensating controls, not exemptions. Where a controller cannot do certificates or modern authentication, document the gap and wrap it with segmentation, allowlisting and monitoring.
• Plan for isolation before you need it. Design IT, operational IT and process control networks so they can be separated during an incident, and practise manual operation.

Why zero trust looks different in OT

The Department of War (DoW) CIO Zero Trust Portfolio Management Office published "Zero Trust for Operational Technology: ZT for OT Activities and Outcomes" so that system owners have OT-specific requirements alongside the enterprise catalogue. The document states plainly that OT puts availability and safety ahead of confidentiality, that standard IT approaches can be ineffective and potentially dangerous in control systems, and that air gaps are not inherently safe because insiders, temporary connections, removable media and installed software remain attack paths.

The DoW document also notes that if an adversary gains physical access, cyber controls may be insufficient, so physical security remains part of the design rather than a separate programme. In October 2026 NSA added a Cybersecurity Information Sheet, "Hardening Department of War (DoW) Critical Operational Technology (OT) Environments with Zero Trust (ZT) Principles", which frames the same approach around limiting unauthorised access, lateral movement and persistence in critical OT and strengthening legacy systems.

The DoW Zero Trust for OT activities in practice

The OT guidance keeps the seven enterprise pillars but rewrites the activities for control systems. It defines 105 activities: 84 at Target level and 21 at Advanced level. Target is the minimum set needed to prevent lateral movement and address known threats; Advanced activities are adaptive capabilities that the document says will not be held to the Target timeline. The guidance is additive to existing cybersecurity requirements and does not replace the Purdue model, IEC 62443 or UFC 4-010-06. It covers DoW-owned OT up to the point of demarcation and stops at the boundary of weapon systems and defence critical infrastructure, which will get separate guidance.

Three details are worth copying even if you never work with defence. First, an activity may be judged not applicable to a system (a standalone system that cannot ingest threat feeds, for example), but the assessor must document the justification. Second, where a device cannot support periodic authentication, alternative technical or procedural controls must be deployed and documented (1.8.2.OT). Third, devices that cannot support X.509 certificates are marked for retirement or excepted through a documented risk process, and any break-glass path that falls back to insecure protocols needs mitigating controls against misuse (2.1.2.OT).

Architecture: two layers, zones and conduits

The DoW document simplifies the Purdue model into an operational layer, which includes supervisory tooling, operator workstations, process control servers, historians, HMIs and firewalls, and a process control layer covering Purdue levels 0 to 2: field devices, sensors, actuators, motors and safety instrumented systems (SIS). IEC 62443 gives the engineering vocabulary to put zero trust on top of that: group assets with the same security requirements into zones, and route every communication between zones through a defined conduit with its own controls. See the IEC 62443 Guide.

• Enterprise to OT boundary: no direct routes from the corporate network to level 3 or below. Data leaves through a DMZ (often called level 3.5) where historian replicas, patch staging and file transfer brokers sit. The CISA primary mitigations for OT name segmenting IT and OT with a DMZ as one of five core actions.
• Policy enforcement points in OT: industrial firewalls with protocol awareness, remote access brokers, jump hosts and unidirectional gateways. These are where identity, device and context checks happen, because most level 0 to 2 devices cannot make the decision themselves. See the Industrial Protocol Security Guide.
• Cell or area zones: split production lines, units or substations so that a compromise in one cannot reach the next. This is the OT form of microsegmentation, and it is where 5.4.1.OT expects proposed rule changes to be queued for human approval.
• Safety systems: keep the SIS in its own zone with the tightest conduit, ideally read-only data out. A zero trust project should never add a dependency that the SIS needs to function.
• Management plane: engineering workstations, configuration tools and backup servers are the crown jewels for an attacker because they can rewrite logic. Separate the management plane from control traffic, as 5.3.1.OT requires.

The joint secure connectivity principles led by the UK NCSC and co-sealed by CISA, FBI, ASD's ACSC, the Canadian Cyber Centre, BSI, NCSC-NL and NCSC-NZ give a useful checklist for each conduit: balance risk and opportunity, limit exposure, centralise and standardise connections, use standardised and secure protocols, harden the OT boundary, limit the impact of compromise, log and monitor all connectivity, and establish an isolation plan.

Identity and access for people, vendors and machines

Identity is where zero trust gives OT the fastest return, because most OT intrusions use valid accounts or remote services rather than exotic controller exploits. MITRE ATT&CK for ICS lists External Remote Services (T0822), Remote Services (T0886) and Valid Accounts (T0859) as techniques adversaries use to enter and move within control environments.

• Named accounts: inventory every operator, engineer, contractor and vendor account (1.1.1.OT). Replace shared HMI logins with named accounts where the HMI supports it; where it does not, put a named, logged session in front of it.
• Remote access: no direct inbound access to OT. Vendors connect through a broker in the DMZ with phishing-resistant MFA, per-session approval, time limits and session recording. CISA's primary mitigations call for remote access only with phishing-resistant MFA, least privilege per role and disabled dormant accounts. See the OT Remote Access Guide.
• Privileged access: engineering changes to PLC logic or safety settings require just-in-time elevation and, for high-impact changes, a second person. The DoW activities ask for dynamic access control on high-privilege accounts (1.2.2.OT).
• Separate OT identity: keep OT domain controllers or local identity stores inside the OT zone and do not trust the corporate forest. See the Identity for OT Environments Guide.
• Machine identities: historians, OPC servers, data brokers and SCADA service accounts are non-human identities with standing access to controllers. Give each its own account, restrict it to the conduits it needs, rotate its credentials on a maintenance schedule and alert on interactive logons.
• Break-glass: keep local emergency accounts for when the identity service or WAN is down, sealed, monitored and tested, so that operators are never locked out of a running process.

Devices, protocols and legacy equipment

Device trust in OT starts with knowing what is there. CISA and partners including NSA, FBI, EPA and the Five Eyes and European cyber agencies published joint guidance on building an OT asset inventory and supporting taxonomy, because without it no allowlist or segmentation rule can be trusted. See the OT Asset Visibility Guide.

Implementing zero trust in an OT estate

1. Agree the safety rules first. With process safety and operations, write down what a security control may never do: block a safety trip, interrupt a running HMI session, or change a controller without approval. Every later step is tested against this list.
2. Inventory users, devices and flows. Use passive discovery and engineering records to build the asset inventory, then capture actual communication flows between zones for several weeks, including the monthly and seasonal jobs that a short capture misses.
3. Close internet exposure and default credentials. Remove direct internet connections to OT and change default passwords, the first two CISA primary mitigations. Check for exposed devices from outside (ATT&CK for ICS T0883 Internet Accessible Device).
4. Broker all remote access. Move vendors and remote engineers onto a single brokered path with phishing-resistant MFA, approval and recording. Disable every other inbound path. Keep the old path documented but disabled for a defined rollback window.
5. Build the IT/OT DMZ and zone conduits. Deploy firewall rules in monitor or log-only mode first, compare against the flow baseline, then enforce one zone at a time during a planned outage, with the previous rule set saved for immediate rollback.
6. Harden the operational layer. Allowlisting, removal of local admin, configuration monitoring and EDR on Windows hosts, piloted on one line or unit and in a test bench where one exists.
7. Add OT-aware monitoring. Feed protocol-aware detection and conduit logs into the SOC with asset IDs attached, and agree escalation paths with the control room.
8. Write and test the isolation plan. Define how the operational IT and process control networks are disconnected during an incident (7.2.1.OT), who decides, and how the plant runs manually, then exercise it.
9. Move to Advanced activities selectively. Continuous authentication and automated orchestration only where they do not touch the process control layer, or where every automated action is reviewed by a person first.

Decision guidance: what to apply where

Small sites (a water utility or a single factory with a handful of engineers) should focus on the five CISA primary mitigations, one brokered remote access path and a single DMZ, and skip anything that needs a dedicated OT SOC. Large operators with many sites should standardise conduits and remote access centrally, as the NCSC principle on centralising and standardising connections suggests, and adopt the DoW activity numbering in their GRC tooling so evidence maps to one catalogue. Organisations under IEC 62443 programmes can map zero trust work to zone target security levels instead of running a second framework. See the Zero Trust Maturity Model Guide for the enterprise side of the programme.

Detection and measurement

Zero trust in OT is only as good as the visibility behind it, and the Visibility and Analytics pillar asks for OT-specific baselines and alerts correlated to asset IDs. Monitor at least:

• Conduit traffic: denied flows at the IT/OT DMZ and zone firewalls, and any new flow not in the baseline.
• Control actions: program downloads, firmware updates, mode changes and writes to controllers outside approved change windows.
• Remote sessions: start, end, approver and recorded activity for every vendor and remote engineer session.
• Accounts: logons by service accounts to interactive sessions, use of break-glass accounts, new accounts in the OT identity store.
• New devices: unknown MAC or IP addresses on control networks.

Framework mapping

NIST SP 800-82 Rev. 3 (final, September 2023) remains the core US reference for OT security countermeasures; NIST has an initial public draft of Rev. 4 open for comment until 30 November 2026, so check for changes. See the NIST SP 800-82 OT Security Guide.

Common failure patterns

• Enterprise policy pushed into OT: a conditional access or EDR policy written for laptops quarantines an HMI or forces a reboot during production. Separate policy sets for OT and test them on a bench first.
• Forgotten remote paths: the broker is deployed but an old VPN profile or vendor modem stays live. The Colonial Pipeline ransomware attack began with an unused VPN account without MFA, and the operator shut down pipeline operations as a precaution even though the intrusion was on the IT side.
• Trusting the air gap: no monitoring on a network believed to be isolated, while laptops, USB media and temporary vendor links cross it. The DoW guidance is explicit that air gaps are not inherently safe.
• Shared service accounts across zones: one historian or SCADA service account used in the DMZ and the control zone, so a DMZ compromise reaches controllers with valid credentials.
• No rollback for segmentation: conduit rules enforced without a monitor-mode period or saved previous rule set, leading to an outage and pressure to open everything again.
• Isolation plan never exercised: the plan exists on paper but nobody has run the plant manually with OT disconnected from IT.

Practitioner checklist

• Agree written safety constraints for security controls with process safety and operations.
• Build an asset and account inventory for every OT zone, including vendor and service accounts.
• Remove all direct internet exposure and default credentials from OT.
• Route every remote and vendor session through one broker with phishing-resistant MFA, approval and recording.
• Implement an IT/OT DMZ and deny-by-default conduits between zones, piloted in monitor mode with rollback.
• Keep safety instrumented systems in their own zone with no new dependencies.
• Document compensating controls and expiry dates for every legacy device exception.
• Send OT conduit, remote access and control-action logs to the SOC with asset IDs.
• Write and exercise an isolation and manual operation plan at least yearly.

Standards and references

• Department of War CIO: Zero Trust for Operational Technology Activities and Outcomes
• NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
• NCSC and partners: Secure Connectivity Principles for Operational Technology
• CISA: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• CISA and partners: Foundations for OT Cybersecurity, Asset Inventory Guidance
• ISA: ISA/IEC 62443 Series of Standards
• MITRE ATT&CK for ICS: External Remote Services
• Intelligence Community News: NSA releases Zero Trust OT guidance

Related NHI Mgmt Group resources: OT Security Guide · Identity for OT Environments Guide · NIST SP 800-207 Zero Trust Architecture Guide · AI in OT and Industrial Systems Guide · Zero Trust Implementation Roadmap Template