Purdue model (formally the Purdue Enterprise Reference Architecture, or PERA) is a five-level reference architecture for industrial control system (ICS) networks. It defines a hierarchical separation between field devices at Level 0 and enterprise IT at Level 4, with control, supervisory, and operations layers in between.
How the Purdue model works
The Purdue model was developed at Purdue University in the 1990s to provide a logical framework for organizing the components of a manufacturing enterprise. It divides the network into distinct levels:
- Level 0 (Process): Physical sensors, actuators, and field instruments that directly interact with the manufacturing process.
- Level 1 (Basic control): PLCs, RTUs, and safety instrumented systems that execute real-time control logic.
- Level 2 (Area supervisory): HMIs, engineering workstations, and local SCADA servers that provide operator visibility and control within a production area.
- Level 3 (Site operations): Historians, MES platforms, and site-wide SCADA that aggregate data across production areas and manage scheduling and workflow.
- Level 3.5 (Industrial DMZ): A buffer zone added later to the original model, mediating all traffic between OT (Levels 0 through 3) and IT (Levels 4 and above).
- Level 4 (Enterprise): Business systems including ERP, email, and corporate IT infrastructure.
The model was designed primarily for availability and operational efficiency, not for cybersecurity. Each level communicates with its immediate neighbors, and traffic should not skip levels. Firewalls or routers at each boundary enforce this hierarchy.
The core assumption underlying the Purdue model is that physical separation and hierarchical firewalling are sufficient to protect lower levels from threats originating in the enterprise or internet. This assumption has eroded significantly over the past decade.
Why the Purdue model is breaking down
IT/OT convergence has punched holes through every layer of the Purdue hierarchy. Cloud-based analytics platforms pull historian data from Level 3 directly to external services, bypassing the DMZ. Remote access solutions allow vendors to connect to Level 1 PLCs from the internet. IIoT devices at Level 0 transmit telemetry over cellular or Wi-Fi links that never touch the hierarchical firewall chain.
Each of these connections is a lateral path that the Purdue model was never designed to account for. The result is a network that looks like a Purdue diagram on paper but behaves like a flat network in practice. Attackers who compromise a single connection path can move laterally across levels without triggering the boundary controls that the architecture depends on.
Modern zero-trust architectures address this by replacing implicit trust based on network location with explicit identity verification for every connection. Instead of relying on hierarchical boundaries, each device and user must authenticate before reaching any resource, regardless of which "level" they occupy.
OT and industrial context
A water treatment facility operating under the Purdue model might place its SCADA server at Level 3 and its PLCs at Level 1, with a firewall between them. If a vendor needs remote access to update PLC firmware, the facility must punch a hole through Levels 4, 3.5, 3, and 2 to reach Level 1. Each firewall rule added for this purpose persists long after the maintenance window closes, creating a permanent attack surface.
In power generation, the Purdue model's assumption of isolated OT networks conflicts with regulatory requirements for real-time telemetry reporting to grid operators. The data must flow from Level 2 or 3 to external entities, and the hierarchical model provides no clean mechanism for authorizing this traffic on a per-identity or per-session basis.
Compliance relevance
IEC 62443 builds on Purdue-model concepts with its zones and conduits framework, but extends them to require explicit risk assessment for each communication path. NERC CIP-005 mandates Electronic Security Perimeters that map loosely to Purdue levels but require more granular access controls. NIST SP 800-82 references the Purdue model as a starting point for ICS network architecture but acknowledges the need for defense-in-depth beyond hierarchical segmentation.
Related terms
Access Gate connection
Access Gate replaces the rigid hierarchical boundaries of the Purdue model with identity-enforced overlay networking, enabling granular microsegmentation without redesigning the physical network. Learn more at Beyond the Purdue model.
