What is the Purdue model? A plain explanation for OT networks
The Purdue model is the diagram that turns up early in most OT security conversations. It sorts an industrial network into levels, from the sensors and valves that touch the process up to the corporate IT network. Everyone gets a shared way to say where a system sits and what’s allowed to talk to it.
Where it comes from
Theodore J. Williams and the Industry-Purdue University Consortium for Computer Integrated Manufacturing developed the Purdue Reference Model, and ISA first published it in 1989. Its job was to describe how manufacturing and business systems fit together. Security wasn’t the point. ISA-95, the standard for connecting enterprise and control systems, builds on the same hierarchy, and OT security practice borrowed the levels later as a map of the network.
The levels
| Level | What lives there | Pipeline example |
|---|---|---|
| 0 | The physical process: sensors, valves, pumps, actuators | Pressure transmitters, valve actuators, compressor drives |
| 1 | Basic control: PLCs, RTUs and other controllers | RTUs at field sites, PLCs at a compressor station |
| 2 | Area supervision: HMIs and local operator stations | A station HMI showing local alarms and setpoints |
| 3 | Site or control center operations: SCADA servers, historians, engineering workstations | The control center SCADA servers and the historian |
| 3.5 | The industrial DMZ between OT and business networks | A historian replica, a patch server, a remote access jump host |
| 4 | Business logistics systems | Scheduling, accounting and reporting systems |
| 5 | The enterprise network | Corporate IT, email, internet access |
Level 3.5 isn’t one of the original levels. It’s a convention from OT security practice, and the PERA reference site describes extra DMZ zones like it for plant and office firewalls. People draw it because the boundary between OT and business systems needs somewhere to live. Sources disagree on where some systems belong, so read the table as a common version of the model, not the only one.
The rule the model encodes
Traffic moves between neighboring levels, through defined points. The business network gets no direct path to the control levels.
When data has to cross, it crosses at the DMZ. A historian replica in the DMZ serves the corporate reporting system, so the corporate side never connects to the real historian, and vendor remote access ends at a jump host in the DMZ instead of at a controller.
The useful questions are about connections that skip levels. A corporate workstation that reaches a Level 2 HMI directly is one. A dual-homed engineering workstation sitting on both the business network and the control network is another. The model says neither path should exist.
Where the model stops fitting
The model assumes a tidy hierarchy. Real networks drift from it:
- Many networks started flat and were segmented later, so a level boundary exists on the diagram but not in the firewall rules.
- Vendor remote access, cellular modems at remote sites and cloud-connected sensors can reach into the control levels without passing through the DMZ.
- A pipeline with RTUs spread across hundreds of miles of radio and cellular links doesn’t sort neatly into a plant floor and a control room.
- A gateway, or a historian with two network cards, can sit in two levels at once.
NIST SP 800-82r3 draws the Purdue model next to an IIoT model in its network segmentation figure, so the two now get read together. A map is only as good as its match to the ground. To check this one, compare the diagram against the firewall rules and against the traffic that crosses each boundary. How to verify IT/OT segmentation in operational networks walks through that comparison.
How it relates to IEC 62443
IEC 62443 describes segmentation with zones and conduits, not levels. A zone groups assets that share security requirements. A conduit is a defined path between zones. Purdue levels make a handy starting point for the first zones, but a zone follows shared requirements and not a level number. What is IEC 62443? covers the standard in more detail.
What to do with it
Use the model as a vocabulary and a first-pass diagram. Place each asset in a level and list every connection that skips one. Then ask which of those connections has a reason to exist. For a target architecture drawn end to end, see the IT/OT segmentation reference architecture. To see where a program stands against the TSA directives, take the Readiness Check.
Sources: The Purdue Reference Model, PERA.net, including the origin, the level structure and the Level 3.5 DMZ note. NIST SP 800-82r3, Guide to Operational Technology (OT) Security, September 2023, for the Purdue model and IIoT model segmentation figure.