A recurring theme in OT security commentary is that the Purdue Enterprise Reference Architecture — the multi-level industrial zoning model that has anchored ICS security thinking since the 1990s — is obsolete. Cloud, IIoT, and flattened networks have supposedly made Purdue irrelevant.
We disagree. Not because Purdue perfectly describes any real facility — it never did — but because Purdue remains the clearest, most widely understood language we have for talking about industrial segmentation with auditors, operators, integrators, and insurers.
What Purdue actually is
The model, as codified in ISA-95 and extended in IEC 62443, defines a set of logical levels:
- Level 0: Physical process — the valves, motors, sensors
- Level 1: Basic control — PLCs, RTUs
- Level 2: Supervisory control — SCADA, HMIs
- Level 3: Operations management — MES, historians
- Level 3.5: The industrial DMZ
- Level 4/5: Enterprise — ERP, corporate IT
It is a logical model. It has never been strictly a physical topology. Flat networks that "violated" Purdue existed long before the cloud.
The "Purdue is dead" argument
Critics point out, reasonably, that modern architectures often have Level 1 devices directly reaching cloud services. Sensor telemetry bypasses the historian. Edge gateways federate across multiple sites. The neat hierarchical diagram does not describe reality.
True. But the critics conflate the model with the diagram. The model's real value is not the pretty layers — it is the separation of concerns between process control, supervision, operations management, and enterprise functions. That separation is more important than ever when any of those concerns can be addressed via cloud services.
Why we still use it
Four reasons:
- Auditors know it. PCI, SOC 2, IEC 62443, NIST SP 800-82 all refer to Purdue or Purdue-aligned zoning. If you need to explain your architecture to an assessor, Purdue is the vocabulary.
- Operators know it. Plant engineering and controls teams can talk about "Level 2" without a translation layer. That is worth a lot.
- It supports the right conversations. "Where does this flow go, and what zone is it in?" is the right question. Purdue gives us a way to ask it.
- It works as a target architecture. Starting from a bad flat network, the path to a defensible state is almost always expressible as "get closer to Purdue-aligned zoning, even if not perfectly hierarchical."
A modernized reading
The way we use Purdue in 2026 engagements:
- Use the levels as logical zones, not physical topologies.
- Accept that cloud-connected Level 1 devices exist — and design the conduits from Level 1 to cloud explicitly, as you would any other cross-zone flow.
- Treat the Level 3.5 industrial DMZ as a hard requirement, not a nice-to-have. This is where most facilities have the largest gap.
- Keep vendor remote access flowing through a jump host in the Level 3.5 zone, never directly into Level 1 or 2.
The bottom line
If a security consultant tells you Purdue is obsolete and wants to sell you a flat, cloud-native OT architecture, be skeptical. Not because Purdue is sacred — it isn't — but because the failure modes they are dismissing with hand-waving are the same failure modes that produce the majority of disclosed manufacturing ransomware events.
Segmentation is not a legacy concept. It is the concept. Purdue is just the shared vocabulary we use to talk about it.
This article was written by the Cascadia OT Security practice, which advises Pacific Northwest data centers and manufacturers on industrial cybersecurity. For engagement inquiries, reach our practice team.