The short answer
The Purdue Model
The Purdue Enterprise Reference Architecture organizes industrial systems into levels, from field devices at Level 0 up through control, supervisory, site operations, and enterprise networks. Its practical value is that it defines where boundaries belong, particularly the demilitarized zone between operations and enterprise networks, which is the single most important segmentation boundary in most industrial sites.
Key points
- Levels 0 to 3 are the control environment; Levels 4 and 5 are enterprise.
- The DMZ between Level 3 and Level 4 is where data is exchanged without direct connection.
- No enterprise host should ever connect straight to a controller.
- Modern architectures diverge from strict layering, but the boundaries still apply.
- A remote lift station is a small control zone, not an exception to the model.
The levels
| Level | Contains | Water utility example |
|---|---|---|
| 0 — Process | Sensors, actuators, motors, valves | Level transmitter, pump motor, valve actuator |
| 1 — Basic control | PLCs, RTUs, safety controllers | Lift station PLC, plant controller |
| 2 — Supervisory | HMI, local SCADA, engineering workstations | Plant operator workstation, local HMI panel |
| 3 — Site operations | Historian, SCADA servers, domain services for OT | SCADA server pair, historian, OT domain controller |
| 3.5 — DMZ | Brokered data exchange, jump hosts, patch staging | Read-only historian replica, remote access broker |
| 4 — Site business | Plant business systems, email, file shares | Utility billing, work order system |
| 5 — Enterprise | Corporate IT, internet-facing services | City network, public web presence |
Why the DMZ is the important part
Business users legitimately need process data. Operations legitimately needs to keep the control network isolated. The DMZ resolves this by giving both sides a place to meet without either crossing into the other.
A historian replica in the DMZ receives data pushed from the OT historian at Level 3. Business users query the replica. No enterprise host ever initiates a connection into the control network, and no control device is reachable from Level 4. If the replica is compromised, the attacker has a copy of process history rather than a path to a controller.
Where real systems diverge
The model was written before cloud services, remote telemetry over cellular, and vendors who expect outbound connections from their equipment. Strict layer-by-layer traversal is not how modern systems are built, and pretending otherwise leads to architectures that get bypassed in practice.
- A remote lift station is its own small zone at Levels 0 through 2, connecting back to Level 3 over a controlled path. It is not a violation of the model, it is an instance of it.
- Cellular-connected RTUs need a defined, encrypted, authenticated path to the SCADA system, terminating at a boundary you control rather than at a controller.
- Cloud historians and vendor telemetry belong at the DMZ or above, fed by a push from inside, never by opening an inbound path.
- Wireless of any kind is a boundary crossing and needs the same scrutiny as a firewall rule.
Applying it to a utility with many remote sites
A collection system with eighty lift stations does not have one flat network with eighty controllers on it, or at least it should not.
- 01Treat each remote site as a zone with a defined conduit back to the plant, in the ISA/IEC 62443 sense.
- 02Terminate remote connections at a boundary device at the plant, not directly on the SCADA server and never on a controller.
- 03Restrict each site to the protocols and destinations it actually needs. A lift station RTU has no reason to reach anything but the SCADA front end.
- 04Prevent site-to-site communication entirely unless a specific requirement exists. One compromised station should not reach the other seventy-nine.
- 05Log and monitor the conduits. A station suddenly talking to something new is a signal worth having.
Frequently asked questions
- Is the Purdue model outdated?
- The strict hierarchy is dated; the boundaries it identifies are not. Most current guidance still starts from these levels and then adapts for cloud, remote sites, and vendor connectivity. It remains the most widely shared vocabulary for discussing industrial network architecture.
- Do I need a DMZ for a small utility?
- You need the boundary. It may be a single firewall with a small DMZ segment holding one replica server rather than a large architecture. The principle that no business host connects directly to a control device applies at every size.
- What is Level 3.5?
- A commonly used informal name for the DMZ between site operations and business networks. It is not part of the original model but it is universally understood in industrial security discussions.
- How does this relate to ISA/IEC 62443?
- IEC 62443 uses zones and conduits, which is a more flexible way of expressing the same idea: group assets with similar security requirements into zones, and control every communication path between zones. The Purdue levels are a common starting point for defining those zones.
Related topics
- Zones and ConduitsThe IEC 62443 way to segment a control system: grouping assets into zones with a shared security level, inventorying every conduit between them, and turning the drawing into firewall rules. With a worked water utility example.
- Industrial DMZ DesignThe buffer zone between the business network and the control system: what goes in it, the no-direct-path rule, push-not-pull data flows, the firewall pair, and the services a utility actually needs to place there.
- IEC 62443The international standard series for industrial automation and control system security: how it is organized, what security levels and foundational requirements mean, and how a utility or integrator actually uses it.
- Water and Wastewater Utility Threat LandscapeWhat has actually happened at water utilities, what those incidents had in common, and the small number of controls that would have prevented most of them.
- OT Security vs IT SecurityWhy the familiar security priorities invert on a plant floor, and what that changes about patching, scanning, authentication, and incident response.
- OT Risk AssessmentRanking what could go wrong in a control system and what it would cost: the consequence-first method for utilities, the assets and scenarios to list, likelihood without pretending to know it, the risk matrix, and turning the ranked list into a work plan.
Direct contact
Have a controls question?
Reach Eric Sullivan directly about anything on this site, a controls or automation topic, or one of his personal projects.