The Purdue Model is still the right map. It stopped matching the territory.
Every OT security conversation starts with the five-level hierarchy, and almost every real plant has traffic that walks straight through it. This guide covers what the levels are, what remote access, IIoT and cloud analytics did to them, and what to enforce instead when redrawing the network is not on the table.
Last updated:
What is the Purdue Model?
The Purdue Model, formally the Purdue Enterprise Reference Architecture (PERA), organises an industrial control system into levels, from the physical process at Level 0 up to enterprise IT at Levels 4 and 5, with an Industrial DMZ at Level 3.5 as the boundary between operations and the business. It was written in the 1990s at Purdue University as a model for manufacturing integration, not as a security control. The security use came later, and it rests on one assumption: that traffic moves vertically, level by level, and that each boundary is a place you can inspect it.
That assumption is what has failed. The levels are still an excellent shared vocabulary, and it is worth keeping them for that reason alone. What no longer holds is the idea that the diagram describes how packets actually move through a modern plant.
The Purdue Model levels, and what lives at each one
Six tiers, counting the DMZ. The numbering runs from the physical process upward, which is the opposite of how most network diagrams are drawn, and is a common source of confusion.
| Level | Name | What lives there | If it is compromised |
|---|---|---|---|
| Level 5 | Enterprise | Corporate IT, ERP, email, the wider business network. | Business disruption, and a foothold with a path toward operations. |
| Level 4 | Site business | Plant scheduling, logistics, site IT services. | Production planning is exposed and the attacker is one hop from the DMZ. |
| Level 3.5 | Industrial DMZ | The IT/OT boundary: jump hosts, patch servers, data brokers, replicated historians. | The whole point of the model is lost. Both sides are exposed at once. |
| Level 3 | Site operations | Plant-wide control, historians, engineering workstations, MES. | Recipes and control logic are reachable, and engineering tools can write downward. |
| Level 2 | Supervisory control | SCADA, HMIs, DCS operator stations. | Operators can be shown one thing while another happens on the process. |
| Level 1 | Basic control | PLCs, RTUs, drives, safety controllers. | Control logic can be altered. This is where physical consequences begin. |
| Level 0 | Physical process | Sensors, actuators, valves, motors. | The process itself. Damage here is measured in equipment and safety, not data. |
Level 3.5 is the one people argue about. It is not in the original PERA at all; it was added by the security community precisely because the model had no answer for the IT/OT boundary. That is worth remembering when the DMZ is treated as the model's central idea.
Three things that walk straight through the hierarchy
None of these are attacks. They are ordinary, sanctioned, business-approved connections, which is exactly why they are hard to argue with and why they are still there.
Remote access collapses the stack into one hop
A vendor VPN terminates near the enterprise edge and reaches a jump host that can talk to controllers. On the whiteboard that path crosses five boundaries. On the wire it is a single hop, and one credential is the whole distance. The separation exists in the drawing, not in the routing table.
IIoT sends telemetry sideways, out of the building
An edge gateway at the process layer publishes straight to a cloud endpoint. It never touches Levels 1, 2 or 3, so no boundary inspects it, and the return path is an unmonitored way in that sits below everything the DMZ can see.
Cloud analytics erase the line between Level 3 and Level 4
Once a historian replicates to a cloud dashboard, the distinction between site operations and the business is a licensing arrangement, not a network control. A compromised cloud tenant reaches plant data that two firewalls were supposed to be standing in front of.
Why the Industrial DMZ concentrates risk instead of reducing it
The model's answer to the IT/OT boundary is one shared, heavily defended crossing. That made sense when crossings were rare. It scales badly when everything needs to cross.
One breach exposes both sides
Every asset that matters is either in front of the DMZ or behind it. There is no third position. Compromise the crossing and you have compromised the arrangement, not one host.
Every unlike thing shares one chokepoint
Vendor sessions, telemetry, patch distribution and historian replication all funnel through the same boundary with the same posture, because there is only one boundary to give them.
Visibility stops at the crossing
The DMZ can log that a connection was allowed. What that connection then does, east to west, across a flat plant network, is not something a boundary control is positioned to see.
Change lags operations by weeks
Every new integration is a firewall rule request. The rules accumulate, nobody removes the old ones, and the effective policy drifts away from the documented one.
Where auditors ask for something the model cannot produce
This is often what forces the conversation. The frameworks moved toward per-asset, per-identity evidence, and a level boundary does not generate it.
IEC 62443 zones and conduits
62443 asks you to define zones by risk and the conduits between them, then enforce and document both. Purdue levels are a starting point for zones, but they are not the same thing, and grouping an entire level into one zone is usually indefensible on risk grounds.
NIST SP 800-82r3
The current revision moved away from presenting Purdue as the reference architecture and toward zone-based segmentation and Zero Trust. Citing Purdue as your architecture no longer maps cleanly onto the guidance.
NERC CIP-005
The electronic security perimeter has to be enumerated, and every access path through it accounted for. Vendor tunnels that bypass the hierarchy are exactly what the standard wants listed, and they are the ones least likely to be in the diagram.
CMMC and NIST SP 800-171
Least privilege is required per system, with an audit trail per access. Coarse segmentation that puts dozens of assets in one trust zone cannot show who reached which asset, only that something reached the zone.
What to use instead, honestly compared
Nothing here replaces the Purdue Model as a vocabulary. What follows replaces it as an enforcement strategy, which is the job it was never designed to do.
| Approach | What it changes | What it costs you |
|---|---|---|
| Zone and conduit (IEC 62443) | Zones are drawn by risk rather than by function, and every conduit between them is explicit and documented. | A real risk assessment, and the political work of agreeing zones across operations and IT. |
| Microsegmentation | The blast radius becomes one asset or a small group, rather than a whole level. | Traditionally a VLAN and routing redesign, which is why it stalls on brownfield plants. |
| Zero Trust for OT | Identity and policy are checked on every session, not inferred from which subnet the packet came from. | An identity layer that OT networks generally do not have, and somewhere to enforce it. |
| Software-defined networking | Policy is centrally defined and pushed, so configuration drift stops accumulating. | New infrastructure and a new operational skill set, usually a greenfield-only option. |
| Keep Purdue, add enforcement | The levels stay as the shared language; the actual control moves to a per-asset boundary. | Least disruptive, but only works if the enforcement point can front assets you cannot modify. |
Per-asset boundaries without redrawing the network
Most of the options above assume you can restructure the network. On a running plant with equipment that cannot be patched, taken offline or re-addressed, that assumption is usually where the project dies. The alternative is to leave the topology alone and put the boundary in front of the assets that matter, one at a time.
It joins the network you already have
The appliance connects to the existing network rather than cutting into it, so day one is low impact. You then steer the flows you want protected through it, asset by asset, and nothing moves until you move it.
A boundary per asset, not per level
Each protected asset sits behind its own enforced boundary. Reaching one grants nothing toward the next, so the lateral movement the DMZ could never see has nowhere to go.
Identity on the session, not the subnet
Every connection is tied to a named identity, a specific asset and a protocol, with a time bound. That is the per-asset evidence CIP-005, CMMC and 62443 ask for, produced by operations rather than by a separate audit project.
It works on equipment that cannot change
The asset keeps its IP, its firmware and its configuration. A controller from two decades ago gets the same enforced boundary as a current engineering workstation, because nothing is asked of the controller.
How to move without a forklift upgrade
None of this requires abandoning the model or rebuilding the network. It requires finding out where the drawing and the plant disagree, then closing the gaps in priority order.
- 01
Map the traffic you actually have, not the traffic the diagram implies. Every VPN, every edge gateway, every cloud replication job. The gaps between the two documents are the finding.
- 02
Rank assets by consequence rather than by level. A safety controller and a lighting PLC sit at the same level and are not the same problem.
- 03
Put a boundary in front of the highest-consequence assets first, and prove the pattern on a handful before committing to a rollout.
- 04
Replace shared tunnels with named, scoped, time-bounded access. One vendor credential that opens a whole network is the single largest gap in most estates.
- 05
Log at the boundary you created, not only at the plant edge, and baseline what normal looks like per asset so the abnormal is visible.
- 06
Keep the Purdue levels in your documentation and your conversations. Losing the shared vocabulary costs more than it saves.
Take the full analysis with you.
The long-form version: how the hierarchy erodes in practice, why the Industrial DMZ concentrates the risk it was meant to reduce, and the per-asset architecture that replaces it.
12 pages
What you will learn
Where the five levels stop describing real traffic, and which of the three bypasses is usually present first on a brownfield plant.
The per-asset architecture
How asset-level boundaries are deployed incrementally against equipment that cannot be patched, re-addressed or taken offline.
See what your hierarchy looks like on the wire
If your Purdue diagram and your actual traffic have drifted apart, we can walk through where the bypasses are on your network and what fronting the critical assets would take.
OT network security
How zone architecture gets imposed across sites without a VLAN redesign.
See the solutionWalk through your own topology
A review against your estate: where traffic bypasses the hierarchy, which assets are exposed, and what enforcement would look like.
Purdue Model questions
The Industrial DMZ level, which does not appear in the original Purdue Enterprise Reference Architecture. It was added later by the security community.
As a security architecture, largely yes. As a shared vocabulary for describing an industrial estate, no, and it is still the most useful one available. The distinction matters: the levels remain a good way to explain where a system sits, but the assumption underneath the security use, that traffic crosses levels in order and can be inspected at each boundary, is no longer true in a plant with vendor remote access, IIoT gateways and cloud replication. Keep the levels for describing. Do not rely on them for enforcing.
The Purdue Model is a descriptive hierarchy of functional levels. IEC 62443 is a standard that asks you to define zones by risk, define the conduits between them, and apply and document security requirements for each. Purdue levels are often used as a first draft of 62443 zones, but they are not equivalent, because a zone is defined by shared risk rather than by shared function. Two assets at the same Purdue level frequently belong in different zones.
They describe unrelated things and are not alternatives. The OSI model has seven layers describing how a single network communication is structured, from physical signalling up to the application. The Purdue Model has levels describing where systems sit in a plant, from the physical process up to enterprise IT. OSI answers how a packet is built; Purdue answers what a machine does and where it belongs.
Level 0 is the physical process, sensors and actuators. Level 1 is basic control, the PLCs, RTUs and safety controllers. Level 2 is supervisory control, SCADA and HMIs. Level 3 is site operations, historians, MES and engineering workstations. Level 3.5 is the Industrial DMZ, the IT/OT boundary. Levels 4 and 5 are site business and enterprise IT. The numbering runs upward from the physical process, which is the opposite of most network diagrams.
No, and framing it as a choice is usually unhelpful. The productive move is to keep the levels as documentation and shared language, and change where enforcement happens: from a boundary between levels to a boundary in front of each asset, with identity checked per session. In practice most estates end up with Purdue on the wall and per-asset enforcement on the network, which is a coherent position rather than a compromise.
