Why the Level 3–4 Boundary Is the Most Dangerous Point in Your Network

The Purdue Reference Model has organized industrial network security since the 1990s, separating operational technology (OT) at Levels 0–3 from enterprise IT at Levels 4–5, with a demilitarized zone (DMZ) at Level 3.5 acting as the boundary. For decades, that boundary held. OT networks were air-gapped or minimally connected. The DMZ was a controlled chokepoint with limited, well-defined data flows.

That architecture no longer reflects reality. In 2025, 70% of OT systems are projected to connect to IT networks. Predictive maintenance platforms pull real-time data from PLCs to cloud analytics. ERP systems push production schedules directly to manufacturing execution systems (MES). Remote engineers access SCADA dashboards from home offices. Vendor support sessions traverse the Level 3–4 boundary routinely.

The result is an expanded attack surface at exactly the point where the Purdue Model’s defenses are weakest. 75% of OT attacks now originate as IT breaches that cross into operational technology through the Level 3–4 boundary. Ransomware groups targeting OT rose 60% year-over-year in 2025, with manufacturing accounting for 42% of all OT attack detections. The average time to patch an OT vulnerability is 180 days – six times longer than IT systems. And 65% of OT environments had insecure remote access conditions, most of them at the IT/OT convergence boundary.

The Purdue Model was designed for separation. Today’s operational reality demands integration. Applying zero trust principles to the Purdue Model – particularly at the Level 3–4 boundary – is how CISOs and security architects close this gap without disrupting the production processes that the architecture was built to protect.

This guide provides the technical framework, compliance mapping, and implementation steps for deploying zero trust across Purdue Model levels – with specific focus on securing IT/OT convergence at the most exploited boundary in industrial cybersecurity. For CISOs and security architects evaluating how to implement zero trust Purdue model OT security, the approach begins at the Level 3–4 boundary and extends inward.

The Purdue Model in 2026: What Still Works and What Doesn’t

The Six Levels

Purdue Level	Function	Typical Systems	Security Reality in 2026
Level 5	Enterprise Network	Internet, cloud, email, SaaS	Fully Zero Trust in mature orgs
Level 4	Enterprise IT	ERP, business systems, Active Directory	Partially Zero Trust
Level 3.5	DMZ (IDMZ)	Historians, jump servers, patch servers	Often poorly maintained
Level 3	Manufacturing Operations	MES, SCADA servers, engineering workstations	Minimal segmentation
Level 2	Control Systems	HMI, DCS, operator stations	Flat networks, legacy protocols
Level 1	Intelligent Devices	PLCs, RTUs, VFDs	Unpatchable, no authentication
Level 0	Physical Process	Sensors, actuators, field instruments	No cybersecurity capability

What Still Works

The Purdue Model’s layered hierarchy remains the authoritative reference for understanding data flows in industrial environments. IEC 62443 explicitly uses the Purdue zone-and-conduit model. The DoD’s November 2025 “Zero Trust for Operational Technology” guidance acknowledges that the Purdue Model, IEC 62443, and UFC 4-010-06 “remain authoritative frameworks for classifying OT systems.” The model’s value is in describing what exists – which systems sit at which level, and how data should flow between them.

What Doesn’t Work

The Purdue Model was designed for separation between IT and OT. It assumed that Levels 0–3 would remain isolated from Levels 4–5, with the DMZ at Level 3.5 serving as a strict boundary. Three developments have broken this assumption.

IT/OT convergence has dissolved the boundary. Cloud analytics, remote access, IIoT devices, and ERP-to-MES integration create continuous bidirectional data flows across Levels 3–4. The DMZ that was supposed to be a controlled chokepoint now handles dozens of uncontrolled connections.

Flat networks exist within levels. The Purdue Model defines boundaries between levels but says little about segmentation within levels. Level 2 and Level 3 networks are typically flat – every device can communicate with every other device. A compromised HMI at Level 2 can reach every PLC on the same network segment.

Trust is assumed within each level. If a user or device is “inside” a Purdue level, it is implicitly trusted. There is no per-session verification, no identity-based access control, and no continuous authorization. This is the exact opposite of Zero Trust.

The DoD’s Answer: Simplifying Purdue for Zero Trust

In November 2025, the U.S. Department of Defense released “Zero Trust for Operational Technology Activities and Outcomes” – a 28-page document that represents the most authoritative zero trust Purdue model OT security guidance published to date. This guidance follows DTM 25-003, issued in July 2025, which directed all DoD components to achieve Target Level Zero Trust across all systems, including OT.

The Two-Layer Abstraction

