Purdue Model Explained: OT Network Levels 0 to 5

The Purdue model is the layered reference architecture nearly every industrial network is still drawn against, splitting an environment into Levels 0 through 5, from the physical process at the bottom to the enterprise network at the top. It started life as a functional hierarchy for manufacturing, not a security design, and the security world adopted it because it was the only shared map anyone had. MSP Pentesting runs white-labeled penetration testing for MSPs, channel-only, and a Purdue diagram is usually the first artifact we ask a client to produce.

Your client will hand you one. It'll be three years old, it'll show clean boundaries, and it'll be wrong in at least two places.

That isn't a criticism. That's the job.

Where the Purdue model came from

The full name is the Purdue Enterprise Reference Architecture, or PERA, developed by Theodore J. Williams and a consortium at Purdue University in the early 1990s. It described how manufacturing information should flow between the shop floor and the business, and it fed into the functional hierarchy in ISA-95, published internationally as IEC 62264.

Worth knowing, because it explains most of the arguments people have about it.

PERA and ISA-95 were about function and data flow. They weren't security architectures. The version in every OT security deck, with Levels 0 through 5 and a demilitarized zone wedged in at 3.5, is a later adaptation by the security community. ISA-95's functional hierarchy tops out at Level 4. Level 5 and the DMZ got bolted on because practitioners needed somewhere to put the corporate WAN and the jump host.

So when someone tells you the Purdue model was never meant to be a firewall plan, they're right. It's still the most useful one on the table.

The levels, bottom to top

Here's what actually lives at each level and why an attacker would care.

Two things fall out of that table immediately.

Levels 0 through 3 are operational technology. Levels 4 and 5 are IT. The boundary between 3 and 4 is the one that matters, and it's the one your client's diagram draws most confidently and enforces least.

The other is directionality. Data flows up. Control stays down. Every serious OT incident involves something moving down a path drawn as one-way.

Level 3.5 and why the DMZ exists

The industrial DMZ isn't in the original model. It got added because the alternative was a firewall rule letting Level 4 talk straight to Level 3, and everyone who tried that learned the same lesson.

Done properly, no session crosses the boundary. A user from the business network lands on a jump host in the DMZ and starts a fresh session from there. The Level 3 historian pushes data to a replica in the DMZ, and business users read the replica. Patches stage in the DMZ and get pulled down, never pushed through.

Done badly, which is what testers find most often, it's a VLAN with a firewall in front and rules that let traffic pass end to end. A speed bump with a good name.

The test is simple. Sit at Level 4 and see whether a packet you send shows up at Level 3. If it does, the DMZ isn't doing the one job it has.

Where the model is straining

The Purdue model assumes information moves level by level. A whole generation of industrial products is sold on the promise that it doesn't have to. That's the tension, and ignoring it makes for bad architecture reviews.

• Cloud historians and analytics. Vendors want telemetry going straight from Level 2, sometimes Level 1, to a cloud service. The path skips three levels and terminates outside the client's network entirely.
• Cellular IIoT. A vibration sensor with an LTE modem doesn't sit at any Purdue level. It sits on the equipment and talks to the internet. The network diagram won't show it, because it isn't on the network.
• Vendor remote access. Outbound-initiated tunnels from a cell gateway or a remote access appliance defeat the DMZ by design. The firewall sees an allowed outbound connection. What rides inside it is somebody else's decision.
• Virtualized HMIs. When Level 2 consoles run as VMs in a data center at Level 3 or higher, the physical layering stops matching the logical layering. The hypervisor becomes a level boundary and nobody treats it like one.
• Edge compute. Containers on gateway hardware between Levels 1 and 2, pulling images from a public registry. A software supply chain reaching down to the controllers.
• Identity flattening. Cloud identity providers now authenticate OT users, which means a Level 5 identity compromise has a plausible path to a Level 2 login.

None of this means the model is dead. It means the model describes intent, and your job is to test reality against it.

Which is a much better engagement than confirming a diagram.

Why it still earns its place

Every proposed replacement for the Purdue model is a set of principles. Principles don't tell an engineer which switch port to move. It survives for four practical reasons.

