What Is the Purdue Model? Definition, Level & Best Practices

The Purdue Model is the federal standard for ICS network segmentation, organizing OT environments into six hierarchical levels with enforced trust boundaries.

What Is the Purdue Model?

A single compromised HMI workstation gives an attacker direct command authority over PLCs controlling physical processes. The difference between that workstation sitting behind three enforced security boundaries or sharing a flat network with your corporate email server is, in practical terms, the Purdue Model.

The Purdue Enterprise Reference Architecture (PERA), universally known as the Purdue Model, is a hierarchical reference framework that segments industrial control system (ICS) networks into distinct functional layers, from physical processes at the field level to enterprise IT and external networks. Developed at Purdue University's Laboratory for Applied Industrial Control in 1991 by Theodore J. Williams and the Industry-Purdue University Consortium for Computer-Integrated Manufacturing, the model originally addressed data flows in computer-integrated manufacturing, not cybersecurity.

As industries connected OT to IT, the hierarchical structure became the natural foundation for defining what should and should not communicate across network boundaries. Today, the model organizes ICS environments into Levels 0 through 5 (plus a critical Level 3.5 Industrial DMZ), each with defined components, trust boundaries, and security requirements.

DOE research confirms the model "is used as a baseline architecture for all industrial control system frameworks such as API 1164 and NIST 800-82."

Understanding what the Purdue Model is, however, is only the first step. Its significance in modern industrial security comes from how it translates that hierarchical structure into concrete cybersecurity protections.

How the Purdue Model Relates to Cybersecurity

The Purdue Model's core security value is establishing clear trust boundaries between OT and IT environments, enabling defense-in-depth through layered security zones. ISA-95 formally codified its hierarchical approach into standardized terminology, and ISA/IEC 62443 built its zones and conduits security architecture directly on the model's foundation.

CISA, NIST, and the DoD actively endorse the Purdue Model in current 2025 guidance:

• CISA's 2025 advisories reference it as "a guide for layered security zones"
• NIST incorporated it into SP 800-82 Revision 3
• The Department of Defense references it in zero-trust OT guidance

When you defend architecture decisions to auditors or regulators, the Purdue Model carries cross-agency federal endorsement.

Manufacturing represented 27.7% of all cyberattacks in 2025, the highest of any industry for the fifth consecutive year, according to the IBM X-Force 2026 Index. These numbers demonstrate why structured segmentation in industrial environments is not an optional enhancement.

To understand how that segmentation works in practice, you need to know what lives at each level and what security obligations each one carries.

The Six Levels of the Purdue Model

The Purdue Model defines six functional levels (0–5), plus the Industrial DMZ added to address IT/OT convergence. Each level contains specific components, carries a defined risk profile, and requires distinct security controls.

Level 0: Physical Process

The actual industrial process being controlled. Sensors, actuators, valves, motors, and production equipment live here. The primary requirement is physical access control and signal integrity protection.

Level 1: Basic Control

Real-time programmable control of physical processes. PLCs, RTUs, Safety Instrumented Systems (SIS), and intelligent electronic devices execute control logic. These are high-value targets because compromising them enables direct manipulation of physical processes. They typically run real-time operating systems with no support for modern authentication or patching. The DOE classifies Levels 0 and 1 together as the Safety Zone with a Critical risk profile.

Level 2: Supervisory Control

Human-machine interaction and supervisory monitoring. HMIs, SCADA systems, operator workstations, and local control servers reside here. This level is the primary target for attacker lateral movement from IT because it runs Windows-based operating systems while maintaining direct command authority over Level 1 PLCs, a critical monitoring and containment gap in many environments.

Level 3: Site Operations

Plant-wide operations management. Manufacturing Execution Systems (MES), data historians, batch control systems, and OT network monitoring platforms aggregate all OT data flowing upward. Historians at this level are a common IT/OT bridge point and have historically been exploited as pivot points between environments.

Level 3.5: Industrial DMZ (iDMZ)

This layer did not exist in the original 1990s model. DOE guidance states: "This level was not designed initially within the Purdue model; however, with the continual convergence of OT and IT this abstract layer is essential to ensure separation of communications." It contains perimeter firewalls at both IT and OT boundaries, data diodes, proxy servers, historian replicas, and jump servers. No direct IT-to-OT connections traverse this zone.