The DoD guidance collapses the traditional five-layer Purdue Model into two layers for applying Zero Trust principles:

Operational Layer – encompasses Purdue Levels 3, 3.5, and 4. Includes application services, control center workstations, HMI, operator workstations, engineering workstations, historians, and wireless gateways. This is where IT/OT convergence happens and where most Zero Trust controls are implemented.

Process Control Layer – encompasses Purdue Levels 0, 1, and 2. Includes field control devices (PLCs, RTUs), sensors, actuators, and basic control loops. These systems often cannot support modern authentication or encryption, requiring compensating controls rather than direct Zero Trust implementation.

The guidance explicitly states that this abstraction “does not replace the standard reference architectures” – the Purdue Model remains authoritative for classifying systems. Instead, the two-layer model provides a practical framework for applying Zero Trust principles without being overly prescriptive about which specific Purdue level each control applies to.

105 Activities, 84 Mandatory

The DoD guidance defines 105 distinct security activities – 84 designated as mandatory “Target Level” requirements and 21 as “Advanced Level.” Key mandatory activities include identity verification for every access request to OT systems, microsegmentation of communication pathways within and between OT zones, deny-by-default network policies that enforce contextual access decisions, continuous monitoring of device posture and access patterns, session-level access controls (no standing privileges), and encrypted communications across all inter-zone and remote access pathways.

Five Zero Trust Controls for Each Purdue Boundary

Applying zero trust to the Purdue model for OT security requires implementing specific controls at each boundary. The controls below address the convergence points where attacks most commonly cross between levels.

Boundary 1: Internet → Enterprise IT (Level 5 → Level 4)

This boundary is typically the most mature, with existing firewalls, SWG, and CASB controls. Zero Trust enhancements include identity-verified access to all enterprise applications (ZTNA replacing VPN), device posture assessment before access is granted, continuous session validation with automatic termination on policy violation, and DLP enforcement on data flowing from enterprise systems toward OT.

Boundary 2: Enterprise IT → IDMZ (Level 4 → Level 3.5) – THE CRITICAL BOUNDARY

This is where IT/OT convergence creates the greatest risk. The IDMZ was designed as a controlled buffer zone, but in practice it has become a pass-through for dozens of uncontrolled connections. Zero trust controls at this boundary must enforce per-application access from IT to IDMZ services – no broad network access, outbound-only data flow from OT to IDMZ (OT pushes data to historian mirrors and relays; IT reads from IDMZ, never directly from OT), identity-based access controls for every user and application that crosses this boundary, session recording for all cross-boundary sessions (remote engineering, vendor support, administrative access), and time-bounded access with automatic expiration for all non-permanent connections.

The January 2026 CISA/NCSC-UK joint guidance on OT connectivity explicitly states: “All connections with the OT environment should be initiated as outbound connections from within the OT environment.” This principle directly applies to the Level 4 → Level 3.5 boundary – IT should never initiate inbound connections to the IDMZ or OT network.

Boundary 3: IDMZ → Manufacturing Operations (Level 3.5 → Level 3)

This boundary separates the DMZ from the manufacturing operations zone. Zero Trust controls include reverse-access architecture – Level 3 systems initiate outbound connections to the IDMZ; the firewall at this boundary stays in deny-all for inbound traffic. Application-level gating ensures that only explicitly authorized data flows (historian replication, patch distribution, configuration management) cross this boundary. Protocol inspection validates that only expected OT protocols traverse the conduit. No IT protocols (SMB, RDP, HTTP from enterprise) should reach Level 3 directly.

Boundary 4: Manufacturing Operations → Control Systems (Level 3 → Level 2)

This boundary separates SCADA servers and MES from the control systems that directly operate physical processes. Zero Trust controls include network segmentation that prevents engineering workstations from communicating with control devices they are not authorized to access, application-layer access controls on SCADA-to-PLC communication, change management verification before configuration changes are allowed to reach PLCs, and session isolation – an engineer configuring one PLC cannot reach others in the same zone without separate authorization.

Boundary 5: Control Systems → Physical Process (Level 2 → Level 0/1)

Devices at Levels 0 and 1 (sensors, actuators, PLCs) typically cannot support Zero Trust controls directly – they lack the computing resources for authentication, encryption, or agent-based security. Compensating controls include network-level enforcement through microsegmentation that isolates each device or device group, protocol whitelisting that blocks all communication except expected OT protocols (Modbus, EtherNet/IP, PROFINET), unidirectional data flow enforcement (sensors push data outward; no inbound commands from unauthorized sources), and physical security controls (locked panels, tamper detection) as the final defense layer.

