The Purdue Model (formally the Purdue Enterprise Reference Architecture, or PERA) is a five-level reference architecture for industrial control system 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. For three decades it has been the default mental map for how a plant network should be laid out.
How does the Purdue Model work?
The model was developed at Purdue University in the 1990s to give manufacturing a logical framework for organizing plant systems. It divides the network into distinct levels:
- Level 0 (Process): physical sensors, actuators, and field instruments that touch the process directly.
- Level 1 (Basic control): PLCs, RTUs, and safety instrumented systems that run real-time control logic.
- Level 2 (Area supervisory): HMIs, engineering workstations, and local SCADA servers that give operators visibility within a production area.
- Level 3 (Site operations): historians, MES platforms, and site-wide SCADA that aggregate data and manage scheduling.
- Level 3.5 (Industrial DMZ): a buffer zone added later, 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.
The design goal was availability and operational efficiency, not cybersecurity. Each level talks only to its neighbors, traffic should not skip levels, and a firewall or router at each boundary enforces the hierarchy. The core assumption is that physical separation and layered firewalling keep the lower levels safe from threats that originate in the enterprise or on the internet.
Why is the Purdue Model breaking down?
IT/OT convergence has punched holes through every layer of the hierarchy. Cloud analytics platforms pull historian data from Level 3 straight to external services, bypassing the DMZ. Remote access tools let vendors reach Level 1 PLCs from the internet. IIoT devices at Level 0 send telemetry over cellular or Wi-Fi links that never touch the firewall chain.
Each of these is a lateral path the 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. An attacker who compromises one connection can move across levels without tripping the boundary controls the architecture depends on. Modern zero-trust approaches answer this by replacing trust based on network location with explicit identity verification for every connection.
What does the Purdue Model look like in real OT environments?
A water treatment facility might place its SCADA server at Level 3 and its PLCs at Level 1, with a firewall between them. When a vendor needs remote access to update PLC firmware, the facility punches a hole through Levels 4, 3.5, 3, and 2 to reach Level 1. Each firewall rule added for that job tends to outlive the maintenance window, leaving a permanent opening.
In power generation, the model's assumption of isolated OT networks collides with regulatory requirements for real-time telemetry to grid operators. Data has to flow from Level 2 or 3 to outside entities, and the hierarchy offers no clean way to authorize that traffic per identity or per session.
How does the Purdue Model relate to compliance frameworks?
IEC 62443 builds on Purdue concepts with its zones-and-conduits framework but extends them to require an explicit risk assessment for each communication path. NERC CIP CIP-005 mandates Electronic Security Perimeters that map loosely to Purdue levels while demanding more granular access control. NIST SP 800-82 cites the Purdue Model as a starting point for ICS architecture but calls for defense-in-depth well beyond hierarchical segmentation.
How Access Gate helps
Access Gate replaces the rigid hierarchical boundaries of the Purdue Model with identity-enforced overlay networking, enabling granular microsegmentation without redesigning the physical network. Instead of a device inheriting trust from the level it sits on, each session authenticates before it reaches a resource. Learn more at Beyond the Purdue Model.
