The Purdue Enterprise Reference Architecture (PERA), commonly called the Purdue Model, is the most widely used conceptual framework for structuring industrial control system networks. Developed at Purdue University in the 1990s, it remains the baseline for OT network design even as cloud and IIoT architectures challenge its rigid hierarchy. Understanding the model — and its limitations — is essential for any engineer working on industrial cybersecurity or network design.

The Five Levels of the Purdue Model

The Purdue Model organises an industrial enterprise into five numbered levels, each representing a different function and communication requirement:

  • Level 0 — Field Devices: Physical process equipment: sensors (pressure transmitters, flow meters, temperature elements), actuators (control valves, motors, dampers), and analysers. These are the devices that directly interact with the physical process. Communication at this level is typically 4-20 mA, HART, or fieldbus (PROFIBUS PA, FOUNDATION Fieldbus H1).
  • Level 1 — Basic Control: The PLCs, DCS controllers, and safety system logic solvers that execute real-time control. These devices read Level 0 field values and send output signals back to actuators on a millisecond to second cycle. Communication uses PROFIBUS DP, PROFINET, EtherNet/IP, or proprietary protocols.
  • Level 2 — Supervisory Control: SCADA systems, DCS operator stations, HMI displays, and engineering workstations. These systems provide operator visibility, setpoint entry, and alarm management. They communicate with Level 1 controllers over the plant control network (PCN), typically an isolated Ethernet LAN.
  • Level 3 — Manufacturing Operations: Manufacturing Execution Systems (MES), Laboratory Information Management Systems (LIMS), batch management, historian servers, and real-time performance management. This level aggregates data from multiple control systems and provides production-level reporting. It sits at the top of the OT world, just below the enterprise boundary.
  • Level 4 — Business Planning and Logistics: Enterprise IT systems — ERP (SAP, Oracle), supply chain management, business intelligence. This is the corporate IT world. Communication with Level 3 is controlled and typically passes through a DMZ.

Some references add a Level 5 for external networks and internet connectivity, though many organisations treat this as an extension of Level 4.

The DMZ: The Critical Security Boundary

The most important security feature of the Purdue Model implementation is the Demilitarized Zone (DMZ) between Level 3 and Level 4. The DMZ is a separate network segment containing data servers, historian replication services, and file transfer utilities that allow limited, controlled data exchange between OT and IT without direct connectivity.

In practice, the DMZ should be implemented with two firewalls: one between Level 4 (IT) and the DMZ, and one between the DMZ and Level 3 (OT). Traffic rules should be whitelist-based — only explicitly allowed protocols and IP pairs are permitted. Denying all traffic by default and allowing only what is specifically required is the foundation of DMZ security.

Common services that legitimately cross the DMZ include: historian replication (OSIsoft PI, Aspen IP.21), SFTP file transfer for reports, and read-only OPC DA/UA connections from business systems to process data. Direct RDP, SMB file shares, and network management traffic should never cross the DMZ boundary.

Network Segmentation in Practice

Implementing the Purdue Model means creating physically or logically separate networks for each level:

  • Process Control Network (PCN): Levels 1-2. No internet access. Managed switches with VLAN segmentation. Only control traffic and operator workstation communication. Change management controls all additions to this network.
  • Operations Network: Level 3. Historian servers, MES, LIMS. Access controlled by AD domain separate from corporate IT. Firewalled from PCN.
  • DMZ: Data diodes or dual-homed firewalls for IT-OT data exchange. Patched and monitored like corporate servers.
  • Corporate Network: Level 4. Standard IT policy, internet access, cloud connectivity. No direct OT access.

Where the Purdue Model Falls Short

The Purdue Model was designed in the 1990s before cloud computing, IIoT, and remote access were common requirements. Its limitations are real and increasingly relevant:

  • Cloud connectivity breaks the hierarchy: IIoT platforms like AWS IoT, Azure IoT Hub, and Ignition Cloud need data from Level 2 or Level 3, bypassing Levels 4. Traditional Purdue routing has no clean way to handle this without punching holes through the DMZ.
  • Remote access is inherently outside the model: Vendors who need remote access to Level 1 controllers for maintenance do not fit neatly into the five-level hierarchy. Jump server architectures and zero-trust remote access solutions have emerged to address this gap.
  • IT/OT convergence creates shared services: Modern plants share Active Directory, patch management, and endpoint detection between IT and OT. These shared services exist at multiple levels simultaneously, which the original model does not accommodate.

Modern Alternatives and Evolutions

The IEC 62443 standard series has largely supplanted the Purdue Model as the design reference for industrial cybersecurity. IEC 62443-3-3 introduces the concept of Zones and Conduits: a Zone is a logical grouping of assets with similar security requirements; a Conduit is the communication path between zones, controlled by a security policy.

This Zones and Conduits model is more flexible than Purdue’s rigid hierarchy. A cloud-connected historian can be in its own Zone with conduits to both the Operations Zone and the cloud service provider, without forcing the connection to traverse every level of the Purdue stack.

In practice, most OT security programmes use the Purdue Model as a conceptual starting point and IEC 62443 as the technical design standard. The two are complementary: Purdue provides the mental model for conversations with operations teams; IEC 62443 provides the technical specification for security architects.

Practical Advice for Engineers

When designing or auditing an OT network, apply the Purdue Model as a checklist of questions: Can a device at Level 4 directly reach a Level 1 controller? If so, why, and what controls are in place? Is there a DMZ, or do IT and OT systems share a flat network? Are historian connections using a controlled interface, or is the OT network directly exposed to the corporate LAN?

Most real-world OT security incidents involve a violation of the Purdue Model boundaries — typically a flat network where Level 4 and Level 2 share connectivity, or a vendor VPN that bypasses the DMZ and terminates directly on the control network. The model’s enduring value is precisely as a checklist for these violations.