• Shared vocabulary. When a controls engineer and a network admin both say "Level 2," they mean the same thing. That alone saves days on a scoping call.
• It forces an inventory. You can't assign assets to levels without knowing what the assets are, which is why the exercise finds devices nobody remembered.
• It gives you default boundaries. Purdue levels are a sensible first draft of security zones, refined later by risk. If your client is working toward IEC 62443, the level map is a starting point for the zone and conduit model, not the finished product.
• It makes direction explicit. Up is data, down is control. That single rule catches an enormous number of bad firewall entries during a review.

Use it as a reference architecture. Don't use it as an excuse. A perfect Purdue diagram with a flat switch fabric underneath is a document, not a defense, and that gap is what a test exists to expose.

How the model shapes pentest scoping

This is where the model earns its money for an MSP. Purdue levels give you a scoping language your client's engineers already speak, and they let you set risk boundaries in writing before work starts.

A workable default looks like this:

• Levels 4 and 5. Full active testing. This is standard internal and external work, and it's where an assumed-breach scenario starts.
• Level 3.5. Full testing of the DMZ itself. Jump host escape, broker misconfiguration, session handling, credentials cached on the intermediary.
• Level 3. Active testing on servers, with change windows for anything touching the historian or the OT domain. Historians get treated carefully because production reporting depends on them.
• Level 2. Read-only and passive by default. Traffic capture, config review, credential checks on HMIs. Active work only against a spare or on written agreement.
• Level 1. Config and firmware review, protocol analysis, lab replication on identical hardware. Nobody sends unsolicited writes to a controller running a process.
• Level 0. Never touched directly. Assessed through the layers above it.

The deliverable clients actually want isn't a vulnerability list per level. It answers one question. Starting from a compromised laptop at Level 4, how far down does the tester get, and what stopped them?

Answer that and you've told the plant manager something no scanner report ever has.

Segmentation testing that proves something

Reviewing firewall rules isn't a segmentation test. It's a document review with a Wireshark hat on.

Real segmentation testing means putting a host on the source VLAN and trying to reach the destination, both directions, across every boundary the diagram claims exists. Test the tunnel and not just the firewall in front of it, because an outbound-initiated vendor connection walks past a rule set that looks airtight. Test the jump host as a target instead of assuming it's infrastructure. Check what wireless can reach, since a wireless controller with a route into Level 3 is a boundary nobody drew.

If you're building this into an offering, the scoping conversation makes or breaks the margin. Our pentest partner program exists partly so MSPs stop guessing at OT scope and start quoting from a known shape of work.

Common questions about the Purdue model

Is the Purdue model obsolete?

No, but treating it as a complete security architecture is. It's a reference model for structure and vocabulary. Layer risk-based zoning and identity controls on top. Anyone declaring it dead usually hasn't had to explain a network to a controls engineer at 2am.

Does a small plant need a full industrial DMZ?

It needs the function, not the hardware. Small sites get most of the value from a single hardened jump host with unique credentials, session recording and no route from the business network to anything below it. The principle is that no session crosses the boundary uninterrupted.

How does the Purdue model relate to zero trust?

They answer different questions. Purdue describes the structure. Zero trust says don't grant access based on network position. Both hold at once, and in OT you'll apply zero trust incrementally, because a 15-year-old controller cannot authenticate anything and never will.

What Purdue level should an MSP have access to?

Whatever the contract says, enforced through the DMZ like any other remote user. The failure mode we see repeatedly is an MSP holding a flat VPN into Level 3 because that was easiest during onboarding. Fix that before a client's assessor finds it. Your access is part of their attack surface.

Can you test an OT network without stopping production?

Yes, with the right scope. Upper levels take normal active testing. Lower levels get passive analysis, config review and lab replication. What you can't do is run a default scanner profile across the whole environment and hope. That's how legacy devices fall over, and it's why OT testing gets banned at sites where somebody tried it once.

Where to take this next

The Purdue model is a map, and like any map it goes out of date when the territory changes. Cloud connectors, cellular sensors and vendor tunnels change it constantly. The model still earns its keep because it gives you and your client a shared way to describe what should be true. Testing is how you find out what actually is.

If you're taking on industrial clients, scoping is the hard part. Not the testing.

MSP Pentesting works channel-only, under your brand, and we'll walk the level map with you before anyone quotes anything. Bring the diagram, the asset list and the constraints your client has already set. Get a pentest quote and we'll tell you what's testable live, what belongs in a lab, and which boundary nobody has ever verified.