Purdue Model vs Zero Trust for OT: Where Each Holds and How to Layer Them

Plant owners keep being told to choose between the Purdue model and zero trust, when the real question is which problems each one solves and where the layered design starts to leak. The Purdue reference model gives an industrial network its levels and its DMZ; zero trust removes the assumption that anything inside a level is trustworthy because of where it sits. This guide compares the two as architectures for operational technology (OT): what each protects against, where segmentation still holds, where it fails (cloud historians, direct IIoT connections, vendor remote access), how far identity can reach on legacy controllers, and how to combine them. It is for OT security architects, control engineers and CISOs. Zone design basics are covered in the OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide, and the full control catalogue for zero trust in plants is in the Zero Trust for OT and ICS Guide.

Key takeaways

• They answer different questions. Purdue and IEC 62443 zones answer "what may talk to what"; zero trust answers "should this subject, on this device, get this session now". An OT network needs both answers.
• Segmentation still carries the process control layer. NIST SP 800-82 Rev. 3 says a zero trust architecture might not be practical for some OT devices and suggests applying it to compatible devices at Purdue levels 3 to 5 and the OT DMZ.
• The levels leak at three predictable places. Cloud-connected historians and analytics, IIoT devices that talk straight to a platform, and vendor remote access each create paths that the level diagram does not show.
• Identity stops at the conduit for legacy devices. Where a PLC cannot authenticate a session, the policy decision moves to a broker, jump host or protocol-aware firewall in front of it, and monitoring covers what enforcement cannot.
• The hybrid is the destination, not a compromise. Keep Purdue zones as the blast radius boundary, put zero trust policy enforcement points on every conduit that a human or a cloud service crosses, and measure both.

The short answer

Do not replace the Purdue model with zero trust in a plant. Use the Purdue levels and IEC 62443 zones to limit how far a compromise can spread, and use zero trust to decide who and what may cross each boundary. NIST SP 800-82 Rev. 3 (section 5.2.3.4) reaches the same position: it describes zero trust as authorisation that is continuously evaluated rather than implicitly granted, notes that perimeter defences alone do not stop lateral movement because insiders are treated as trusted, and then cautions that PLCs and HMIs may lack the support zero trust needs. It also flags shared credentials in OT as an obstacle to full adoption. The practical reading is a split: zero trust where devices and users can support it, segmentation and monitoring where they cannot, and policy enforcement at the boundary between the two.

The Purdue model as an architecture

Threat model: the attacker starts on the enterprise network (phishing, a compromised server) and tries to reach the control network. The Purdue levels stack enterprise systems (levels 4 and 5) above site operations (level 3), supervisory control (level 2), basic control (level 1) and the physical process and field I/O (level 0), with an industrial DMZ, often called level 3.5, between business and operations. NIST SP 800-82 Rev. 3 names the Purdue model as one industry model for organising OT segmentation and recommends firewall rules that prevent level 4 devices from communicating directly with level 2, 1 or 0 devices.

Architecture in words: traffic from the enterprise terminates in the DMZ. Historian replicas, patch staging, file transfer and remote access brokers live there, so no session passes straight through. IEC 62443 turns this into engineering terms: a zone groups assets with common security requirements, a conduit groups the communication channels between zones, and each zone gets a target security level from SL1 (casual or coincidental violation) to SL4 (sophisticated means with extended resources). Restricted Data Flow is one of the seven 62443 foundational requirements, which is the formal home of segmentation.

What it does well: it needs nothing from the device. A 20-year-old controller speaking an unauthenticated protocol is protected exactly as well as a new one, because the decision happens on the wire. It also maps cleanly to the isolation plans in the NCSC-led secure connectivity principles, where a well-segmented site can isolate one service instead of the whole site.

Where it fails: the model assumes data flows up and down through the levels. Modern plants have flows that skip levels, and inside a level everything is implicitly trusted. An engineering workstation on level 2 with a valid account can download logic to every controller it can route to (ATT&CK for ICS T0843 Program Download), and the firewall above it never sees the session.

Zero trust as an architecture for OT