Level 4: Enterprise Network

Corporate IT systems including ERP, CRM, Active Directory, and business applications. The critical enforcement requirement: zero direct connectivity to Level 2 or below.

Level 5: External Network

Internet-facing systems, cloud services, and vendor access portals that, properly architected, have no path to OT without traversing multiple security boundaries.

Understanding these components is necessary, but knowing how traffic flows between them is where security enforcement actually happens.

How the Purdue Model Works

The Purdue Model enforces security through hierarchical communication control. Each level communicates primarily with its immediate neighbors, and all traffic between the OT zone (Levels 0 through 3) and the IT zone (Levels 4 and 5) must pass through the Industrial DMZ at Level 3.5.

NIST SP 800-82 Rev. 3 explicitly requires firewall rules preventing Level 4 devices from directly communicating with Level 2, 1, or 0 devices. The standard also recommends that organizations consider making outbound rules as stringent as inbound rules, helping to prevent both inbound attacks and outbound data exfiltration.

ISA/IEC 62443 formalizes this through zones and conduits. A zone is a collection of assets sharing common security requirements. A conduit is the communication channel connecting zones and must be secured to the same level of criticality as the most trusted zone it connects.

In practice, the data flow works like this:

• Level 0 sensors feed data to Level 1 controllers
• Level 1 controllers report to Level 2 HMIs and SCADA systems
• Level 2 pushes data to Level 3 historians
• Level 3 historian replicas in the DMZ serve data to Level 4 IT consumers

IT systems never query OT directly

This one-way data push architecture, reinforced by firewalls, access controls, and optionally hardware data diodes, prevents an attacker who compromises the enterprise network from reaching the systems that control physical processes.

Key Benefits of Implementing the Purdue Model

Properly implemented, the Purdue Model delivers compounding security value across four operational areas.

• Defense-in-depth through enforced segmentation. Each Purdue level creates a security boundary an attacker must traverse. Even if the enterprise network is fully compromised by ransomware, proper segmentation can prevent operational shutdown of physical processes.
• Regulatory and standards alignment. The Purdue Model forms the explicit basis for ISA/IEC 62443 compliance assessments, NIST SP 800-82 architecture requirements, and active CISA advisories. Implementing it gives you an auditable, regulator-defensible architecture.
• Lateral movement containment. The 2025 Verizon DBIR found ransomware now represents 44% of all data breaches. In OT environments, ransomware directly threatens operational availability and safety, not only data. Purdue segmentation limits ransomware propagation from IT into OT zones.
• Compensating control for legacy systems. Industrial equipment lifecycles of 15 to 25 years mean your OT environment likely contains systems that cannot be patched, authenticated, or monitored with modern tools. CISA's guidance specifically recommends network segmentation as the primary protection for these systems.

These benefits compound, but only when the implementation is sound. And sound implementation starts with understanding the structural challenges that make the Purdue Model harder to deploy than it looks on paper.

Purdue Model Implementation Challenges

The Purdue Model's principles are clear on paper. The operational reality of implementing them in live industrial environments is not. Several structural challenges consistently create friction between what the architecture diagram shows and what traffic actually does on the network.

1. IT/OT convergence creates undocumented architecture. Modern operational requirements continuously create new connections across Purdue boundaries. Peer-reviewed research published in 2025 identifies data flow requirements, security zone complexity, and protocol bridging as the three primary convergence challenges.
2. Legacy systems resist modern security controls. Level 1 PLCs and RTUs typically run real-time operating systems with proprietary protocols that most IT security tools cannot inspect. You cannot install endpoint agents on a PLC running RTOS from 2005. Network-based segmentation becomes your only viable control.
3. Operational safety constrains security options. NIST SP 800-82 Rev. 3 explicitly requires that segmentation account for "operational performance and safety." ICS environments cannot tolerate authentication failures or network latency that would be acceptable in IT. No security control can become a single point of failure for production or safety systems.
4. Cloud and IIoT lack clear Purdue placement. The DOE specifies that Level 0 and 1 devices are not viable for virtualization or cloud hosting due to real-time timing requirements. Cloud and virtualization apply at Level 3 and above, but many organizations integrate cloud analytics and IIoT sensors without a clear framework for where they belong.
5. Remote access violates fundamental principles. Traditional VPN solutions often create direct connectivity to lower OT levels, directly violating the Purdue Model's control hierarchy. CISA has documented pro-Russia hacktivist groups successfully compromising OT control devices through minimally secured, internet-facing VNC connections.

