What Is the Purdue Model?

Back to Blog

The Levels of the Purdue Model

The Purdue model runs from Level 0 to Level 5. Level 0 is the process - the physical equipment being controlled. Level 1 holds basic control: PLCs, RTUs, and controllers. Level 2 is area supervisory control, including HMIs and local SCADA. Level 3 is site operations - historians, production management, and engineering workstations. Above that sits Level 4 (site business systems) and Level 5 (enterprise IT), which together form the corporate IT domain.

A defining feature is the industrial demilitarized zone (IDMZ) placed between Levels 3 and 4. It acts as a controlled buffer so that OT systems below never talk directly to IT systems above. Data crossing that boundary is brokered through the DMZ, which is why historians, patch servers, and remote-access jump hosts often live there.

Why the Purdue Model Still Shapes OT Design

The model was created for discrete manufacturing decades ago, and modern realities - cloud services, IIoT sensors, and remote monitoring - do not always map cleanly onto its rigid layers. Cloud SCADA, for example, deliberately moves some functions off-site, which challenges the assumption that Level 3 lives on-premise. Many teams now treat Purdue as a conceptual guide rather than a strict wiring diagram.

Even so, its core principle endures: segment the network, control every boundary crossing, and never let enterprise traffic reach controllers directly. That discipline underpins most OT security programs. A cloud platform that respects these boundaries typically collects data through an edge gateway or DMZ broker rather than exposing controllers, which is how Merobix connects to field devices while keeping the control layer isolated.

Mapping a Remote Site to the Levels

The model reads naturally at a plant, but a remote oil and gas site compresses it. At a wellsite, the transmitters and wellhead hardware are Level 0; the RTU or PLC running local control is Level 1; a local display, where one exists, is Level 2. There is usually no Level 3 on site at all - site operations functions such as the historian and operator consoles live at a regional office or in a hosted environment, reached over a cellular or satellite WAN. The model still applies; the boundaries just fall on different hardware than in a plant.

The WAN link is the boundary that deserves the most design attention, because the public carrier network is not a Purdue level - it is untrusted transport that happens to sit between your Level 1 and your Level 3. The standard treatment is to make the boundary explicit: the site's gateway initiates an outbound, authenticated connection - typically a VPN tunnel - and nothing upstream can open a connection into the site. That one rule preserves the model's core discipline even when the network diagram includes a carrier you do not control.

Traffic Rules the Model Implies

The levels earn their keep as a set of traffic rules. Flows should cross one boundary at a time: Level 1 talks to Level 2, Level 2 to Level 3, Level 3 to the DMZ, and the DMZ to Level 4 - never Level 4 directly to Level 1. Each crossing is a place to enforce policy: which protocol, which endpoints, initiated from which side. The strictest version adds a protocol break at the DMZ - data arrives in one protocol, is stored, and leaves in another - so no single session ever spans from enterprise to control.

Direction of initiation matters as much as the path. The resilient pattern is data flowing up via connections initiated from below: the control side pushes to the DMZ broker, the enterprise side pulls from it, and neither side holds an open door into the other. Remote engineering access inverts the data flow but keeps the discipline - a user lands on a hardened intermediary in the DMZ under its own authentication and audit trail, rather than connecting straight through to a controller.

Auditing an Existing Network Against the Model

The model is most useful as an audit lens for a network that grew organically:

1. Inventory every device and assign it a level - the arguments this provokes are the audit working as intended.
2. Map every traffic flow: source, destination, protocol, and which side initiates.
3. Flag every flow that skips a level, especially anything reaching Level 1 or Level 2 from outside the OT zone.
4. Flag every inbound-initiated connection into OT, and every path that bypasses the DMZ.
5. For each violation, either re-architect the flow or document it as an accepted exception with compensating controls.
6. Repeat after every project, because new integrations are where clean architectures decay - and have the result reviewed by qualified security personnel rather than treated as a desk exercise.

What the Model Does and Does Not Give You

Purdue is a reference architecture, not a security standard - it tells you where boundaries belong, not how strong each one must be. Security programs layer zone-and-conduit thinking, requirements, and assessment regimes on top of the segmentation Purdue sketches; the model is the floor plan, not the locks. Similarly, the levels are logical roles, not necessarily separate switches: whether a boundary is enforced by physical separation, VLANs and firewalls, or something stronger is a site-specific engineering decision the model itself does not settle.

It also does not decide organizational questions - who owns the DMZ, who approves a new flow, how exceptions get reviewed - even though those decisions determine whether the architecture survives contact with real projects. Pairing the network levels with the functional decomposition of ISA-95 helps here, because it attaches responsibilities and interfaces to the same layer boundaries the network drawing shows.

Frequently Asked Questions