Purdue Model for Industrial Control System (ICS) Cybersecurity Explained

The Purdue Model organizes an industrial plant's network into six hierarchical levels, from field sensors to enterprise IT, giving engineers and security teams a shared map of where PLCs, SCADA, and DCS systems sit and where to enforce security boundaries between them.

What is the Purdue Model?

The Purdue Model, formally the Purdue Enterprise Reference Architecture (PERA), is a hierarchical reference framework developed in the early 1990s by Theodore J. Williams and the Purdue University Consortium for Computer-Integrated Manufacturing. It was never originally built as a security framework. Its first purpose was simply to describe how data should flow between the physical plant floor and the business systems above it.

What made the model endure for over three decades is that its natural layering, from real-time PLC control at the bottom to corporate IT at the top, turned out to map almost perfectly onto where cyber attackers would eventually need to be stopped. Today the Purdue Model underpins NIST SP 800-82, ISA/IEC 62443, and API 1164, the core references most industrial cybersecurity programs are built around.

The Six Levels of the Purdue Model

Data and commands should flow vertically between adjacent levels, never directly across unrelated levels, and never straight from Level 5 down to Level 0 without passing through every checkpoint in between. That single design rule is what turns each level boundary into a natural place to put a firewall, an access control list, or a monitoring sensor.

Real Life Example

Think of a factory as a castle with concentric walls. The outermost wall faces the internet and the public business network. Each wall you cross moving inward gets harder to breach and protects something more physically dangerous if it fails, until you reach the innermost keep: the sensors and actuators directly touching a real process. The Purdue Model is simply a name for each of those walls and what lives behind them.

What Lives at Each Purdue Level

1. Level 0, Physical Process: Sensors, actuators, valves, and motors that directly interact with the real-world process. Requires physical access control and signal integrity protection above all else.
2. Level 1, Basic Control: PLCs, RTUs, and safety instrumented systems that execute real-time control logic. Often runs real-time operating systems with no support for modern authentication or patching.
3. Level 2, Supervisory Control: SCADA software, DCS, and HMI screens where operators monitor and issue commands to the process. A single compromised HMI at this level gives an attacker direct command authority.
4. Level 3, Operations Management: Manufacturing Execution Systems (MES), process historians, and batch scheduling that manage plant-wide production workflows.
5. Level 3.5, Industrial DMZ: Not part of the original model but now considered essential. Hosts patch management servers, historian mirrors, and remote access gateways as a controlled buffer.
6. Level 4, Business Logistics: ERP systems, plant scheduling, and business planning software that consume production data for decision making.
7. Level 5, Enterprise Network: Corporate email, file storage, and internet-facing services, entirely removed from direct contact with any ICS component.

Purdue Model and IEC 62443: How They Map Together

Applications Across Industries

Is the Purdue Model Still Relevant?

The honest answer from most of the OT security community is: mostly, but incompletely. The model assumed a clean "air gap" between IT and OT that made sense in the 1990s but rarely exists today, since cloud analytics, remote vendor access, and IIoT sensors have made a fully isolated OT network nearly impossible in practice. Critics point out that many modern architectures now send Level 0 sensor data straight to the cloud, bypassing the neat hierarchy entirely.

Even so, most security practitioners still find the model useful, not as a literal network topology, but as a shared vocabulary for asset inventory, risk assessment, and where to place security controls. As SANS put it, even if the hierarchical layers can no longer be applied uniformly, sorting devices into functional levels still helps determine where defenses belong.

Common Purdue Model Implementation Mistakes

1. Assuming an "air gap" exists when remote access or cloud connections have quietly bridged it
2. Placing firewall rules only on inbound traffic while ignoring outbound data exfiltration risk
3. Treating the Industrial DMZ as optional rather than a mandatory buffer zone
4. Failing to inventory legacy Level 0 and 1 devices that predate any authentication capability
5. Allowing flat, unsegmented OT networks to persist because retrofitting feels too disruptive
6. Applying IT security patch cycles to Level 1 controllers without accounting for uptime requirements

Purdue Model for ICS Security: Video Walkthrough

Frequently Asked Questions About the Purdue Model

• SANS Institute, Introduction to ICS Security Part 2: The Purdue Model
• Palo Alto Networks, What Is the Purdue Model for ICS Security
• Fortinet, What Is the Purdue Model for ICS Security