IT/OT Convergence Attack Scenarios and Zero Trust Responses

Scenario 1: Ransomware Traversing from IT to OT

Attack path: Attacker compromises an employee’s workstation at Level 4 through phishing. Ransomware propagates via SMB to the IDMZ historian server (Level 3.5), which has network connectivity to Level 3 SCADA servers. The ransomware encrypts SCADA databases, causing loss of visibility and control over manufacturing operations.

Without Zero Trust: The flat network between Level 4 and Level 3.5 allows SMB propagation. The historian server has standing credentials to Level 3 systems. There is no boundary enforcement beyond a permissive firewall rule.

With Zero Trust on the Purdue Model: Identity-based access at the Level 4→3.5 boundary prevents the compromised workstation from reaching the historian – the workstation is not authorized for historian access. Microsegmentation within Level 3.5 isolates the historian from other IDMZ services. Outbound-only data flow means the historian receives data from OT but does not accept inbound connections from IT. Even if the historian were compromised, reverse-access architecture prevents it from initiating connections to Level 3 systems.

Scenario 2: Vendor Credential Compromise

Attack path: A PLC vendor’s VPN credentials are stolen through a credential-stuffing attack. The attacker connects through the VPN, which grants network-level access to the Level 3 manufacturing operations zone. The attacker moves laterally from the VPN landing zone to SCADA servers, engineering workstations, and eventually PLC programming interfaces.

With Zero Trust: The vendor authenticates at an access gateway instead of a VPN. The gateway grants application-level access to the specific PLC programming interface the vendor is authorized to use – no network access. The session is time-bounded (4-hour window), recorded, and requires MFA with device posture verification. Lateral movement is impossible because the vendor’s session is isolated to a single application.

Scenario 3: Insider Threat at Level 3

Attack path: A disgruntled engineer with legitimate Level 3 access uses their engineering workstation to modify PLC ladder logic, introducing a logic bomb that will cause a process failure 30 days later.

With Zero Trust: Per-session authorization requires the engineer to authenticate specifically for PLC programming access – separate from their general Level 3 access. The session is recorded with full keystroke and screen capture. Change management controls require a second approval before configuration changes are pushed to PLCs. Behavioral baselines flag the unusual access pattern (programming a PLC outside the engineer’s normal scope).

IEC 62443 Alignment: Zero Trust Meets Zone-and-Conduit

IEC 62443’s zone-and-conduit model is directly compatible with Zero Trust principles – both require controlled communication between defined security domains. Together, they form the compliance backbone of any zero trust Purdue model OT security implementation. Here is how Zero Trust enhances each IEC 62443 foundational requirement within the Purdue framework:

IEC 62443 FR	Purdue Boundary Most Affected	Zero Trust Enhancement
FR1 – Identification & Authentication	Level 4→3.5 (remote access)	Per-session identity verification with MFA at every cross-level access
FR2 – Use Control	All boundaries	Per-application, per-user policies replace implicit trust within zones
FR3 – System Integrity	Level 3→2 (PLC programming)	Change management with session recording and dual authorization
FR4 – Data Confidentiality	Level 3.5 (IDMZ data transit)	End-to-end encryption (TLS 1.3) for all cross-boundary communication
FR5 – Restricted Data Flow	Level 4→3.5 and Level 3.5→3	Outbound-only data flow from OT; IT reads from IDMZ relay only
FR6 – Timely Response	All boundaries	Immutable session-level audit trails integrated with SIEM
FR7 – Resource Availability	Level 5→4 (DDoS), Level 4→3.5	Reverse-access eliminates inbound attack surface at OT boundary

Implementation Roadmap for Security Architects

Effective zero trust Purdue model OT security deployment follows a boundary-by-boundary approach, starting where the risk is highest and expanding inward toward the process control layer.

Phase 1: Map Your Actual Purdue Architecture (Weeks 1–4)

Most organizations’ networks do not match their documented Purdue diagrams. Before applying Zero Trust, map reality:

• Inventory every connection that crosses the Level 3–4 boundary (including shadow IT connections)
• Document every remote access pathway (VPN, RDP, TeamViewer, vendor portals)
• Identify all data flows between IT and OT (historian replication, ERP integration, patch distribution, SIEM ingestion)
• Classify each connection by Purdue level, protocol, direction, and frequency
• Flag connections that violate the Purdue Model’s intended separation

A former DHS official found that no completely isolated OT networks exist – on average, industrial networks have 11 links to IT that managers are unaware of. This discovery phase is essential.