Knowing these challenges helps you anticipate them. But the most dangerous failures are the ones teams create themselves.

Common Purdue Model Mistakes to Avoid

Where challenges are structural, mistakes are choices: decisions teams make during design, deployment, or ongoing management that undermine the protections the model is meant to deliver. These are the errors CISA threat hunters encounter most consistently in real industrial environments.

Deploying VLANs without enforcing inter-VLAN access control. CISA's proactive threat hunt discovered organizations with properly configured separate IT and SCADA VLANs but no corresponding firewall rules, leaving inter-VLAN routing unrestricted. The result: "a non-privileged user within the IT network [could] use their credentials to access the critical SCADA VLAN." VLANs alone are a network management tool, not a security control.

The following errors compound that foundational mistake and are just as common in live environments:

• Leaving permissive firewall rules in place. "Temporary" troubleshooting rules (allow any/any, open RDP/VNC) become permanent fixtures that persist through audits and personnel changes.
• Allowing direct IT access to field controllers. NIST SP 800-82 Rev. 3 requires firewall rules preventing Level 4 devices from communicating with Level 2, 1, or 0. Violations create attack paths that bypass all supervisory controls.
• Treating implementation as a one-time project. Organizations that deploy Purdue segmentation and never revisit it accumulate undocumented connections as operational needs change. Architecture validation must include actual traffic analysis and rule auditing, not just diagram review.
• Granting broad vendor remote access into OT zones. CISA's threat hunt guidance identifies vendor remote access as a frequently exploited vulnerability. VPN access terminating directly in OT zones rather than DMZ jump servers creates persistent attack paths.

Avoiding these mistakes requires deliberate, standards-aligned practices.

Purdue Model Best Practices

Knowing what can go wrong is half the work. The other half is building and maintaining the architecture in ways that hold up under operational pressure, audit scrutiny, and active threat conditions. The following practices reflect current CISA, NIST, and DOE guidance for ICS environments.

Implement a two-firewall Industrial DMZ. CISA's guidance is explicit: deploy firewalls at both the IT-DMZ boundary and the OT-DMZ boundary, two separate enforcement points. Host all shared services (historians, jump servers, remote access endpoints) inside the DMZ. DMZ hosts must not initiate connections into OT zones.

Deploy ICS-aware security controls. Standard IT firewalls are insufficient. CISA requires SCADA-aware firewalls capable of inspecting industrial protocols at the application layer, application allowlisting for authorized protocols, and deep packet inspection for industrial communications.

From there, four operational controls reinforce the architecture day to day:

• Enforce bidirectional communication controls. NIST SP 800-82 Rev. 3 recommends making outbound rules as stringent as inbound rules, preventing both inbound attacks and outbound data exfiltration from compromised OT systems.
• Use data diodes for high-security data flows. Hardware-enforced unidirectional data transfer for historian replication physically prevents reverse communication, eliminating the risk of command-and-control into OT via historian channels.
• Validate architecture against actual traffic. Compare firewall rulesets against network diagrams. CISA threat hunts have repeatedly found these contradict each other. Simulate attacker scenarios: attempt to reach critical SCADA VLANs from compromised non-privileged IT accounts.
• Terminate all remote access in the DMZ. Every vendor, employee, and contractor remote session must land in Level 3.5 jump servers with session logging, never directly in OT zones.

Extend with zero trust at upper levels. Both CISA's 2025 guidance and DoD's Zero Trust for OT position zero trust as complementary to Purdue, not a replacement. Identity verification applies at Level 3.5 and above. Levels 0 through 2 require network-based segmentation as the primary control.

These practices reflect the model as it was designed to work. But the Purdue Model itself has not stood still, and understanding how it has evolved is essential for teams operating in environments where IT and OT are no longer cleanly separate.

The Modern Evolution: IT/OT Convergence and Purdue 2.0

The Purdue Model has evolved from a 6-level architecture to a 7-level model with Level 3.5 as a mandatory security control. Security architects now refer to this as "Purdue 2.0," representing adaptation rather than replacement. The hierarchical segmentation principle combined with the Level 3.5 iDMZ remains the most operationally validated approach for protecting physical industrial processes.

For security teams managing these increasingly converged environments, cross-environment visibility becomes essential for finding threats that traverse IT/OT boundaries and correlating suspicious activity across endpoints, identities, and network traffic.

Key Takeaways

The Purdue Model remains the federally endorsed reference architecture for ICS network segmentation, organizing industrial environments into hierarchical levels with enforced trust boundaries. The Industrial DMZ at Level 3.5 is now mandatory for any connected OT environment. 

Implementation succeeds or fails based on enforcement, not design: validate firewall rules against actual traffic, terminate all remote access in the DMZ, and deploy ICS-aware security controls. With ransomware present in 44% of breaches and manufacturing the most-targeted industry for five consecutive years, Purdue-based segmentation is not optional.

FAQs

What is the Purdue Model?

The Purdue Enterprise Reference Architecture (PERA), commonly called the Purdue Model, is a hierarchical framework that segments industrial control system (ICS) networks into distinct functional layers, from physical processes at Level 0 to enterprise IT and external networks at Levels 4 and 5. 

Developed at Purdue University in 1991, it was originally designed for computer-integrated manufacturing and has since become the standard reference architecture for ICS security, actively endorsed by CISA, NIST, and the Department of Defense.

Is the Purdue Model still relevant in 2025, or has zero trust replaced it?

The Purdue Model remains actively endorsed by CISA, NIST, and the DoD as of 2025. Zero trust complements it rather than replacing it. CISA's 2025 guidance and the DoD's Zero Trust for OT documentation both position zero trust as an enhancement applicable at Level 3.5 and above. 

Levels 0 through 2 typically cannot support identity-based controls, making network segmentation the primary protection mechanism for physical process control.

What is the difference between the original Purdue Model and the Extended Purdue Model?

The original 1991 model defined six levels (0 through 5) for computer-integrated manufacturing data flows. The Extended Purdue Model adds Level 3.5, the Industrial DMZ, as a mandatory buffer zone between OT (Levels 0 through 3) and IT (Levels 4 and 5). 

The DOE developed this extension specifically because IT/OT convergence made the original boundary insufficient. Every current government recommendation treats Level 3.5 as essential.

How does the Purdue Model map to ISA/IEC 62443?

ISA/IEC 62443 builds its zones and conduits security architecture directly on the Purdue Model's hierarchical levels. Each Purdue level maps to a security zone with defined Security Levels (SL 1 through 4), ranging from basic protection to defense against sophisticated, state-sponsored attacks. 

Conduits connecting zones must be secured to the same criticality as the most trusted zone they connect. This mapping gives security teams an auditable, standards-aligned architecture for ICS compliance assessments and regulatory reviews.

Why is Level 2 considered the most significant security gap in ICS environments?

Level 2 contains SCADA systems and HMIs that run Windows-based operating systems while maintaining direct command authority over Level 1 PLCs. This makes them vulnerable to standard IT attack techniques and simultaneously capable of commanding physical processes. 

Because Level 2 often becomes the pivot point between enterprise compromise and physical process impact, it frequently represents the highest-leverage monitoring and access-control gap in real plants.

What is the single most common Purdue Model implementation failure?

Deploying VLANs without enforcing inter-VLAN access controls. CISA's proactive threat hunts documented organizations with properly separated IT and SCADA VLANs but no firewall rules between them, allowing non-privileged IT users to reach critical SCADA networks. 

VLANs organize network traffic; they do not restrict it. Without corresponding firewall rules explicitly limiting inter-VLAN communication, an attacker who compromises the IT network can move freely into OT systems. VLAN segmentation alone provides no meaningful security boundary.