Threat model: the attacker already has a valid account or a foothold on a trusted device. MITRE ATT&CK for ICS lists External Remote Services (T0822), Remote Services (T0886) and Valid Accounts (T0859) among the techniques used to enter and move inside control environments. A segmented network does not stop any of these if the session is allowed by the conduit rule.

Architecture in words: NIST SP 800-207 (final, August 2020) separates subject and device authentication and authorisation into discrete steps performed before a session with a resource is established, and moves protection from network segments to resources. In OT the policy decision point usually sits in the operational layer or DMZ, and the policy enforcement points are the remote access broker, the jump host or privileged access workstation, the protocol-aware firewall on each conduit and, only where the component supports it, the device itself.

What it does well: it removes standing trust. A vendor session is approved per job, tied to a named person with phishing-resistant MFA, limited to the assets in the work order and recorded. An engineering workstation must be a known, compliant device before it can reach a controller. See the NIST SP 800-207 Zero Trust Architecture Guide for the general model.

Where it fails: zero trust depends on things many OT components cannot do: carry an identity, present a certificate, run an agent or tolerate a re-authentication mid-session. Ending a session on a risk change is fine on a laptop and dangerous on an operator HMI mid-procedure. It also adds a dependency: without a local fallback, an unreachable policy service locks the site out of its own process.

Where segmentation still holds

• Process control layer: levels 0 to 2 and safety instrumented systems still depend on zone boundaries and tightly specified conduits. NIST SP 800-82 Rev. 3 points zero trust at levels 3 to 5 and the DMZ precisely because these lower levels often cannot support it.
• Obsolete components: the secure connectivity principles say obsolete products should be treated as untrusted, should not be used to implement security controls and should not be exposed directly to external networks. Segmentation, protocol gateways and hardened jump hosts are the listed compensating controls.
• Isolation during an incident: the CISA, FBI, EPA and DOE primary mitigations include segmenting IT and OT and practising manual operation. A clean level structure is what makes "disconnect the plant from IT and keep running" possible.

Where the level model leaks

The NCSC-led principles address most of these directly: all connections with the OT environment should be initiated outbound from inside OT, external parties should reach assets through a broker in a separate segment such as the DMZ, remote access should be centralised in the DMZ rather than spread across per-vendor VPN endpoints, and cloud use with dynamic public addressing needs an accurate record of exposed addresses. The historian case gets its own treatment in the OT Process Historian Security Guide, and IIoT design in the Industrial IoT (IIoT) Security Guide.

How far identity reaches on legacy devices

In OT the assumption that every subject can be identified breaks in layers. Move the policy decision to the nearest component that can make it.

The secure connectivity principles ask for secure protocol versions by default, a business case for each insecure protocol, a migration roadmap to secure variants and compensating controls where encryption is not feasible. Treat each legacy exception as a documented risk with an owner and review date. The machine identities in this table (historian connectors, OPC servers, SCADA service accounts) are covered in NHIs in OT, and the people side in the Identity for OT Environments Guide.

Designing the hybrid

1. Freeze the zone model as the blast radius boundary. Keep the Purdue levels and 62443 zones you have; record each conduit with its owner, permitted flows and target security level. If the network is flat, segment first, because zero trust policies have nothing to anchor to on a flat network.
2. Classify every conduit by who crosses it. Machine-to-machine conduits inside the process control layer stay as static allow lists. Conduits crossed by humans, by cloud services or by vendors become zero trust enforcement points.
3. Put the policy decision point in the operational layer. Run OT-local identity and policy services in level 3 or the DMZ so that a WAN or cloud outage does not lock the site out, with sealed break-glass accounts whose use raises the highest-severity SOC alert, as the secure connectivity principles recommend.
4. Broker every human and vendor session. One path, initiated or relayed from the DMZ, with phishing-resistant MFA, approval per job, time limits and recording. Disable the old paths, but keep their configuration documented for a defined rollback window.
5. Give machines their own identities. One credential per connector, historian interface or data broker, scoped to its conduit, never shared across zones, rotated in maintenance windows.
6. Add device trust where it is real. Compliance checks for engineering workstations and HMIs; secure protocol variants only after vendor qualification and bench testing; NAC on OT switches for unknown devices (see the NAC for OT Networks Guide).
7. Test in monitor mode, then enforce one zone at a time. Log-only policies first, compared against a multi-week flow baseline that includes monthly and seasonal jobs; enforce during a planned outage with the previous rule set saved for immediate rollback.
8. Keep automatic blocking out of the process control layer. Use alerting and human approval below level 3; reserve automated session termination for the operational layer and remote access.

