The Purdue Model Explained: Levels, Zones, and OT Security
The Purdue model explained — the levels (0-5), the DMZ between IT and OT, how it structures industrial networks, and its role in OT cybersecurity and segmentation.
The Purdue model is the most widely referenced framework for structuring industrial control system (ICS) networks. Whether you are a controls engineer designing a new plant network, an OT security analyst hardening an existing one, or an IT professional navigating IT/OT convergence, you will encounter this model constantly — in vendor documentation, compliance frameworks, and security audits.
This guide breaks down every level, explains the critical DMZ between IT and OT, and shows how the Purdue model maps to real-world segmentation and IEC 62443 security zones.
What Is the Purdue Model? (PERA)
The Purdue Model — formally the Purdue Enterprise Reference Architecture (PERA) — is a hierarchical framework originally developed by Theodore J. Williams and the Purdue University Consortium for Computer Integrated Manufacturing (CIM) in the early 1990s. It was published as the ISA-95 precursor document and later adopted wholesale by the ISA and NIST as the de facto reference for ICS network architecture.
The model divides an industrial enterprise into six numbered levels (0 through 5), each representing a distinct layer of technology, function, and operational responsibility. The key insight is that data and commands should flow vertically between adjacent levels — not horizontally across unrelated systems, and never directly from Level 5 (internet-facing enterprise) to Level 0 (physical plant floor) without traversing all the security checkpoints in between.
This vertical, layered architecture is what makes the Purdue model so useful for security: every level boundary is a natural enforcement point for firewalls, data diodes, and access controls.
Quick definition: The Purdue model (PERA) is a hierarchical architecture that divides industrial networks into six levels — from physical sensors and actuators at the bottom to enterprise IT systems at the top — with security controls enforced at each boundary.
The Purdue Model Levels Explained
The six levels are often grouped into three broad zones: the OT zone (Levels 0–3), the DMZ (Level 3.5), and the IT zone (Levels 4–5). Here is each level in detail.
Level 0 — The Physical Process (Field Devices)
Level 0 is the plant floor itself: the physical process you are trying to control. This level consists of:
- Sensors (temperature transmitters, pressure transducers, flow meters, encoders)
- Actuators (control valves, variable-frequency drives, solenoids, motor starters)
- Physical machinery (pumps, compressors, conveyors, reactors)
There is no "network" at Level 0 in the traditional sense. Devices communicate via analog signals (4–20 mA, 0–10 V), discrete I/O (dry contacts, 24 VDC), or fieldbus protocols (HART, Foundation Fieldbus, Profibus PA). The information moving at this level is raw process data: a milliamp signal from a thermocouple, a pulse train from an encoder.
Security relevance: Level 0 devices have essentially no authentication or encryption capability. Protecting them means protecting physical access to the field wiring and panels, and controlling what Level 1 devices they are wired to.
Level 1 — Basic Control (PLC/RTU/DCS Controllers)
Level 1 is where the automated control logic lives. This level consists of:
- Programmable Logic Controllers (PLCs) — executing ladder logic, function block, or structured text programs in real time
- Remote Terminal Units (RTUs) — common in oil and gas and utility SCADA applications
- DCS controllers — distributed control system field controllers running continuous process control loops
- Safety Instrumented System (SIS) controllers — executing safety logic per IEC 61511
These devices read Level 0 sensor inputs, execute control algorithms (PID loops, sequential logic, interlock logic), and write outputs back to Level 0 actuators — all within scan cycles measured in milliseconds. They communicate upward to Level 2 via industrial Ethernet protocols: EtherNet/IP, Profinet, Modbus TCP, DNP3.
Security relevance: PLCs and RTUs are the most consequential devices in the architecture. Compromising a Level 1 device means direct, real-time control over physical equipment. This is the attack surface targeted by malware such as Stuxnet and Industroyer. Segmentation between Level 1 and everything above it is non-negotiable. See PLC security best practices for hardening guidance specific to controllers.
Level 2 — Supervisory Control (SCADA/HMI)
Level 2 is the supervisory layer: the human-machine interfaces and SCADA servers that operators use to monitor and intervene in the process. This level consists of:
- HMI workstations — operator panels and SCADA display stations showing real-time process graphics
- SCADA servers — the data acquisition servers polling PLCs and RTUs and storing historian data
- Engineering workstations — used by controls engineers to program, configure, and maintain Level 1 devices
- Alarm management servers — aggregating alarms from multiple PLCs for operator action
Level 2 communicates downward to Level 1 controllers and upward to Level 3 operations systems. This level runs a mix of real-time and near-real-time data: process values, alarm states, and operator commands.
Security relevance: Engineering workstations at Level 2 carry some of the highest risk in the entire architecture. A compromised engineering workstation can push malicious PLC firmware directly to Level 1 controllers. Access to Level 2 systems must be tightly controlled with role-based access, removable-media policies, and application whitelisting.
Level 3 — Site Operations (MES/Batch/Historian)
Level 3 represents site-wide operations management — the systems that coordinate production across multiple Level 2 cells or units within a facility. This level consists of:
- Manufacturing Execution Systems (MES) — scheduling, dispatching, and tracking production orders
- Batch management systems — coordinating multi-step batch recipes (per ISA-88) across multiple PLCs
- Plant historians — time-series databases (OSIsoft PI, Aveva Historian, Ignition Historian) storing production data for analysis
- Quality management systems — capturing inline and lab quality data against production records
- OPC-UA servers — acting as a protocol aggregation layer between Level 2 devices and Level 3 applications
Level 3 is the top of the OT zone. Data flowing upward from here leaves the real-time control domain and enters business systems.
Security relevance: The historian is a frequent attack vector. Because it needs to pull data from Level 2 continuously, poorly configured historians become a bridge that attackers can traverse from Level 4 down into the control network. Historians must be configured in a read-only, pull-from-below model — never push from above.
Level 3.5 — The Industrial DMZ (IT/OT Boundary)
Level 3.5 is not in Williams' original 1992 PERA document. It was introduced by practitioners and codified in guidance from NIST SP 800-82, IEC 62443, and NERC CIP as the modern way to handle IT/OT integration safely.
The Industrial DMZ (IDMZ) is a demilitarized zone — a network segment that sits between the OT network (Levels 0–3) and the IT network (Levels 4–5). It contains:
- Screened subnet firewalls — two firewall layers, one facing OT and one facing IT, so that neither side has direct routed access to the other
- Data brokers / jump servers — dedicated servers that accept data from OT systems and make it available to IT applications, without a routable path between them
- Remote access infrastructure — VPN concentrators, jump hosts, and privileged access management (PAM) solutions for vendor and IT personnel needing controlled access into the OT zone
- Patch management servers — WSUS servers and software distribution systems staging updates before they touch the OT network
- Anti-virus / EDR update servers — pulling signature updates from IT and pushing them into OT on a controlled schedule
The cardinal rule of the DMZ is: no direct connections traverse it. A firewall rule that allows a routable connection from Level 4 to Level 3 bypasses the DMZ entirely and defeats its purpose. All data exchange must terminate at a DMZ service and restart as a separate session on the other side.
| DMZ Component | OT-Facing Role | IT-Facing Role |
|---|---|---|
| Data broker / historian relay | Receives data from plant historian | Exposes data to ERP/analytics via API |
| Jump server / bastion host | Accepts RDP/SSH sessions from IT-side | Provides controlled access to OT workstations |
| Remote access (VPN/PAM) | Terminates vendor VPN sessions | Issues time-limited credentials with audit logging |
| Patch staging server | Pushes validated patches to OT systems | Pulls approved patches from IT software repo |
| AV update relay | Distributes definitions to OT endpoints | Pulls current definitions from cloud/IT AV server |
Level 4 — Business/Site IT (ERP and Logistics)
Level 4 is the business IT layer at the site level. This is where enterprise resource planning, production scheduling, and supply chain applications operate:
- ERP systems (SAP, Oracle, Microsoft Dynamics) — production orders, materials management, procurement
- Supply chain management — raw material tracking, dispatch scheduling
- Business intelligence / reporting — dashboards consuming historian and MES data for KPI reporting
- Corporate email and collaboration — standard IT services used at the site
Level 4 is governed by standard IT security practices: patch management, vulnerability scanning, SOC monitoring. However, it must not be treated as a trusted network relative to OT — it is squarely on the IT side of the DMZ.
Level 5 — Enterprise Network (Corporate IT / Cloud)
Level 5 is the corporate enterprise network, potentially spanning multiple sites globally:
- Corporate WAN / SD-WAN — connecting facilities to headquarters
- Cloud services — Azure, AWS, GCP workloads consuming data from OT historians
- Internet-facing systems — web applications, SaaS platforms, partner integrations
- Corporate security operations — SIEM, SOC, threat intelligence platforms
Level 5 is where the threat landscape is most hostile. Direct internet exposure, phishing, supply-chain attacks, and nation-state intrusion attempts all originate or land here first. The Purdue model treats Level 5 as inherently untrusted relative to OT — every packet from Level 5 destined for Level 3 or below must traverse the DMZ.
The IT/OT Boundary and Why the DMZ Exists
The fundamental tension the Purdue model addresses is the conflicting security priorities of IT and OT.
In IT, the CIA triad prioritizes Confidentiality → Integrity → Availability. You can patch a server offline, revoke user access instantly, or shut down a service under attack.
In OT, the priorities are inverted: Availability → Integrity → Confidentiality. A safety-critical PLC controlling a turbine or a chemical reactor cannot be rebooted mid-production. Availability is paramount, and any security control that risks uptime is resisted.
This mismatch is why a flat network — one where the ERP server and the PLC are on the same subnet — is so dangerous. An attacker who phishes a finance employee's laptop can pivot laterally to the PLC within the same broadcast domain. The Purdue model addresses this by making the OT/IT boundary explicit and enforced.
The DMZ enforces the following properties:
- No direct routable path from IT to OT (or vice versa)
- All data exchange is mediated by a service in the DMZ that terminates and re-originates each session
- Remote access is channeled through a PAM/jump server with full audit logging, not via direct VPN tunnel into the OT network
- Outbound-only data flows from OT to IT wherever possible (unidirectional security gateways / data diodes for the most critical environments)
For deeper detail on why the IT/OT boundary matters and how it affects your security posture, see OT vs IT Security: Key Differences Explained.
Why Segmentation Matters: Security and ICS Protection
The Purdue model's primary value in 2026 is as a segmentation blueprint. Each level boundary is a potential enforcement point. Properly implemented, segmentation limits the blast radius of an intrusion.
Consider a ransomware attack entering at Level 4 (a compromised ERP workstation). With proper Purdue-based segmentation:
- The DMZ firewall blocks lateral movement from Level 4 into Level 3 — the ransomware cannot reach the historian or MES
- Even if the historian is compromised via an incorrectly configured DMZ service, it does not have a routable path to Level 2 SCADA or Level 1 PLCs
- PLCs at Level 1 continue running their control logic unaffected — the physical process stays up
Without segmentation (flat network):
- Ransomware spreads from the ERP workstation to the engineering workstation
- From the engineering workstation it deploys malicious PLC firmware to Level 1 controllers
- Physical process stops or, worse, runs in an unsafe state
This is not a hypothetical scenario. The 2021 Oldsmar water treatment attack, the 2015 Ukraine power grid attack (BlackEnergy), and the Colonial Pipeline ransomware event all exploited insufficient IT/OT segmentation.
Mapping Purdue Levels to IEC 62443 Zones and Conduits
The Purdue model aligns closely with IEC 62443, the international standard for ICS cybersecurity. IEC 62443 organizes security into zones (groups of assets with similar security requirements) and conduits (controlled communication paths between zones).
The typical mapping looks like this:
| Purdue Level | IEC 62443 Zone | Typical Security Level Target |
|---|---|---|
| 0–1 (Controllers + Field) | Safety/Control Zone | SL 3–4 |
| 2 (HMI/SCADA) | Supervisory Zone | SL 2–3 |
| 3 (MES/Historian) | Operations Zone | SL 2 |
| 3.5 (DMZ) | Industrial DMZ | SL 2–3 (conduit) |
| 4–5 (IT/Enterprise) | Enterprise Zone | SL 1–2 |
Every boundary between zones in IEC 62443 requires a conduit — a defined, controlled communication path with documented protocols, firewall rules, and access policies. The Purdue model's level boundaries map naturally to these conduit enforcement points.
For ICS environments subject to IEC 62443-3-3 or NERC CIP compliance, the Purdue model provides the conceptual underpinning for zone definition even if the specific terminology differs.
The industrial control systems guide covers the full technology landscape of ICS — PLCs, DCS, SCADA, and historians — that populates the Purdue levels.
Purdue Model vs ISA-95
The Purdue model (PERA) and ISA-95 are frequently mentioned together, and for good reason: ISA-95 (also published as IEC 62264) was directly informed by the PERA work at Purdue.
The key distinction:
- Purdue model (PERA) is primarily a network and systems architecture framework. It describes the technology layers and where each class of system sits within the industrial enterprise hierarchy.
- ISA-95 is primarily a data and integration standard. It defines the object models, data structures, and interface specifications for passing information between the levels the Purdue model defines — specifically the Level 3/Level 4 boundary (the MES-to-ERP interface).
In practice, you use the Purdue model to design your network segmentation and system architecture, and ISA-95 to define what data flows across the Level 3/4 boundary and in what format. They are complementary, not competing.
Criticisms of the Purdue Model in the IIoT and UNS Era
The Purdue model was designed in 1992 for the technology of that era: proprietary fieldbus networks, serial communications, and a clear physical boundary between the plant floor and the office. The industrial landscape has shifted significantly, and a number of its assumptions are under pressure.
The IIoT Challenge
Industrial IoT architectures often require direct sensor-to-cloud paths for analytics, machine learning, and remote monitoring. A Level 0 sensor streaming vibration data to a cloud analytics platform bypasses Levels 1 through 4 entirely. Strictly enforcing the Purdue model would either prohibit this or force it through an elaborate set of proxy hops.
Modern practice tends to accommodate IIoT by treating the cloud data path as a separate, read-only conduit that is explicitly designed and controlled — not by abandoning the Purdue framework entirely, but by extending it with explicit IIoT conduit definitions.
The Unified Namespace (UNS) Challenge
The unified namespace approach, popularized by MQTT broker architectures (particularly Sparkplug B), proposes a flat, single data broker as the central hub for all plant data — devices publish to the broker, applications subscribe. This explicitly flattens the Purdue hierarchy in favor of event-driven data flows.
UNS proponents argue that the Purdue model creates artificial data silos and delays that are unnecessary with modern messaging infrastructure. Purdue advocates counter that the security boundaries remain essential even if the data topology is flat — a UNS broker sitting inside the OT zone with an IT-facing subscription interface still needs to be placed in a DMZ or secured conduit.
The honest assessment is that the security principles of the Purdue model remain valid — zone separation, enforced boundaries, DMZ mediation — but the physical layering of the architecture is increasingly a logical construct rather than a rigid topology.
Flat Networks Are Not Going Away (For the Wrong Reasons)
Many legacy industrial facilities still operate flat networks not out of intentional architectural choice but because the equipment was installed before network segmentation was standard practice. Retrofitting Purdue-style segmentation onto a 20-year-old plant with undocumented device inventories is expensive and operationally risky. This practical constraint means many OT networks remain less segmented than the Purdue model recommends, regardless of the IIoT debate.
Frequently Asked Questions
What is the Purdue model?
The Purdue model (formally the Purdue Enterprise Reference Architecture, or PERA) is a hierarchical framework that divides industrial control system networks into six levels — from physical field devices at Level 0 to enterprise IT systems at Level 5. It provides a blueprint for network segmentation, system placement, and security boundary enforcement in industrial environments.
What are the levels of the Purdue model?
The Purdue model has six levels: Level 0 (physical process — sensors and actuators), Level 1 (basic control — PLCs, RTUs, DCS controllers), Level 2 (supervisory control — SCADA, HMI, engineering workstations), Level 3 (site operations — MES, batch systems, plant historian), Level 3.5 (Industrial DMZ — the IT/OT security boundary), Level 4 (business/site IT — ERP and logistics), and Level 5 (enterprise network — corporate IT and cloud).
What is the OT DMZ?
The OT DMZ (Industrial DMZ or IDMZ), placed at Level 3.5 in the Purdue model, is a screened network segment between the OT network (Levels 0–3) and the IT network (Levels 4–5). It contains firewalls, data brokers, jump servers, and remote access infrastructure. Its purpose is to ensure no direct routable path exists between OT and IT while still allowing controlled data exchange — all traffic must terminate at a DMZ service and restart as a new session on the other side.
Is the Purdue model still relevant in 2026?
Yes, with caveats. The Purdue model's security principles — zone separation, enforced boundaries, DMZ-mediated data exchange — remain the foundation of OT network security and are directly referenced by IEC 62443, NIST SP 800-82, and NERC CIP. Its physical layering assumptions are challenged by IIoT and unified namespace architectures, which flatten data flows. Most practitioners treat the Purdue levels as logical security zones rather than rigid network topology requirements, extending the model with explicit IIoT conduits rather than abandoning it.
How does the Purdue model relate to IEC 62443?
IEC 62443 uses the concepts of zones (groups of assets with common security requirements) and conduits (controlled communication paths between zones) to structure OT security. The Purdue model's levels map directly to IEC 62443 zones — Level 1 controllers in one zone, Level 2 supervisory systems in another, with the DMZ forming the conduit between OT and IT zones. The Purdue model is the architectural blueprint; IEC 62443 is the security standard built on top of it.
Key Takeaways
- The Purdue model (PERA) structures industrial networks into six levels — field devices at the bottom, enterprise IT at the top — with security enforced at each boundary.
- Level 0 is the physical process; Level 1 is PLCs/RTUs; Level 2 is SCADA/HMI; Level 3 is MES/historian; Level 3.5 is the DMZ; Levels 4–5 are IT and enterprise.
- The Industrial DMZ at Level 3.5 is the single most important security construct in the architecture — no direct routable path between IT and OT.
- Segmentation limits blast radius: an attacker in Level 4 cannot reach Level 1 PLCs through properly enforced Purdue boundaries.
- The model maps directly to IEC 62443 zones and conduits — the Purdue levels are the zones, and the boundary enforcement points are the conduits.
- IIoT and unified namespace architectures challenge the Purdue model's physical layering but not its underlying security principles.
- Every Purdue level boundary is a firewall enforcement point — treat each one as an explicit access control decision, not a default-permit path.
Related reading: OT vs IT Security — IEC 62443 Explained — PLC Security Best Practices — Industrial Control Systems Guide
