In the dynamic world of cyber security, where new technologies and threats emerge almost daily, relying on a concept developed in the 1990s may seem foolhardy, to say the least. And yet, the Purdue Enterprise Reference Architecture (PERA) Model still remains the absolute foundation on which mature industrial network (OT) security strategies are built. Its strength lies not in a rigid, technological implementation, but in a timeless philosophy that teaches how to logically organize and isolate risk in a complex production environment.
The problem is that many organizations have either forgotten about it or are trying to apply it in a literal way, which in the era of Industry 4.0, the cloud and the Industrial Internet of Things (IIoT) is doomed to failure in advance. The modern connected factory is no longer a simple physical hierarchy that can be easily drawn on a diagram. It is a complex ecosystem with data flowing in many directions. The key to success, then, is not to reject the Purdue Model, but to evolve it wisely - moving from a physical to a logical interpretation of its principles and reinforcing it with modern paradigms such as Zero Trust.
Shortcuts
- What is the Purdue Model and why has it become the foundation of OT security?
- What are the different levels of the Purdue Model and what are they responsible for?
What is the Purdue Model and why has it become the foundation of OT security?
The Purdue model is a conceptual framework that divides the entire infrastructure of an industrial enterprise into logical, hierarchical levels - from sensors and actuators on the shop floor to business systems and Internet connectivity. Its main goal is to create a structured architecture that allows for logical grouping of resources with similar functions and security requirements and, most importantly, tight control over the flow of information between these levels.
Its fundamental importance for OT security stems from the fact that it was the first to introduce the formal concept of segmentation and defense-in-depth into the industrial world. Instead of treating the entire network as a single, flat monolith, the Purdue Model imposes zoning on it. The philosophy is simple: even if an attacker compromises one less-critical level (e.g., the office network), properly designed boundaries between levels should prevent him from easily penetrating lower and more critical levels (e.g., process control systems).
It is this idea of creating barriers and controlled transition points that has made this model so important. It provides security architects and network engineers with a clear, logical blueprint for designing resilient networks in which risks are isolated and managed in a granular way. It is a map to bring order to the chaos of complex industrial systems.
📚 Read the complete guide: Cloud Security / AWS: Bezpieczeństwo chmury publicznej - AWS, Azure, best practices
What are the different levels of the Purdue Model and what are they responsible for?
The Purdue model defines a hierarchy consisting of six main levels, numbered from 0 to 5. Each level represents a specific functional area, from direct interaction with the physical world to strategic business management. Understanding the role of each level is key to properly implementing segmentation.
The structure, going from the bottom, is as follows: Level 0 (Physical Process) is the foundation of everything - the sensors, actuators, motors and other devices that do the physical work. Level 1 (Basic Control) contains the “brains” of the machines, namely PLCs (Programmable Logic Controllers) and PIDs, which make decisions and send commands based on readings from Level 0. Level 2 (Area Supervision) is the domain of operators - SCADA systems and HMI panels that allow monitoring and control of individual cells or production lines.
Above that is Level 3 (Plant Operations Management), where systems that optimize the operation of the entire factory, such as production management systems (MES) and historical databases (historians), operate. Levels 0 through 3 together form the world of operational technology (OT). Level 4 (Logistics and Business Planning) and Level 5 (Corporate Network), on the other hand, are already the domain of information technology (IT). ERP systems, file servers, email and Internet connectivity can be found here.
The Purdue Model Hierarchy: From the Sensor to the Cloud
| Level | Name | Example systems | Domain |
|---|---|---|---|
| 5 | Corporate network | Internet, Cloud, corporate systems | IT |
| 4 | Logistics and planning | ERP servers, file and mail servers | IT |
| 3.5 | Industrial Demilitarized Zone (IDMZ) | Intermediary servers, firewalls | IT/OT border |
| 3 | Management of plant operations | MES systems, Historian servers | OT |
| 2 | Area surveillance | SCADA systems, HMI panels | OT |
| 1 | Basic control | PLC, PID controllers | OT |
| 0 | Physical process | Sensors, actuators, motors | OT |
What is the Demilitarized Zone (IDMZ) and why is it a critical buffer between IT and OT?
As the need for data exchange between the IT and OT worlds grew, the original Purdue Model was supplemented with an absolutely key element - the Industrial Demilitarized Zone (IDMZ), placed at a logical Level 3.5. The IDMZ is a small, isolated network that acts as a secure buffer or lock, separating the trusted and sensitive OT network from the much less trusted IT corporate network.
No direct communication between a system on the IT network and a system on the OT network should be allowed. Any such connection must be terminated in the IDMZ on an intermediary server, and then a new, separate connection to the target network must be established from that server. All traffic passing through the IDMZ is subjected to rigorous inspection by firewalls, which only allow strictly defined and authorized communications through.
The role of the IDMZ cannot be overestimated. It acts like a buffer zone in an armed conflict - it is a neutral ground where controlled exchanges take place. Thus, even if an attacker compromises a server in the corporate IT network, he won’t have a direct path to attack SCADA systems in the OT network. He will have to push through the DMZ’s defenses first, which gives security teams extra time to detect and stop the attack.
How did the NotPetya attack prove the tragic price of ignoring segmentation?
The importance of network segmentation and DMZs is best illustrated by real-life disasters. In 2017, the world was shaken by the NotPetya ransomware attack. The malware, initially spread through an update mechanism for Ukrainian accounting software, infected hundreds of global corporations within hours, causing losses estimated at more than $10 billion.
Many of the affected companies are global manufacturing giants that fell victim to the lack of proper segmentation between IT and OT networks. The NotPetya attack started in office (IT) networks, but because there were no effective barriers (such as IDMZ), the malware was able to spread freely to production (OT) networks. As a result, not only computers in accounting departments were encrypted, but also HMI stations and SCADA servers controlling production.
The consequences were catastrophic. Entire factories, ports and production lines were disabled for days or even weeks. Companies that believed their industrial operations were secure found out painfully that in a flat, unsegmented network, it only takes one infected link in IT to cripple an entire global production chain. NotPetya has become tragic but extremely emphatic proof that the Purdue Model and its segmentation principles are not a theoretical concept, but an absolute business necessity.
Why is Purdue’s rigid hierarchy incompatible with the realities of Industry 4.0?
Despite its fundamental value, the classic, rigid interpretation of the Purdue Model faces serious challenges in the era of Industry 4.0. The model was designed for a world in which data flow was simple and strictly hierarchical - from the bottom up. Data from sensors flowed to controllers, from there to SCADA systems, and finally to business systems. Such an orderly, unidirectional flow is increasingly rare.
The modern factory is a complex, dynamic ecosystem. Intelligent sensors (IIoT) may need to send data directly to a cloud-based analytics platform (Level 5), completely bypassing the traditional hierarchy. A maintenance team may need remote access from the IT network directly to a Level 1 PLC for diagnostics. A third-party vendor may need to connect to its cloud platform to monitor machine health.
These new, non-hierarchical data flows make rigid adherence to physical segmentation into six separate levels impractical and stifle innovation. Trying to force modern technologies to operate within a 30-year-old, rigid model is like trying to fit a jet engine into the body of a horse-drawn carriage. It is this incompatibility that causes many companies to either abandon the Purdue Model altogether or ignore new connections, creating dangerous holes in the architecture.
How are cloud and IIoT blurring the traditional boundaries between levels?
Technologies such as cloud computing and the Industrial Internet of Things (IIoT) are major factors deconstructing the classic hierarchical model. Cloud platforms, offered by vendors such as Microsoft Azure and Amazon Web Services, are becoming the de facto new top level of architecture, often referred to as Level 6. This is where huge sets of data from production go for analysis and machine learning.
IIoT devices are blurring the boundaries in even more radical ways. A modern smart valve can be simultaneously a Level 0 (physical component), Level 1 (has built-in control logic) and Level 5 (communicates directly with the cloud via a cellular network) device. Where in the Purdue hierarchy to put such a device? The answer is: nowhere. It just doesn’t fit into this model.
This blurring of boundaries means that the attack surface is expanding dramatically. The boundary between the secure “inside” and the untrusted “outside” no longer exists. Any IIoT device with cloud access is a potential entry point into the network. Therefore, relying solely on perimeter defense becomes ineffective. Security must move closer to the protected assets.
Is the Purdue Model obsolete, or just a physical interpretation of it?
In the face of these challenges, a key question arises: does this mean that the Purdue Model is dead and should be abandoned? Absolutely not. Only its rigid physical interpretation, which assumes the existence of six separate physical networks, has become obsolete. However, the fundamental philosophy of the Purdue Model is more relevant today than ever before.
Its timeless value lies in the concept of functional segmentation and risk isolation. Regardless of what your data flows look like, it is still true that a PLC is more critical and requires a higher level of protection than an office workstation. It is still true that resources with similar security requirements should be grouped and communications between these groups should be controlled.
The modern approach is to treat the Purdue Model not as a physical network plan, but as a logical risk map. Instead of building six physical networks, we define six (or more) logical security zones. Devices are assigned to these zones based on their function and criticality, not their physical location. And the boundaries between zones are enforced not by physical cables, but by intelligent rules on modern firewalls.
What is the evolution from physical to logical network segmentation?
The evolution we are talking about is a shift from thinking in terms of “where something is” (physical location) to thinking in terms of “what something is and what it can talk to” (logical function and policy). In the physical model, a device was secure because it was on a “secure” OT network. In the logical model, the security of a device depends on the security policies that are assigned to it, regardless of where it is located.
Logical segmentation is implemented using modern network technologies. Next-generation firewalls (NGFWs) can identify not only IP addresses, but also specific applications and industrial protocols (e.g. Modbus, S7). This allows the creation of very granular rules, e.g. “Allow engineering station X to communicate with PLC Y only via S7 protocol and only to upload new logic, and block all the rest.”
Techniques such as microsegmentation go a step further, allowing virtual security boundaries to be created around each individual device or small group of devices. In this way, even if two PLCs are on the same physical network, they can be logically isolated from each other and unable to communicate unless absolutely required by the process. This approach drastically limits an attacker’s ability to roam the network after gaining initial access.
How do Zero Trust principles modernize and strengthen Purdue’s philosophy?
The logical evolution of the Purdue Model dovetails perfectly with the state-of-the-art cyber security paradigm of Zero Trust (Never Trust, Always Verify). Traditional security models, including the classic Purdue, were based on trust - anything inside a “safe” zone was by definition trusted. Zero Trust rejects this concept. It assumes that a threat can come from anywhere, including inside the network, and that trust is a weakness.
The Zero Trust principle states that any attempt to access a resource - whether from the IT network, OT or the same segment - must be treated as potentially hostile. Each connection must be overtly authenticated (verifying the identity of the user or device) and authorized (verifying that it has the authority to perform that particular action). Access is granted on a minimum necessary privileges basis.
Combining Purdue’s philosophy with Zero Trust principles creates an extremely powerful defense architecture. Purdue provides a logical map of zones and criticality (I KNOW what I need to protect and how important it is). Zero Trust provides a mechanism for enforcing the boundaries between these zones (I KNOW how to do this in a granular and dynamic way). In this model, the IDMZ becomes not just a physical buffer, but a set of Zero Trust policies that verify every attempt at communication between the IT and OT worlds.
What technologies, like NGFW, allow flexible deployment of zones and channels?
Implementing logical segmentation and Zero Trust policies in an OT environment requires appropriate technologies. Next-generation firewalls (NGFWs), particularly their industrial counterparts (Industrial Firewalls), play a key role here. Unlike traditional firewalls, which filtered traffic based only on IP addresses and ports, NGFWs have deep packet inspection (DPI) capabilities.
With DPI, the firewall “understands” industrial protocols. It can distinguish between a safe temperature read command and an unsafe PLC stop command, even if both are sent to the same port. This allows the creation of extremely precise rules that minimize risk without blocking essential operational communications. What’s more, many industrial firewalls can operate in transparent mode, allowing them to be deployed on an existing network without changing the IP address.
Other important technologies include identity and access management (IAM) systems, which allow authentication and authorization policies to be enforced, and data diodes (data diodes). Data diodes are hardware devices that physically allow information to flow in only one direction. They are ideal for securely sending data from a sensitive OT network to a less secure IT network without any possibility of any traffic coming back the other way.
How to manage the flow of data between zones in modern architecture?
Managing data flows in an architecture based on the logical Purdue Model and Zero Trust principles requires moving away from simple “allow/block” rules to a more dynamic and contextual approach. The first step is to carefully map all required communication flows. IT and OT teams must jointly identify which systems need to communicate with each other, using which protocols and for what purpose.
Then, for each flow, define a security policy based on the principle of minimum privileges. If the historian server (Level 3) only needs to query the SCADA system (Level 2) for historical data, then only such communication should be allowed. Any other attempt to connect from the historian server to the SCADA system, such as an attempt to change its configuration, should be blocked and alerted.
It is also important to manage not only flows at the IT/OT border, but also within the OT network itself. Communication between different production lines (east-west segmentation) should be blocked by default and allowed only in exceptional, justified cases. Such granular control of flows is the foundation of stopping lateral traffic and minimizing the impact of a possible incident.
Where to put a historian server or IIoT platform in a modern model?
In the classic, rigid Purdue Model, the placement of systems such as a historian server or IIoT platform was problematic. The historian server, which needs to communicate with both SCADA systems (Level 2) and analysts on the corporate network (Level 4), was usually placed at Level 3. IIoT platforms, which communicate with the cloud, did not fit into this scheme at all.
In the modern logical model, the answer is much simpler: we place them in a dedicated logical zone, which has well-defined access policies. A historian server can be in a DMZ (Level 3.5) or in a separate analysis zone. The most important thing is that the policies on the firewalls precisely define what it can talk to. It should be allowed to initiate “downstream” calls to SCADA systems for data collection and to accept “upstream” calls from authorized analysts.
Similarly, the IIoT platform that aggregates sensor data should be placed in its own isolated zone. IIoT sensors should be able to send data only to this platform and nowhere else. That platform, in turn, should have tightly controlled access to the cloud for data synchronization. The key is not physical location, but logical isolation and enforcement of security policies on all communication channels.
What role does Purdue’s philosophy play in building a resilient OT architecture in 2025?
Against all odds, in 2025 the role of the Purdue Model philosophy is more important than ever. In a world of increasing complexity, convergence and blurring boundaries, it provides an extremely valuable map and common language to bring order to the chaos. It is a mental framework that allows architects, engineers and managers to think about risk and segmentation in a coherent way.
Its real strength no longer lies in drawing rigid physical boundaries, but in providing a logical model for classifying the criticality of assets. Identifying which systems belong to Level 1 and which to Level 3 is the foundation for further risk analysis and the creation of adequate security policies. Purdue’s philosophy teaches us that not all systems are created equal and that the heart of the production process requires the strongest protection.
Combined with modern technologies, such as NGFW, and modern paradigms, such as Zero Trust, Purdue’s philosophy becomes a powerful tool for building realistically resilient industrial architectures. It preserves the fundamental principles of risk isolation in an inherently connected world. Thus, it is not an obsolete relic, but a battle-tested compass that continues to reliably point the way in a new and complex threat landscape.
Related Terms
Learn key terms related to this article in our cybersecurity glossary:
- Network Security — Network security is a set of practices, technologies, and strategies aimed at…
- CSPM (Cloud Security Posture Management) — CSPM (Cloud Security Posture Management) is a category of cloud security tools…
- Cybersecurity — Cybersecurity is a collection of techniques, processes, and practices used to…
- Firewall — A firewall, also known as a network firewall or security barrier, is a security…
- Cybersecurity Incident Management — Cybersecurity incident management is the process of identifying, analyzing,…
Learn More
Explore related articles in our knowledge base:
- Zero Trust in the Factory: Can the
- Dell PowerStore Prime 4.0: Breakthrough in IT Infrastructure
- FortiGate Cloud-Native Firewall - Cloud security and a new paradigm in firewalls
- FortiGate NGFW: Next-Generation Network Protection
- The SASE revolution: FortiSASE’s approach to secure access to edge services
Explore Our Services
Need cybersecurity support? Check out:
- Security Audits - comprehensive security assessment
- Penetration Testing - identify vulnerabilities in your infrastructure
- SOC as a Service - 24/7 security monitoring
Explore Our Products
Solutions mentioned in this article that can help protect your organization:
- Dell PowerStore — Dell Technologies
- FortiGate Cloud-Native Firewall — Fortinet
- FortiGate — Fortinet
Cybersecurity for Your Industry
Learn more about cybersecurity in your industry:
