The Purdue model is a reference architecture that organizes industrial systems into levels 0 through 5, from the field devices that touch the process, up through control and supervision, to the enterprise IT that runs the business, with a security buffer called the DMZ between the plant and the office. It underpins the ISA-95 standard and is the shared map for OT network segmentation.
If you have ever heard someone say "keep that on level 2" or "it has to go through the DMZ," they were speaking Purdue. The model is old, it comes from work at Purdue University in the 1990s, and it is under real pressure from cloud and IIoT. But it remains the vocabulary every controls engineer, IT team, and auditor shares, so it is worth understanding exactly, not vaguely.
What is the Purdue model?
The Purdue model, formally the Purdue Enterprise Reference Architecture (PERA), is a layered blueprint for how industrial control systems and business systems fit together. It groups every device and application in a plant into functional levels, orders them by how close they sit to the physical process, and, critically, defines how data and commands are allowed to flow between them. It was later folded into the international standard ISA-95 / IEC 62264 for enterprise-control integration.
The core idea is simple: the closer a system is to the moving metal, the faster and more deterministic it must be, and the more tightly it should be isolated from the open internet. The further up you go, the slower, broader, and more business-oriented the systems become. Reaction time stretches from milliseconds at the bottom to days at the top.
What are the levels of the Purdue model?
There are six numbered levels plus a demilitarized zone (DMZ) inserted between the plant and the enterprise. Here is what lives at each one.
| Level | Name | What lives there | Timescale |
|---|---|---|---|
| 5 | Enterprise network | Corporate IT, email, internet-facing systems | Days+ |
| 4 | Business planning & logistics | ERP, site business systems | Days |
| 3.5 | Industrial DMZ | Proxied historians, patch relays, data brokers | Buffer zone |
| 3 | Site operations | MES, historians, scheduling | Minutes–hours |
| 2 | Area supervisory control | SCADA, HMI | Seconds |
| 1 | Basic control | PLCs, RTUs, DCS controllers | Milliseconds |
| 0 | Physical process | Sensors, actuators, drives | Real-world physics |
A quick walk up the stack: Level 0 is the physics, the sensors and actuators that read and move the real world. Level 1 is basic control, the PLCs and RTUs making millisecond decisions. Level 2 is area supervision, the SCADA systems and HMIs an operator watches. Level 3 is site operations, where the MES historians, and scheduling coordinate a whole plant. Levels 4 and 5 are the business: ERP and site logistics at 4, corporate IT and the internet at 5. And between the plant (0–3) and the business (4–5) sits the industrial DMZ at level 3.5.
Why does segmentation between levels matter?
Because a flat network means a compromise anywhere is a compromise everywhere, including the machines that can hurt people. The whole safety and security case for the Purdue model is that the control layers should not be directly reachable from the office network or the internet. If ransomware lands on a laptop at level 5, it should hit walls long before it reaches a PLC at level 1. Segmentation turns one big blast radius into many small ones.
This is not just good practice; it is codified. The ISA/IEC 62443 series of security standards builds its zones-and-conduits architecture directly on these levels: group assets into zones by trust, and force traffic between zones through controlled conduits. The Purdue levels are the natural zone boundaries. That is why "which level does this sit on" is a security question as much as an architecture one.
What is the industrial DMZ at level 3.5?
The industrial DMZ is a buffer network between the plant (levels 0–3) and the business (levels 4–5) that no traffic is allowed to cross directly. Instead of a firewall rule letting the ERP reach into the historian, both sides talk only to systems that live in the DMZ: a proxied copy of the historian, a patch-management relay, a data broker. The plant never opens a direct hole to the enterprise, and vice versa.
This level 3.5 buffer was not in the original model. It was added, the extended Purdue model, precisely because IT/OT convergence made the old single boundary too thin. Modern guidance from government and industry treats the DMZ as essential rather than optional, and it is the single most important structural idea to get right when you connect a plant to anything outside it.
How is the classic Purdue model changing?
Cloud services, IIoT sensors, and the push for real-time data are all pressuring the strict layer-by-layer flow the model assumes. The classic pattern says data climbs one level at a time. But a modern wireless vibration sensor may want to send readings straight to a cloud analytics service, and a unified namespace (UNS) architecture flips the model from hierarchical polling to a publish-subscribe broker that many systems read from at once. These patterns do not respect the tidy ladder.
The honest state of things in 2026: the Purdue model is not obsolete, but it is no longer a literal wiring diagram. It survives as a security and trust framework, the levels still define where the boundaries and the DMZ go, even as data paths get flatter. The reframing most teams land on is "Purdue for segmentation, broker for data." You keep the strong boundaries and the DMZ, and you let a well-secured broker or edge layer, sitting in the DMZ or level 3, handle the many-to-many data flows that the strict ladder cannot. See IIoT and smart factory technology for how those newer patterns fit.
How do you apply the Purdue model to a real plant network?
You apply it as a segmentation and trust plan, working from an honest inventory. The model is only useful if it maps to what is actually plugged in.
- Inventory every device and its level. List each PLC, HMI, server, and sensor, and assign it a Purdue level. Anything you cannot place is a red flag.
- Draw the current data flows. Trace what talks to what today. Most plants find at least one connection that skips levels or reaches straight from the office to a controller.
- Define zones and conduits. Group assets into trust zones along the level boundaries, per ISA/IEC 62443, and decide which conduits between them are allowed.
- Stand up the DMZ. Put proxied historians, patch relays, and data brokers at level 3.5 so no plant system talks directly to a business system.
- Close the skip-level paths. Route every crossing through the DMZ and remove default credentials and direct internet exposure from control-layer devices.
- Choose a data pattern for the top. Decide whether higher-level analytics read through the classic ladder or through a broker in the DMZ, and keep it read-mostly so data flows up while commands stay down.
By the numbers
The Purdue model's authority comes from being embedded in the standards plants already follow. It feeds ISA-95 / IEC 62264 for enterprise-control integration and provides the level boundaries that ISA/IEC 62443 uses to define security zones and conduits. U.S. cybersecurity guidance for industrial control systems from CISA reinforces the same principle, segment the control network and place a DMZ between it and enterprise IT. Six levels, one DMZ, one enduring rule: the closer to the process, the more isolated it stays.
Where this connects to operations: respecting the model does not mean leaving plant data trapped at the bottom. Modern operational layers are built to read from SCADA, historians, and PLCs through segmented, read-mostly connections, up through the DMZ, never around it. That is exactly how Harmony connects: it adds context, search, and approvable actions on top of existing systems without touching the control layer or flattening the boundaries the Purdue model protects. No rip-and-replace (see the connected systems module).
Where does the Purdue model sit alongside other plant concepts?
Think of the Purdue model as the map and the other plant-tech topics as the territory. The layers it defines are the same ones described in SCADA vs MES vs ERP; the networks that connect level 0 to level 1 are Profinet and Profibus; the pressure to move faster is the story of real-time manufacturing data; and the failure to move data across the boundaries at all is the story of manufacturing data silos. For where a digital replica of the process fits into this stack, see digital twin.