A Thirty-Year-Old Model in a Cloud-Connected World
Ask any OT engineer to sketch an industrial network and they will almost certainly draw horizontal layers stacked from the plant floor up to the enterprise. That mental model is the Purdue Enterprise Reference Architecture, and it has shaped how the industry thinks about control system design for three decades. It remains the single most common vocabulary for discussing where a device belongs and how data should flow.
Yet the world the Purdue model was built for no longer exists in pure form. Historians replicate to the cloud, engineers connect from home, IIoT sensors report directly to analytics platforms, and vendors reach into equipment for remote support. Each of these crosses the neat horizontal lines the model draws. The reasonable question, asked more and more in 2026, is whether the Purdue model is still relevant or whether it has become a comforting diagram that no longer matches reality.
The answer is nuanced. The model's layers are strained, but the thinking behind it is more important than ever. What has to change is how we apply it.
What the Purdue Model Actually Says
At its core, the model divides an industrial enterprise into levels, each representing a functional tier with different purposes and trust characteristics.
| Level | Function | Typical systems |
|---|---|---|
| Level 0 | Physical process | Sensors, actuators, valves, motors |
| Level 1 | Basic control | PLCs, RTUs, controllers |
| Level 2 | Area supervisory control | HMIs, SCADA servers, engineering workstations |
| Level 3 | Site operations | Historians, production management, site-wide control |
| Level 3.5 | Industrial DMZ | Jump servers, patch and antivirus relays, data brokers |
| Level 4 and 5 | Enterprise IT | Business systems, ERP, corporate network, internet |
The security value of this structure is not the layering for its own sake. It is the principle that traffic between levels should be controlled, that the lower levels closest to the physical process deserve the strongest protection, and that a demilitarized zone at Level 3.5 should broker all communication between the plant and the enterprise so that IT and OT never talk directly. Those principles remain sound.
Where the Model Strains in 2026
The pressure on the model comes from architectures that simply do not fit a strict vertical stack.
- Cloud connectivity: sending OT data to cloud historians, analytics, and digital twins creates flows that leave the plant entirely, bypassing the tidy Level 4 boundary the model imagines as the top of the stack.
- Remote operations and access: engineers, integrators, and vendors reach into Level 2 and Level 3 systems from outside the facility, creating pathways the original model never accounted for.
- IIoT and edge devices: modern sensors often communicate upward directly, sometimes over cellular or straight to a cloud platform, collapsing the careful separation between Level 0 and the upper tiers.
- Converged and virtualized infrastructure: shared virtualization, software-defined networking, and combined IT and OT data centers make it harder to point at a physical layer and say where a system lives.
The common thread is that connectivity has become multidimensional. Data no longer moves only up and down a stack. It moves outward, sideways, and to third parties. A model drawn as horizontal layers cannot fully capture that.
The Wrong Conclusion and the Right One
Faced with this strain, some conclude that the Purdue model is obsolete and should be discarded. That is the wrong conclusion, and acting on it usually produces flat, poorly segmented networks justified by the claim that layering is outdated.
The right conclusion is that the model's layers are a starting point, not a straitjacket. The underlying goals, which are controlling communication between trust levels, protecting the systems closest to the physical process most strongly, and brokering external connectivity through a controlled boundary, are exactly what modern threats demand. What needs updating is the mechanism used to express those goals. That mechanism is the zone and conduit model from IEC 62443.
From Levels to Zones and Conduits
IEC 62443 reframes segmentation in a way that survives the messiness of modern architectures. Instead of fixed horizontal levels, it groups assets into zones based on shared security requirements, and defines conduits as the controlled pathways between them. This shift is subtle but powerful.
- A zone is defined by the security level its assets require, not by which floor of the Purdue diagram they sit on. A safety instrumented system and a general HMI can live at similar Purdue levels yet belong in very different zones because their consequence and trust profiles differ.
- A conduit explicitly documents every pathway between zones, including the ones the Purdue model struggles with: a cloud replication link, a vendor remote access path, an IIoT data flow. If a communication exists, it is a conduit, and it must be identified, justified, and controlled.
- Security levels assigned to each zone drive the strength of the controls on its conduits, giving a defensible basis for firewall rules and access decisions.
In practice, the Purdue model and the zone and conduit model work together. The Purdue levels give a familiar first-pass grouping that engineers already understand. The zone and conduit overlay then refines that grouping by consequence and adds explicit accounting for every real pathway, including the modern flows that break the pure stack. In Beacon Security's experience, the strongest OT architectures use Purdue as the shared language and IEC 62443 zones as the actual control boundary.
Modernizing Your Architecture Without Starting Over
Operators do not need to abandon existing designs. A practical evolution looks like this:
- Keep the Purdue levels as your reference language. They remain the fastest way to communicate roughly where a system belongs, and everyone in the room understands them.
- Preserve the industrial DMZ at Level 3.5. This remains one of the most valuable ideas in the entire model. No direct IT to OT communication, ever. All brokered through the DMZ.
- Redraw your segmentation as zones based on consequence, not just level. Group by how much damage a compromise would do, and assign each zone a target security level.
- Inventory every conduit, including the uncomfortable ones. Cloud links, remote access, and IIoT flows must appear on the diagram. A pathway you do not document is one you cannot control.
- Derive firewall and access rules from the conduit definitions, so your controls trace back to a deliberate architecture rather than years of accumulated ad hoc exceptions.
- Treat the architecture as living. Every new cloud service, vendor connection, or sensor deployment is a change to the zone and conduit model and should be reviewed as one.
The Verdict
The Purdue model in 2026 is neither dead nor sufficient on its own. Its layered picture no longer captures the outward and sideways connectivity of modern industrial operations, and treating it as a rigid rule leads to designs that ignore real risk. But the principles it established, which are trust-based separation, strongest protection nearest the process, and a controlled boundary to the enterprise, are precisely what secure OT architecture still requires.
The model earns its continued relevance by evolving into the role of a shared reference, with IEC 62443 zones and conduits doing the work of actual segmentation. Used that way, it remains one of the most useful ideas in industrial cybersecurity, thirty years on.
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.
