Opsio - Cloud and AI Solutions
AI7 min read· 1,669 words

What Is the Purdue Model? ICS Network Architecture Explained

Praveena Shenoy
Praveena Shenoy

Country Manager, India

Published: ·Updated: ·Reviewed by Opsio Engineering Team

Quick Answer

The Purdue Enterprise Reference Architecture is the foundational network model for industrial control system security. Developed at Purdue University in the...

The Purdue Enterprise Reference Architecture is the foundational network model for industrial control system security. Developed at Purdue University in the 1990s, it separates OT and IT networks into hierarchical levels that limit lateral communication and contain the spread of security incidents. With 96% of OT incidents originating from IT network compromises (Dragos, 2025), understanding and implementing Purdue-based segmentation remains one of the most impactful OT security controls available.

Key Takeaways
  • The Purdue Model divides industrial networks into 6 levels, from field devices to enterprise IT.
  • Each level communicates only with adjacent levels, limiting lateral attack propagation.
  • Modern adaptations add cloud and remote access zones not covered in the original model.
  • DMZ between Level 3 and Level 4 is the most critical security boundary in most ICS environments.
  • Zones and conduits from IEC 62443 provide a more flexible modern alternative to rigid Purdue levels.
[INTERNAL-LINK: OT security services overview → /ot-security-services/]

What Are the Six Levels of the Purdue Model?

The Purdue Model organizes industrial and enterprise systems into six distinct levels. Level 0 contains physical process equipment: sensors, actuators, motors, and valves that interact directly with the physical world. Level 1 contains basic control devices: PLCs, RTUs, and safety instrumented systems that control Level 0 equipment. Level 2 contains supervisory control systems: HMIs, SCADA workstations, and engineering stations that provide operator visibility and control over Level 1 devices.

Level 3 contains manufacturing operations systems: manufacturing execution systems (MES), historians, batch management, and quality management systems. This is the highest level of the OT network. Level 3.5, sometimes called the Industrial DMZ, is not part of the original Purdue model but has become standard practice. It acts as a buffer zone between OT (Levels 0-3) and IT (Levels 4-5) networks, housing systems that need to communicate with both sides.

Level 4 is the business logistics network: enterprise IT systems including ERP, email, file servers, and business applications. Level 5 is the enterprise network providing connectivity to external networks and the internet. The fundamental security principle of the Purdue Model is that communication should flow only between adjacent levels, never jumping levels directly. Enforcing this principle through firewall rules and network architecture limits the blast radius of any single compromise.

[IMAGE: Layered diagram of Purdue Model showing all 6 levels with example systems at each level - search terms: Purdue model ICS levels diagram industrial network architecture]

Why Is the DMZ Between Level 3 and Level 4 So Critical?

The boundary between OT (Level 3) and IT (Level 4) is where 96% of OT incidents cross. A properly designed DMZ at this boundary is the single most impactful architectural control in most industrial security programs. The DMZ hosts proxy services, data historians, and application servers that broker communication between OT and IT systems without allowing direct network connections to cross the boundary in either direction.

Data historians in the DMZ collect process data from OT systems and make it available to IT systems for analytics and reporting. This is a unidirectional data flow: OT pushes data to the historian, IT pulls data from the historian, but IT systems never connect directly to OT field devices. Implementing this pattern eliminates the most common attack path: an attacker who compromises an IT system cannot reach OT field devices directly if the DMZ is properly designed and enforced.

Firewall rules at the DMZ boundary must be explicit and minimal. Default-deny posture, where all traffic is blocked unless explicitly permitted, is the correct approach. Many organizations discover during assessments that their OT DMZ firewall rules have accumulated over years without cleanup, with overly permissive rules that effectively negate the DMZ's security value. Regular firewall rule reviews are a necessary maintenance activity for any OT DMZ.

[INTERNAL-LINK: IEC 62443 standard and zones/conduits → /knowledge-base/what-is-iec-62443-standard/]
Free Expert Consultation

Need help with cloud?

Book a free 30-minute meeting with one of our cloud specialists. We'll analyse your situation and provide actionable recommendations — no obligation, no cost.

Solution ArchitectAI ExpertSecurity SpecialistDevOps Engineer
50+ certified engineers4.9/5 customer rating24/7 support
Completely free — no obligationResponse within 24h

What Are Zones and Conduits, and How Do They Differ from Purdue Levels?

IEC 62443 introduces zones and conduits as a more flexible alternative to the strict Purdue level hierarchy. A zone is a logical grouping of assets that share a common security level requirement and are subject to the same security policy. A conduit is a defined communication path between zones, with specific security controls applied to the traffic that flows through it. This approach accommodates the reality that OT networks rarely map cleanly onto the six Purdue levels in practice.

The zones and conduits model is better suited to modern OT environments. Cloud connectivity, remote access aggregation points, mobile operator interfaces, and IoT-enabled field devices all fit awkwardly into the Purdue hierarchy. They fit more naturally into a zones model where each logical grouping of assets is defined by function and security requirement, with explicitly defined and controlled communication paths between groups.

Zones and conduits also scale to multi-site environments. A single Purdue model describes one facility. The zones and conduits model can describe security requirements across an entire enterprise, with site-specific zone definitions and enterprise-level conduit requirements for inter-site communication. This enterprise applicability is one reason IEC 62443 zones and conduits have become the preferred architecture vocabulary for large industrial organizations.

