Keep the Purdue Model as your map. Put a boundary in front of each machine.
Most OT security talks start with the Purdue levels. Yet almost every real plant has traffic that skips them. This guide covers the levels, what remote access, IIoT and cloud analytics changed, and what to enforce when redrawing the network is not an option.
Last updated:
What is the Purdue Model?
The Purdue Model, formally the Purdue Enterprise Reference Architecture (PERA), organises an industrial control system into levels. Level 0 is the physical process and Levels 4 and 5 are enterprise IT. An Industrial DMZ at Level 3.5 separates operations from the business. Purdue University wrote it in the 1990s as a model for manufacturing integration. It was never designed as a security control. The security use came later and rests on one assumption: traffic moves vertically, level by level, and you can inspect it at each boundary.
That assumption no longer holds. The levels are still an excellent shared vocabulary, and worth keeping for that alone. But the diagram no longer describes how packets move through a modern plant.
The Purdue Model levels and what sits at each.
There are six tiers, counting the DMZ. The numbering runs upward from the physical process. Most network diagrams run the other way, which often causes 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 connections that skip the levels.
None of these are attacks. They are ordinary connections the business approved. That is why they are hard to argue with, and why they are still there.
Remote access skips every level in 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 data straight 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 blur Levels 3 and 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.
The Industrial DMZ concentrates risk in one place.
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.
Unrelated traffic 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.
Auditors ask for evidence the levels cannot produce.
This is often what starts the conversation. Frameworks now ask for evidence per machine and per identity. A level boundary does not produce 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.
Options for enforcement, compared.
Nothing here replaces the Purdue Model as a vocabulary. These options replace it as an enforcement strategy, a 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. |
Protect each machine without redrawing the network.
Most options above assume you can restructure the network. On a running plant, equipment often cannot be patched, taken offline or re-addressed. That is usually where the project stalls. The alternative is to leave the topology alone. You put a boundary in front of the machines that matter, one at a time.
Connects to your existing network.
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.
One boundary per machine.
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 checked on every session.
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.
Works on machines 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 replacing equipment.
You do not need to abandon the model or rebuild the network. Find where the drawing and the plant disagree. Then close 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
End every shared tunnel at a gate that gives 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 how traffic really moves on your network.
Have your Purdue diagram and real traffic drifted apart? We can show where the bypasses are on your network. We can also scope what protecting the critical machines 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.
Common questions about the Purdue Model.
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 an industrial estate, no: it is still the most useful one available. The levels remain a good way to explain where a system sits. The security use assumed that traffic crosses levels in order and can be inspected at each boundary. That 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 a first draft of 62443 zones. They are not equivalent, because a zone is defined by shared risk rather than 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 rarely helps. Keep the levels as documentation and shared language. Change where enforcement happens: from a boundary between levels to a boundary in front of each asset, with identity checked per session. Most estates end up with Purdue on the wall and per-asset enforcement on the network. That is a coherent position in its own right.
PERA is the full name of what everyone calls the Purdue Model. Theodore Williams and the Purdue University Consortium published it in the early 1990s as a reference model for computer-integrated manufacturing. It covered far more than security: it described the whole enterprise, from the physical process up to business planning. What survived into common use is the level hierarchy, Levels 0 to 5, plus the Industrial DMZ that practitioners later added at 3.5. When someone says Purdue reference model or Purdue reference architecture, they mean that hierarchy, not the original consortium document.
It gives you a shared map. A map is worth a great deal when IT and OT describe the same estate in different words. Placing an asset at Level 1 or Level 3 settles what it does, what talks to it, and what a compromise would cost. The model also makes lateral movement visible: if traffic crosses three levels to reach a PLC, that shows up as a design fact. What it does not do is enforce anything. The levels are documentation. The security value comes from pairing the map with enforcement checked per session, in front of each asset.
The levels are the usual starting point for segmentation. Each level becomes a zone, and traffic between levels passes through a controlled conduit. The Industrial DMZ is the crossing between IT and OT. That mapping is why Purdue and segmentation are discussed together, and also where the model shows its age. Segmenting by level assumes traffic moves vertically, one level at a time. That stopped being true once IIoT gateways began publishing from Level 0 straight to the cloud. Segmentation still matters, but the useful unit is now the asset rather than the level.
