What is the Purdue Model?
The Purdue Enterprise Reference Architecture, universally known as the Purdue model, is a framework for organizing the systems and networks of an industrial enterprise into functional levels. It originated from the Purdue University work that also informed the ISA-95 standard for enterprise and control system integration, and it was later adopted by ISA-99 and the IEC 62443 series as the conceptual reference for OT network segmentation.
Its enduring value is that it gives the entire industry a shared language. When an engineer refers to a Level 1 device or a Level 3.5 DMZ, colleagues across companies and sectors understand exactly what is meant. Three decades after its introduction, that common vocabulary remains one of the most useful contributions to industrial cybersecurity.
The question in 2026 is whether the model still describes how modern plants are actually built, because the way industrial data moves has changed significantly since the model was drawn.
The Levels of the Purdue Model
The model divides the industrial enterprise into levels, each representing a distinct function with its own trust characteristics.
| Level | Function | Typical systems |
|---|---|---|
| Level 0 | Physical process | Sensors, actuators, valves, motors, drives |
| Level 1 | Basic control | PLCs, RTUs, controllers, IEDs |
| Level 2 | Area supervisory control | HMIs, SCADA servers, engineering workstations |
| Level 3 | Site operations | Historians, MES, production and site-wide control |
| Level 3.5 | Industrial DMZ | Jump servers, historian replicas, patch and antivirus relays, file brokers |
| Levels 4 and 5 | Enterprise IT | ERP, business systems, corporate network, internet |
The lower levels sit closest to the physical process and carry the highest consequence, since a compromise there can directly affect equipment and safety. The upper levels handle business functions and carry different risks. The Level 3.5 industrial DMZ is a particularly important concept: it is the controlled boundary through which all communication between the enterprise and the plant is brokered, so that IT and OT never connect directly.
The Security Principles Behind the Model
The layers themselves are less important than the security logic they express. Three principles sit at the heart of the model and remain fully valid.
Control communication between levels. Traffic should not flow freely across the architecture. Each boundary is a point where communication is filtered, monitored, and constrained to what is genuinely required.
Protect the process most. The systems closest to the physical process deserve the strongest protection, because they are the ones that can move a valve, trip a line, or affect a safety function. Security investment should be weighted toward the lower levels.
Broker the enterprise boundary. The plant floor and the corporate network should never communicate directly. All such traffic passes through the industrial DMZ, where it can be inspected and controlled.
The Colonial Pipeline shutdown of 2021 illustrated the value of the third principle. The attack affected the company's business systems rather than its pipeline controls, but because the boundary between IT and OT was not clearly defined, the operator could not confirm the control systems were unaffected and made the prudent decision to pause operations until it could. A clearly enforced boundary is not bureaucratic overhead; it is what allows an operator to reason confidently about the state of the plant during an incident.
Where Modern Architecture Challenges the Model
The strain on the model comes from connectivity that no longer runs in straight vertical lines.
Cloud connectivity. OT data increasingly flows to cloud historians, analytics platforms, and digital twins. This data leaves the plant entirely along a path that runs outward, not up through Level 4 as the model envisions.
Edge computing and modern data flows. Newer architectures using report-by-exception messaging and unified namespace designs allow a device near the process to publish its data to a shared broker that both the plant and the cloud can subscribe to. This is efficient and widely adopted, and it does not follow the layer-by-layer chain the model assumes.
Remote operations and access. Engineers, integrators, and vendors reach supervisory and site systems from outside the facility. These pathways are essential and constant, and the classic model has no dedicated place for them.
IIoT and direct-to-cloud sensors. Modern instrumentation often communicates upward directly, sometimes over cellular networks, bringing the separation between the process level and the upper tiers closer together.
Virtualization and convergence. Software-defined networking, virtualized control systems, and converged IT and OT data centers make it harder to point to a physical layer and say where a workload resides.
The common thread is that connectivity has become multidimensional. Data now moves up, down, sideways, and out to third parties, and a model drawn as horizontal layers cannot represent all of that on its own.
From Levels to Zones and Conduits
The response to this challenge is not to abandon segmentation but to express it with a more flexible tool: the zone and conduit model of IEC 62443-3-2, which extends the Purdue model rather than replacing it.
Zones group assets by security requirement, not by level. A zone is a collection of assets that share the same protection needs. A safety instrumented system and a general HMI might sit at similar Purdue levels yet belong in different zones because the consequence of their compromise differs sharply. Each zone is assigned a target Security Level, from SL 1 to SL 4 under IEC 62443-3-3, which determines the strength of the controls applied to it.
Conduits are the controlled pathways between zones. Every communication path between zones is a conduit that must be identified, justified, and secured. This is the mechanism that brings the modern flows the Purdue model struggles with, cloud replication, remote access, edge messaging, onto the architecture where they can be governed. If a connection exists, it is a conduit, and it is controlled.
Firewall and access rules derive from the conduit definitions, so that controls trace back to a deliberate design rather than to years of accumulated exceptions.
In practice, the two models work together. The Purdue model provides the familiar grouping that every engineer understands, and the zone and conduit overlay refines it by consequence and accounts for every real pathway. In Beacon Security's experience, the strongest OT architectures use the Purdue model as the shared language and IEC 62443 zones and conduits as the actual control boundary.
Modernizing Your Architecture
Operators do not need to discard existing designs. A practical evolution looks like this:
- Keep the Purdue levels as reference language. They remain the fastest way to communicate roughly where a system belongs.
- Preserve and strengthen the Level 3.5 DMZ. Keep all IT to OT communication brokered through the DMZ, and treat it as a critical asset in its own right.
- Redraw segmentation as zones by consequence. Group assets by the impact of their compromise and assign each a target Security Level.
- Inventory every conduit, including the less obvious ones. Cloud links, remote access, and edge data flows must all appear on the architecture.
- Derive controls from the model. Firewall policy and access decisions should trace to the documented zones and conduits.
- Treat the architecture as living. Every new cloud service, broker, vendor connection, or sensor is a change to the zone and conduit model and should be reviewed under management of change.
The Verdict
The Purdue model in 2026 is neither obsolete nor sufficient on its own. Its layered picture no longer captures every dimension of modern connectivity, and applying it too rigidly can leave real pathways unaddressed. But the principles it established, controlling communication between levels, protecting the process most, and brokering the enterprise boundary, are exactly what secure OT architecture still requires. Abandoning them for a flat network is a far greater risk than retaining a model that needs updating.
Used as a shared reference, with IEC 62443 zones and conduits performing the detailed work of segmentation, the Purdue model remains one of the most useful ideas in industrial cybersecurity. It has not been replaced. It has been extended to match the way modern plants are actually built.
Beacon Security designs and validates OT network architectures that pair the familiarity of the Purdue model with the rigor of IEC 62443 zones and conduits. Contact us to review your segmentation and build a defensible industrial network design.