[CHART: Comparison diagram - Purdue Model 6-level hierarchy vs IEC 62443 zones and conduits model - source: IEC 62443-3-3]

How Has the Purdue Model Adapted for Cloud and Remote Access?

The original Purdue Model, developed in the 1990s, did not anticipate cloud connectivity, mobile devices, or the scale of remote access that modern industrial operations require. Industry practitioners have developed adaptations that extend the Purdue Model with new zones. A cloud connectivity zone handles data flows between OT historians and cloud analytics platforms, with controls ensuring that cloud-to-OT commands are prohibited while OT-to-cloud data flows are permitted and monitored.

A remote access aggregation zone consolidates all external remote access sessions before they reach OT networks. This zone houses jump servers, privileged access workstations, and session recording infrastructure. Remote users, whether employees working from home or vendors performing maintenance, connect to this zone first. From there, session-specific, time-limited access to specific OT assets is granted. This architecture makes all remote access visible, auditable, and controllable from a single point.

Some practitioners refer to the modern, extended Purdue Model as the "ISA-99 reference architecture" after the ISA committee that produced IEC 62443. Others simply acknowledge it as "Purdue-inspired" rather than strictly Purdue. The underlying principle, hierarchical segmentation with controlled inter-zone communication, remains valid and is the right starting point for any OT network architecture design.

[IMAGE: Modern extended Purdue model diagram with cloud zone and remote access zone added - search terms: modern Purdue model cloud remote access OT architecture]

What Are Common Purdue Model Implementation Mistakes?

The most common implementation mistake is building the architecture on paper without enforcing it in practice. Organizations that document a Purdue-based design but allow exceptions for operational convenience, a laptop that bypasses the DMZ here, a vendor VPN that connects directly to Level 2 there, create a model that exists only in documentation. Regular network architecture audits that compare actual traffic flows against the documented model are essential for maintaining implementation integrity.

Over-trusting internal zones is another frequent error. The Purdue Model defines inter-level boundaries but does not mandate intra-level segmentation. In practice, flat Level 2 networks where all HMIs, PLCs, and engineering workstations share a single segment allow lateral movement within the OT zone once an attacker crosses the Level 3-to-Level 2 boundary. Micro-segmentation within Purdue levels is increasingly recognized as necessary for mature OT security programs.

Finally, neglecting the physical layer undermines network architecture controls. A properly segmented network is bypassed entirely when a technician connects a laptop to a field device via serial cable, or when a USB drive is inserted into a control room workstation. Physical security controls, including locked equipment rooms, USB port restrictions, and visitor escort policies, must complement network architecture to prevent out-of-band access that bypasses segmentation entirely.

Frequently Asked Questions

Is the Purdue Model still relevant in 2026?

Yes, with adaptations. The core principle of hierarchical segmentation with controlled inter-level communication remains highly relevant and widely applied. The specific six-level structure requires extension to accommodate cloud connectivity, mobile access, and modern remote operations patterns. IEC 62443 zones and conduits provide a more flexible framework for modern environments, but the Purdue Model remains the most widely understood reference architecture in industrial cybersecurity.

Can the Purdue Model be applied to legacy OT environments?

Yes, though it requires pragmatic adaptation. Legacy environments with flat networks and limited device management capabilities can be progressively segmented by adding firewalls and DMZ infrastructure around existing device groups rather than requiring device-level changes. The goal is improving the security of existing assets through architectural controls, without requiring those assets to be replaced. Even partial Purdue implementation significantly reduces attack surface compared to a completely flat network.

What is the difference between a DMZ and a conduit in OT networking?

A DMZ (demilitarized zone) is a network segment that sits between two security boundaries, typically between OT and IT networks, hosting systems that need to communicate with both sides. A conduit in IEC 62443 terms is a logical communication path between two zones, including all the security controls that govern traffic on that path. A DMZ is a physical/logical network construction; a conduit is an architectural concept that may or may not be implemented as a DMZ, depending on the technology used.

Conclusion

The Purdue Model has provided the foundational vocabulary and architecture for ICS network security for over three decades. Its core principle, that OT and IT systems should be separated into layers with controlled inter-level communication, remains the most impactful architectural control available for reducing OT security risk. Modern adaptations for cloud, remote access, and mobile operations extend its applicability without abandoning its foundational logic.

For organizations building or reviewing their OT network architecture, the Purdue Model combined with IEC 62443 zones and conduits provides a comprehensive framework. Opsio's OT security services include network architecture review and design as a core capability for industrial environments.


Author: Opsio Security Practice | Published: April 2026 | Last updated: April 2026

Written By

Praveena Shenoy
Praveena Shenoy

Country Manager, India at Opsio

Praveena leads Opsio's India operations, bringing 17+ years of cross-industry experience spanning AI, manufacturing, DevOps, and managed services. She drives cloud transformation initiatives across manufacturing, e-commerce, retail, NBFC & banking, and IT services — connecting global cloud expertise with local market understanding.

Editorial standards: This article was written by cloud practitioners and peer-reviewed by our engineering team. We update content quarterly for technical accuracy. Opsio maintains editorial independence.