The Purdue Enterprise Reference Architecture, developed in the 1990s at Purdue University, has been the foundational model for industrial control system network architecture for over three decades. Its hierarchical structure - from Level 0 physical processes through to Level 5 enterprise networks - provides a conceptual framework that remains valuable for understanding how industrial systems should be organised and protected. However, the operational technology landscape has evolved dramatically since the Purdue Model was conceived. Cloud services, remote work requirements, advanced threat actors, and converged IT/OT environments create challenges that the original model did not anticipate. This does not mean the Purdue Model should be abandoned - rather, it needs thoughtful adaptation to remain relevant while preserving its core principles of defence in depth and segmentation between trust zones.
The Enduring Value of Hierarchical Architecture
Before discussing adaptations, it is worth understanding why the Purdue Model has endured. The fundamental insight - that industrial systems should be organised into hierarchical levels with controlled boundaries between them - remains sound. Level 0 and Level 1 contain the physical processes and basic control systems that must operate reliably and safely. Level 2 encompasses supervisory systems like HMIs and engineering workstations. Level 3 houses site operations systems including historians and asset management. The boundaries between these levels represent trust transitions where traffic should be controlled and inspected. This hierarchy maps to operational realities. Engineers working at Level 2 need different access than operators at Level 1. Enterprise applications at Level 4 need data from historians at Level 3, but should never communicate directly with PLCs at Level 1. The Purdue Model makes these relationships explicit and provides a shared vocabulary for discussing OT network architecture. Even as we adapt the model, these principles remain essential for protecting industrial systems.
The Level 3.5 DMZ: Bridging IT and OT
The most significant adaptation to the traditional Purdue Model is the formalisation of a demilitarised zone between the OT network (Levels 0-3) and the IT network (Levels 4-5). Often called Level 3.5, this DMZ serves as a mediation point where data can be exchanged without allowing direct connectivity between enterprise systems and control networks. A well-designed Level 3.5 DMZ hosts services that need to span both worlds: historian replicas that receive data from Level 3 historians and make it available to Level 4 applications, jump servers that provide controlled access for remote support, and security services like log collectors and patching infrastructure. The critical principle is that traffic crossing the DMZ should be application-specific, inspected, and logged. No direct routing should exist between IT and OT networks - a ll legitimate traffic flows through explicit application gateways. Implementing this architecture requires careful collaboration between IT and OT teams to understand data flow requirements and design appropriate controls. The result is a security architecture that enables necessary business functions while maintaining strong separation between operational and enterprise networks.
Cloud Connectivity Patterns
Cloud services present a significant challenge to traditional Purdue architecture. Vendors increasingly offer cloud-based analytics, predictive maintenance, and remote monitoring services that require connectivity from OT environments to cloud platforms. Simply extending the Purdue Model upward to a 'Level 6' cloud does not address the security concerns - the real question is how cloud connectivity should be mediated. The preferred approach treats cloud connectivity as an extension of the Level 3.5 DMZ concept. Data destined for cloud services should be staged in the DMZ, where it can be validated, filtered, and transmitted through controlled egress points. Cloud-originated traffic should never flow directly into OT networks; instead, it should be received by DMZ systems that can apply appropriate validation before forwarding sanitised data to Level 3 systems. For organisations with higher security requirements, data diodes provide one-way data transmission that physically prevents inbound traffic from cloud environments. While this limits functionality - bidirectional communication with cloud services becomes impossible - it provides strong assurance that cloud connectivity cannot be leveraged for attacks against OT networks. The appropriate architecture depends on risk tolerance and operational requirements.
Secure Remote Access Architecture
Remote access to OT environments has become a necessity rather than an exception, accelerated by the pandemic but driven fundamentally by the need for specialist support and efficient operations across geographically distributed assets. The Purdue Model's original conception did not anticipate personnel routinely accessing Level 2 systems from home offices or vendor support connecting to PLCs from overseas. Modern remote access architecture for OT environments should follow several key principles. First, remote access should always terminate in the Level 3.5 DMZ, never directly into OT networks. Jump servers or privileged access management (PAM) solutions provide controlled access points where authentication, authorisation, and session recording can be enforced. Second, connections should be session-based and time-limited rather than persistent - vendor access for a specific maintenance window, not standing VPN connections. Third, multi-factor authentication is essential, and network-based controls should restrict what systems each user can access based on their role and the current authorisation. Organisations should also consider the distinction between read-only access (viewing HMI screens for monitoring) and interactive access (making configuration changes). The risk profiles differ significantly, and access controls should reflect this distinction.
Micro-Segmentation Within Levels
Traditional Purdue implementations focused on segmentation between levels - controlling traffic as it crossed from Level 2 to Level 3, for example. Modern threats, particularly ransomware, have demonstrated the importance of limiting lateral movement within levels as well. An attacker who compromises one Level 2 workstation should not automatically have access to every other system at that level. Micro-segmentation applies zero-trust principles within OT networks, restricting traffic flows to only those required for operational purposes. Software-defined networking technologies like Cisco ACI or VMware NSX can implement micro-segmentation policies that would be impractical with traditional VLAN-based approaches. For OT environments specifically, host-based firewalls on Windows systems and network-based controls for devices that do not support host security provide complementary enforcement points. Implementation requires detailed understanding of traffic flows, which is often more complex than IT environments due to proprietary protocols and legacy systems. Passive network monitoring tools can help establish baseline communication patterns before implementing restrictive policies. The goal is to reduce blast radius - when a compromise occurs, limiting how far it can spread before detection and response.
Conclusion
The Purdue Model remains valuable as a conceptual framework for OT network architecture, but it requires adaptation to address modern operational requirements and threat landscapes. The Level 3.5 DMZ, secure remote access architecture, cloud connectivity patterns, and micro-segmentation all extend the model's core principles to contemporary challenges. Organisations should view the Purdue Model as a foundation to build upon rather than a rigid prescription, adapting it to their specific operational and security requirements while preserving its fundamental insight: hierarchical architecture with controlled boundaries provides defence in depth for industrial control systems.
