The Purdue Model Explained, Level by Level
If you've sat through an OT security presentation, you've almost certainly seen the Purdue Model: a stack of levels running from field sensors at the bottom to corporate systems at the top. It's the most widely used way to describe how an industrial network should be organized. Understanding it, level by level, makes almost every other OT security conversation easier.
Where the Purdue Model came from
The model traces back to the Purdue Enterprise Reference Architecture (PERA), developed in the early 1990s by Theodore J. Williams and a consortium of industry members working with Purdue University in Indiana. PERA wasn't originally a security framework. Its purpose was to describe how a manufacturing enterprise is organized, from physical equipment up to business planning, so that computer systems could be integrated in a consistent way.
The hierarchy was later adopted into ISA-95, the international standard for integrating enterprise and control systems, which defines functional levels for manufacturing operations. Over time, security practitioners took that same layered picture and used it to describe where network boundaries belong. The industrial DMZ at Level 3.5 was added through industry practice rather than in the original reference model.
The lower levels: running the process
These levels are where the physical work happens. Disruptions here are felt immediately on the plant floor.
Level 0, the physical process. Sensors, transmitters, valves, motors, pumps and analyzers. These devices measure and act directly on the process.
Level 1, basic control. Controllers such as programmable logic controllers (PLCs), remote terminal units (RTUs) and DCS controllers. They read Level 0 inputs, run control logic and drive outputs, often in real time. Safety instrumented systems are usually shown at this level too, though they're best treated as their own protected zone.
Level 2, area supervisory control. Human-machine interfaces (HMIs), local SCADA servers, alarm servers and the operator stations that let people supervise a unit or area. Programming workstations used by controls staff often live here as well.
The upper levels: operations and business
Level 3, site operations. Systems that manage the site as a whole: plant historians, manufacturing execution systems, production scheduling, site-wide domain services and the servers that support the control network. Level 3 is the top of the OT environment.
Level 3.5, the industrial DMZ. A buffer network between OT and IT. It hosts services that both sides need, such as a replicated historian, patch and antivirus distribution servers, file transfer services and remote access gateways. Nothing should pass straight through it; connections terminate in the DMZ and new, separately controlled connections continue on.
Level 4, business logistics. Site business systems such as email, ERP access, business planning and reporting. This is the corporate IT network at the site.
Level 5, enterprise. Corporate data centres, enterprise-wide applications, internet connectivity and, increasingly, cloud services.
Which traffic should cross, and which shouldn't
The real value of the model is in the boundaries between levels. A few principles guide what should be allowed:
No direct IT-to-Level 2 traffic. A user or system on the business network should never connect directly to an HMI, controller or programming workstation. Any access from Level 4 or above should be brokered through the industrial DMZ.
Data should flow up more than commands flow down. It's normal for process data to move upward, for example from a site historian to a replicated historian in the DMZ for business reporting. Commands and changes moving downward should be rare, tightly controlled and logged.
Each boundary should be explicit. Firewalls between levels should have rules that name specific sources, destinations and protocols, not broad "any to any" permissions.
Adjacent levels talk to adjacent levels. Traffic generally shouldn't skip levels. Level 1 controllers talk to Level 2 HMIs, not to Level 4 business servers.
Remote access lands in the DMZ first. Vendors and remote staff should connect to a gateway in Level 3.5, authenticate strongly, and then reach only the specific systems they need.
Common problems we see include historians that are reachable directly from the business network, dual-homed computers with one network card in IT and another in OT, and flat networks where Levels 1 through 3 share a single broadcast domain. Each of these quietly undoes the separation the model is meant to provide.
How Purdue relates to zones and conduits
The IEC 62443 series of standards uses a related but more flexible idea: zones and conduits. A zone is a group of assets that share the same security requirements. A conduit is the controlled communication path between zones.
The Purdue levels are a natural starting point for defining zones. A site might put its Level 3 servers in one zone, each process area's Level 1 and 2 equipment in its own zone, and the safety system in a separate, highly restricted zone. The firewalls and approved data flows between them become conduits, each with documented rules.
Where Purdue describes a general hierarchy, zones and conduits let you tailor that hierarchy to the risks of a specific site. The two work best together: Purdue gives everyone a shared vocabulary, and IEC 62443 gives you a method for deciding how strong each boundary needs to be.
Key takeaways
The Purdue Model grew out of PERA, developed in the early 1990s at Purdue University, and its hierarchy was later adopted into ISA-95.
Levels 0 to 3 make up the OT environment; Levels 4 and 5 are business and enterprise IT.
The industrial DMZ at Level 3.5 brokers every connection between IT and OT, so nothing passes straight through.
IT systems should never connect directly to Level 2 or below.
IEC 62443 zones and conduits build on the Purdue levels to set boundary strength based on risk.
How QBits Networks can help
Most sites have a Purdue diagram on paper, but the real network doesn't always match it. A network segmentation review compares your actual traffic and firewall rules with the intended architecture and shows where boundaries have drifted. Tell us what you need through our contact page and we'll scope it with you.