The Purdue model in 2026: what still holds, what broke

What the Purdue model actually is

The Purdue model — formally the Purdue Enterprise Reference Architecture, developed under Theodore Williams at Purdue University in the early 1990s and later absorbed into ISA-95 — organizes an industrial enterprise into functional levels. It was created as a manufacturing-integration model, not a security architecture. Security people adopted it anyway, because it gave us something we badly needed: a shared map of which systems belong together and where the boundaries should sit.

The levels, in the form the industry actually uses:

Level	Function	Typical systems
5	Enterprise	Corporate IT, ERP, email, internet access
4	Site business	Local business systems, scheduling, MES interfaces
3.5	OT DMZ	Replicated historian, patch staging, jump hosts, AV/EDR relays
3	Site operations	Primary historian, engineering workstations, domain services for OT, alarm servers
2	Supervisory control	HMIs, SCADA servers, operator consoles
1	Basic control	PLCs, DCS controllers, RTUs, protective relays
0	Physical process	Sensors, actuators, valves, drives, the process itself

Two footnotes that matter more than the table. First, Level 3.5 — the DMZ — is not in the original model at all; practitioners bolted it on in the 2000s, and it turned out to be the most valuable level of the bunch. There is a lesson in that: reference models improve in the field, not in the committee. Second, safety instrumented systems are usually drawn as a separate zone beside Levels 0–1 rather than inside them, because their independence is the entire point of having them.

What still holds

The trust gradient is real. Consequence of compromise genuinely increases as you descend. A phished mailbox at Level 5 is a bad day; unauthorized writes at Level 1 can bend metal. Any architecture that groups assets by consequence and restricts traffic between the groups is doing the essential thing, whatever you call the groups. This is the same zone logic as enterprise network segmentation — with physics raising the stakes at the bottom of the stack.

The DMZ-and-broker pattern is undefeated. No session originating at Level 4 or above should terminate at Level 2 or below, and vice versa. Everything crosses through a broker in the DMZ: the enterprise reads the replicated historian, patches stage on a DMZ server before OT pulls them, remote access lands on a jump host. When I ran both networks at a petrochemical plant, this boundary was the line item I defended hardest in every budget and every design review — because every incident scenario we tabletopped either died at that boundary or didn’t.

Levels as vocabulary. When an integrator, an asset owner, and a consultant can all say “that belongs at Level 3” and mean the same thing, you save real engineering hours. ISA/IEC 62443 formalizes the flexible version — zones and conduits defined by risk rather than by a fixed hierarchy — and NIST SP 800-82r3 discusses the Purdue model in exactly this spirit: a useful reference concept, not a mandate.

What cloud and IIoT broke

The model’s implicit assumption was that data flows vertically, level by level, inside one facility you own. That assumption is gone, and it is not coming back.

The model earned its levels. It never earned its arrows.

Sensors that skip the hierarchy. IIoT vibration sensors, steam-trap monitors, and corrosion probes ship with cellular modems or Wi-Fi and send telemetry straight to a vendor cloud. That is a Level 0/1 data source reaching Level 5-equivalent infrastructure with no levels in between. The data flow is legitimate — predictive maintenance is real value — but the uncontrolled path is the problem.

Cloud historians and analytics. When the system of record for process data is a cloud service, “historian at Level 3, replica in the DMZ” needs reinterpretation. The plant historian becomes an edge buffer, and the DMZ’s job shifts from hosting the replica to controlling the egress.

Vendor telemetry and remote diagnostics. Turbines, compressors, and analyzers increasingly arrive with connectivity as a warranty condition. Each one is a vertical bypass installed by contract, negotiated by people who will never see your network diagram.

Edge gateways that collapse levels. A single edge box may speak Modbus to controllers, run analytics locally, and publish MQTT to a cloud broker — Level 1 through Level 5 functions in one chassis. Drawing it “at” a level is fiction. What matters is which interfaces it exposes to which zones, and that question the model can still answer.

The wrong response is to declare the model dead and abandon hierarchy. The equally wrong response is to pretend it is 2005, ban everything, and watch the business route around you with cellular modems — because it will, and you will find out from a Shodan scan instead of a change record.

Applying it in 2026

Use Purdue as the segmentation blueprint and 62443 zones-and-conduits as the method. Concretely:

1. Keep the levels as default zones. Levels 0–1 (with SIS in its own zone), Level 2, Level 3, DMZ, enterprise. For most plants this is the right starting granularity, and it maps directly onto the firewall and VLAN design covered in SCADA network design.
2. Treat every cloud path as a named conduit. Each IIoT feed, vendor telemetry link, and cloud-historian egress gets documented: source zone, destination, protocol, direction, business owner. Outbound-only, TLS, authenticated, initiated from a gateway you control — never inbound to a control zone.
3. Give IIoT its own zone. Cellular-connected sensors do not join the control network just because they measure the same pump. Segregated network, no path to Levels 0–2. If the data must reach the control room, it comes back down through the DMZ like any other external feed.
4. Move the DMZ’s job from hosting replicas to governing exchange. Jump hosts, egress proxies, data diodes where the consequence justifies them, patch staging, broker services. The DMZ is a customs checkpoint, not a warehouse.
5. Refuse direct enterprise-to-controller paths. Still. Always. Every modernization proposal eventually includes one, usually wearing the words “real-time visibility.” The answer that has aged well: you can have the data in near-real time; you cannot have the session.

What to write down

The Purdue diagram itself is the least important artifact. Record instead: the zone inventory with the consequence rationale for each zone, the complete conduit register — including every cellular modem and vendor box, which means walking the plant, because they will not be in any database — which conduits are outbound-only versus bidirectional, and who approves changes to each. Review the register at least annually and after every project, because projects are how unauthorized conduits are born.

The model is thirty-plus years old and describes a world that no longer quite exists. It survives anyway, and the reason is worth stating plainly: consequence-based zoning with brokered boundaries is not a 1990s idea that aged well. It is just correct — and correct engineering ideas outlive the diagrams that first carried them.