Worked scenarios

Water utility with a cloud SCADA project: a small utility wants telemetry in a hosted SCADA service. Purdue alone misses that the service may need setpoint writes. The hybrid answer: a dedicated cloud conduit initiated outbound from the DMZ, a named workload identity for the connector, read-only telemetry by default, setpoint writes on a separate path with operator confirmation on site, and an isolation plan that keeps local control running if the cloud link is cut.

Discrete manufacturer with many machine builders: 30 vendors each have their own remote support tool on line HMIs. Each tool is a hidden path across existing segmentation. The fix is zero trust at one conduit: remove the per-vendor tools, broker all sessions in the DMZ with per-asset scope and recording, and alert on any new outbound remote support connection from levels 2 and 3. The sibling page OT Remote Access vs IT VPN covers the access pattern choice.

Refinery with safety instrumented systems: the SIS stays in its own zone with a read-only conduit out, and no zero trust component is added to anything the SIS depends on. Zero trust is applied to the engineering workstations that can program the SIS, with a second-person approval for logic changes.

Decision guidance

Common failure patterns

• Declaring Purdue obsolete: flattening OT networks in the name of zero trust and relying on agents and identity that controllers cannot support, which removes the only control protecting level 0 to 2 devices.
• Zero trust in name only: a new access broker deployed while per-vendor VPNs, modems and remote support tools stay live, so the old paths bypass the new policy.
• Cloud dependency in the control path: access policy, identity or even control logic that needs a cloud service, with no local fallback, so a WAN outage becomes a production outage.
• Trusting everything inside a level: an engineering workstation or shared account with reach to every controller in the zone, never re-verified because the firewall above it is strong.

Detection and measurement

Log conduit decisions, brokered sessions, program downloads and mode changes outside change windows, interactive service account logons, break-glass use and new outbound connections from levels 2 and 3. See the OT Network Security Monitoring Guide.

Framework mapping

Practitioner checklist

• Keep the Purdue and 62443 zone model as the blast radius boundary and document every conduit with an owner.
• Find and remove every path into levels 0 to 3 that bypasses the DMZ, including modems and vendor remote support tools.
• Classify conduits as machine-only (static allow lists) or crossed by humans, vendors or cloud services (zero trust enforcement).
• Run OT-local identity and policy services with tested break-glass accounts.
• Broker all remote and vendor sessions with phishing-resistant MFA, per-job approval and recording.
• Issue one scoped credential per historian connector, data broker and service account, never shared across zones.
• Document each legacy device exception with compensating controls and a review date.
• Test new policies in monitor mode against a multi-week flow baseline and keep the previous rule set for rollback.

Standards and references

• NIST: SP 800-82 Rev. 3 Guide to Operational Technology (OT) Security
• NIST: SP 800-207 Zero Trust Architecture
• NCSC and partners: Secure Connectivity Principles for Operational Technology
• CISA, FBI, EPA and DOE: Primary Mitigations to Reduce Cyber Threats to Operational Technology
• ISA: ISA/IEC 62443 Series of Standards
• ISA Global Cybersecurity Alliance: Quick Start Guide, An Overview of ISA/IEC 62443 Standards
• MITRE ATT&CK for ICS: External Remote Services
• MITRE ATT&CK for ICS: Valid Accounts

Related NHI Mgmt Group resources: Zero Trust for OT and ICS Guide · OT Network Segmentation, Purdue Model and IEC 62443 Zones and Conduits Guide · Zero Trust vs Perimeter Security · Identity for OT Environments Guide · OT Security Guide