Phase 2: Secure the Level 4→3.5 Boundary (Weeks 5–12)

Start where the risk is highest – the IT/OT convergence boundary:

• Deploy identity-based access controls for all cross-boundary access
• Replace VPN-based remote access with application-level ZTNA
• Implement outbound-only data flow from OT to IDMZ (historian pushes to relay; IT reads from relay)
• Configure time-bounded, session-recorded access for all vendor and contractor sessions
• Set firewall to deny-all for inbound traffic from Level 4 to Level 3.5 – all connections initiated from OT side

Phase 3: Segment Within Levels (Weeks 13–22)

Address the flat-network problem within Purdue levels:

• Deploy microsegmentation at Level 3 to isolate SCADA servers from engineering workstations
• Segment Level 2 control systems by function or criticality (safety systems isolated from process control)
• Implement identity-based segmentation that controls workload-to-workload communication based on identity, not network location
• Apply protocol whitelisting at Level 1/0 boundaries

Phase 4: Extend to Process Control Layer (Weeks 23–32)

Apply compensating controls to Levels 0–2 where devices cannot support direct Zero Trust:

• Network-level enforcement through microsegmentation and protocol filtering
• Gateway-mediated access for PLC programming and configuration changes
• Unidirectional enforcement for sensor data (push outward only)
• Physical access controls as the final layer for field devices

Phase 5: Continuous Validation (Ongoing)

• Quarterly access reviews across all Purdue boundaries
• Annual penetration testing specifically targeting Purdue boundary controls
• Continuous compliance monitoring against IEC 62443 and organizational security policies
• Architecture re-assessment whenever new IT/OT integration pathways are introduced

Common Mistakes in Zero Trust Purdue Deployments

Applying IT Zero Trust directly to OT without adaptation. The DoD guidance explicitly warns that “applying standard IT security approaches to OT environments can be ineffective and potentially dangerous.” OT systems prioritize availability and safety over confidentiality. Zero Trust controls must not introduce latency to real-time control loops, require reboots of 24/7 production systems, or block safety-critical communications during authentication timeouts.

Securing the Level 4→3.5 boundary but ignoring flat networks within levels. Zero Trust at the Purdue boundary is necessary but insufficient. If Level 3 is a flat network, a breach that crosses the boundary has unrestricted movement within the zone. Microsegmentation within levels is equally critical.

Treating the IDMZ as a pass-through instead of a security control plane. The IDMZ should broker, inspect, and control all cross-boundary communication – not simply forward traffic. Historian mirrors, patch staging servers, and authentication gateways should all reside in the IDMZ, preventing direct connections between IT and OT.

Deploying ZTNA for web applications only. OT environments depend on protocols that many ZTNA solutions do not support – Modbus/TCP, EtherNet/IP, PROFINET, OPC-DA, proprietary PLC programming protocols, and SMB file sharing. If ZTNA covers web apps but forces VPN fallback for these protocols, the Purdue boundary protection is incomplete.

Ignoring physical-layer security at Levels 0–1. Zero Trust for OT cannot be purely digital. Field devices that lack authentication must be protected through physical controls – locked panels, tamper detection, and restricted physical access to control cabinets.

Conclusion

The Purdue Model is not obsolete – but it is incomplete. It describes where systems sit and how data should flow, but it does not prevent unauthorized access, lateral movement, or boundary violations. Zero Trust adds the controls that the Purdue Model’s architecture always assumed but never enforced: verify every identity, validate every device, authorize every session, and encrypt every communication – at every level and every boundary.

The DoD’s November 2025 guidance made this explicit by defining 105 mandatory and advanced Zero Trust activities for OT systems. The January 2026 CISA/NCSC-UK guidance reinforced the outbound-only connectivity principle for OT environments. IEC 62443’s zone-and-conduit model provides the architectural foundation. And the threat data – 75% of OT attacks crossing from IT, 65% insecure remote access, 180-day patching cycles – demonstrates why the Level 3–4 boundary cannot remain protected by a permissive firewall and an undermaintained IDMZ.

For CISOs and security architects implementing zero trust across the Purdue model, the starting point is clear: map the actual architecture (not the documented one), secure the Level 4→3.5 boundary with outbound-only, identity-verified access, segment within levels to prevent lateral movement, and extend compensating controls to the process control layer. Implementing zero trust Purdue model OT security is not a rip-and-replace exercise – it is a layered enhancement that respects the Purdue hierarchy while adding the controls it always needed. The Purdue Model tells you where the zones are. Zero Trust tells you how to defend them.