Everyone references the Purdue Model. Few organizations implement it the way the standard intends. Here's what each level actually contains in a working industrial environment — and where most segmentation projects go wrong.
The Purdue Model gets mentioned in every OT security conversation. Vendors reference it in slide decks. Auditors check for it in compliance reports. But when you walk onto a plant floor and trace the actual network paths, what you find rarely matches the clean diagram everyone agreed to in the design phase.
That gap — between the Purdue Model as a reference architecture and the Purdue Model as a living network — is where most OT security risk actually lives.
This post walks through each level of the model, what it looks like when it's implemented correctly, and the patterns we see when it isn't. If your organization is evaluating OT network segmentation or preparing for an ISA/IEC 62443 audit, this is the operational context behind the framework.
The Purdue Enterprise Reference Architecture was originally developed at Purdue University in the 1990s as a way to describe the logical hierarchy of an industrial control system. NIST SP 800-82 and ISA/IEC 62443 both use it as a foundational reference for how to segment and secure OT environments.
It organizes an industrial network into numbered levels — Level 0 through Level 5 — each representing a different function in the operation. The idea is straightforward: devices at each level should only communicate with adjacent levels through controlled boundaries, and IT traffic should never reach the process layer without passing through a DMZ.
The model is not a product. It's not a firewall configuration. It's a design principle — and the value of it depends entirely on how seriously the boundaries between levels are enforced in your actual network.
This is the process itself. Sensors measuring temperature, pressure, flow rate, vibration. Actuators opening valves, starting motors, adjusting speed. These devices speak to controllers at Level 1 and nothing else. They don't have IP addresses. They don't run operating systems. They are electrical and mechanical endpoints.
The security concern at Level 0 isn't malware — it's integrity. If a sensor is feeding bad data to a controller, the controller will make bad decisions. The protection here is physical security, calibration programs, and ensuring that nothing at a higher level can directly manipulate a Level 0 device without going through the control logic.
PLCs, RTUs, and safety controllers live here. These are the devices executing the control logic that keeps the process running — the PID loops, the interlocks, the safety instrumented functions. They read from Level 0 sensors and write to Level 0 actuators.
In a properly segmented network, Level 1 devices communicate with Level 2 (HMIs, engineering workstations) and Level 0, and nothing else. The reality we see in most assessments: Level 1 controllers with IP connectivity that stretches far beyond their intended scope — vendor laptops plugged directly into controller networks, remote access sessions terminating at the PLC, or flat VLANs that let a controller share a broadcast domain with the plant historian.
HMIs, engineering workstations, and local SCADA servers. This is where operators interact with the process — viewing real-time data, acknowledging alarms, making setpoint changes. Engineering workstations are where control logic gets written and downloaded to Level 1 controllers.
Level 2 is often where segmentation breaks down first. Engineering workstations need internet access for vendor software updates. Operators want to check email. Someone connects a personal device to the HMI network. Each of these opens a path from the enterprise network (or the internet) down to the control layer — which is exactly the kind of lateral movement that the Purdue Model exists to prevent.
The plant historian, the MES (Manufacturing Execution System), batch management servers, and site-level databases. Level 3 aggregates data from Level 2 and makes it available to the business — but it's still within the OT boundary. This is the last level before the DMZ.
The critical segmentation boundary sits between Level 3 and Level 4. This is the IT/OT demarcation, and it should be enforced by an industrial DMZ — not a single firewall rule, but a dedicated zone with its own infrastructure where data passes through intermediary servers rather than flowing directly from Level 3 to Level 4.
This isn't a formal "level" in the original Purdue reference, but ISA/IEC 62443 and NIST SP 800-82r3 both treat it as the most critical architectural element in the entire model. The DMZ sits between the OT network (Levels 0–3) and the enterprise IT network (Level 4). Its purpose is simple: no direct traffic between IT and OT. Ever.
In practice, the DMZ contains data diode configurations or mirrored servers — a historian replica that the business side reads from, rather than querying the plant historian directly. Jump servers for remote access that terminate in the DMZ rather than bridging straight to a Level 2 workstation. Patch management staging areas where updates are tested before they touch OT devices.
When we assess plants that have suffered a breach or a near-miss, the DMZ is almost always the weak point. Either it doesn't exist, or it exists on paper but has been bypassed by a direct connection someone added for convenience — a remote desktop session from the corporate network to an HMI, a file share between Level 4 and Level 3, or a vendor VPN that terminates inside the OT boundary.
The corporate network. Email servers, ERP, business intelligence, web browsing. This is the domain that traditional IT security tools — EDR, SIEM, enterprise firewalls — were designed to protect.
The Purdue Model doesn't have much to say about how you run Level 4. What it does say is that Level 4 traffic must not reach Levels 0–3 without passing through the DMZ. That boundary is not optional.
The external-facing perimeter. Internet access, cloud services, partner connections. In older versions of the model this was often merged with Level 4, but modern implementations treat it separately because cloud connectivity and remote operations have made the external boundary a first-class security concern.
The Purdue Model is conceptually simple. The implementation problems aren't about misunderstanding the levels — they're about operational pressure eroding the boundaries over time.
Many plants were commissioned 10 or 15 years ago when OT cybersecurity wasn't a concern. Everything was on one VLAN. Adding segmentation after the fact means re-addressing devices, reconfiguring switches, and testing every communication path without interrupting production. It's not a weekend project — it's a phased engineering engagement that has to be coordinated around production schedules.
Equipment vendors need remote access for troubleshooting and support. If that access terminates directly at a Level 1 or Level 2 device instead of routing through a secure jump server in the DMZ, the segmentation model is compromised every time the vendor connects. This is one of the most common findings in OT assessments — and one of the easiest to fix with proper secure remote access architecture.
The network diagram says there are six VLANs with firewall rules between each zone. The actual switch configurations tell a different story — trunk ports carrying traffic they shouldn't, ACLs that were loosened during a maintenance window and never tightened back, test equipment that's been on the network for three years. Without continuous monitoring, the documented architecture and the real architecture diverge quietly until someone audits (or an attacker finds the gap first).
This is one of the reasons continuous OT network monitoring matters — it gives you ground-truth visibility into what's actually communicating on your network, not what a diagram says should be.
Implementing the Purdue Model isn't a one-time project. It's an operating model — something that has to be maintained, monitored, and enforced across every site, every shift, every vendor visit.
That means continuous monitoring to detect boundary violations as they happen. Vendor-coordinated patch management so updates don't require bypassing the DMZ. Documentation that's refreshed regularly, not just created at commissioning and forgotten. Incident response processes that understand OT context — because a triage playbook written for IT endpoints doesn't apply when the affected device is a safety controller on a production line.
If your organization is running multiple plants and finding that each site has its own version of the Purdue Model (or no version at all), the challenge isn't the framework — it's operationalizing it consistently. That's the problem that a managed OT support model is designed to solve: one operating framework, one set of SLA definitions, one triage process across every plant.
If you're evaluating your current segmentation posture, the first step is understanding what's actually on your network today — not what the commissioning documents say. A ground-truth asset inventory, combined with protocol-aware monitoring for EtherNet/IP, Profinet, and Modbus traffic, gives you the baseline you need to identify where the boundaries are, where they've been violated, and what it will take to bring them in line with the standard.
If you've already read our post on why enterprise firewalls fall short in OT environments, the Purdue Model is the structural answer to the question that post raises: how do you design a network where IT security and OT security coexist without one compromising the other?