Purdue Model
The Purdue Enterprise Reference Architecture (PERA) — a 1990s layered diagram of the manufacturing plant that became the dominant mental model for IT/OT segregation. Levels 0-4, plus the post-hoc Level 3.5 industrial DMZ.
Also: PERA, Purdue Reference Model, Purdue Levels
The Purdue Model is the layered reference architecture for manufacturing plants published by Theodore J. Williams of Purdue University in the early 1990s as part of the Purdue Enterprise Reference Architecture (PERA). The bit that survived in industrial-cyber language is the layer diagram — Levels 0 through 4, from physical instrumentation at the bottom to corporate IT at the top.
The layers
| Level | What lives here |
|---|---|
| Level 0 | The physical process — actual valves, motors, sensors, switchgear, primary plant. |
| Level 1 | Basic control — PLCs, protection IEDs, the things that read sensors and drive actuators. |
| Level 2 | Local supervision — local SCADA, HMIs, area control. |
| Level 3 | Plant-wide systems — historian, MES, plant-level engineering. |
| Level 3.5 | Industrial DMZ — a post-hoc level inserted to give a place to put the historian replicas, jump hosts, and OT-IT brokering. |
| Level 4 | Corporate IT — ERP, business intelligence, the enterprise network. |
Level 3.5 is not in Williams’s original PERA. It was added in the early 2000s once it became clear that Levels 3 and 4 were going to talk to each other and the conversation needed somewhere to happen safely.
Why the model lasted
The diagram caught on not because the layering was novel — IT/OT diagrams have always been drawn that way — but because the gaps between the layers were assumed to be physical. Level 4 was Ethernet/TCP. Levels 0-3 were serial fieldbuses and proprietary protocols. The boundary was a transceiver mismatch, not a firewall rule. Plant managers could point at the diagram and say “the air gap is between Level 3 and Level 4” and mean it.
That assumption held for about a decade. By the early 2000s OPC Classic and Windows-based historians had punched a hole through it; by the late 2010s virtualisation had dissolved most of the physical layering entirely.
Where the Purdue Model breaks in modern substations
The substation-and-control-centre context the corpus describes has multiple Purdue violations baked in:
- Virtualised RTUs are nominally Level 2 supervisors, but they run on the same hypervisor cluster as ADMS / EMS (Level 3 / 3.5). The “level” boundary is now a hypervisor segmentation rule, not a separate piece of hardware.
- Cloud-hosted historians put what was Level 3 functionally into infrastructure that doesn’t fit any Purdue level at all.
- Vendor remote-support tunnels cut across every level when used.
- Engineering laptops carry credentials and configuration across Level 1 / 2 / 3 / 3.5 in a single shift.
The model isn’t wrong — it’s still a reasonable mental scaffold for “where does this asset functionally sit?” — but it isn’t enforceable. That’s the gap IEC 62443 zone-and-conduit thinking is designed to fill: zones are defined by the security requirement, not by the Purdue level, and the boundary is a contract rather than a wire.
How the model relates to 62443
A common modernisation pattern is to take the Purdue diagram as the starting sketch and re-partition it under 62443:
- A Purdue Level 1 protection IED becomes part of a Z-PROC zone.
- A Level 2 station HMI becomes part of a Z-STN zone.
- A Level 3 historian becomes part of a Z-OPS zone.
- A Level 3.5 IDMZ becomes a Z-IDMZ zone (with an explicit conduit catalogue rather than the implied “anything goes” of a DMZ).
- A Level 4 corporate environment is out of scope for the OT design.
The zones don’t have to follow the Purdue levels — but in practice they often do, because the trust boundaries and the functional levels tend to coincide in well-designed systems.