What Is the Purdue Model for ICS Security? | A Guide to PERA

How does the Purdue Model for ICS Security work?

The Purdue Model for industrial control systems (ICS) security works by dividing an industrial control system into multiple layers, each with specific roles and communication boundaries.

The model is designed to isolate different parts of an organization’s operations. Today, it’s adapted to limit network exposure and improve control over both OT and information technology.

At its core, the Purdue Model segments the network into levels, ranging from 0 to 5:

• Levels 0 to 3 represent the OT side, which is responsible for the actual physical processes, such as manufacturing equipment, sensors, and real-time control systems.
• Levels 4 and 5 represent the IT side, including enterprise systems like databases, planning, and data analysis.

When applied correctly, the model creates separation between ICS/OT and IT systems. The isolation allows organizations to enforce strong access controls without impacting business operations.

For example: Today, a key aspect of the Purdue Model is the implementation of firewalls between Levels 3 and 4, which separate the OT and IT environments. The firewall prevents direct communication between the two environments, reducing the risk of unauthorized access or cyberattacks affecting critical industrial processes.

Also, the Purdue Model emphasizes the use of DMZs (demilitarized zones) at key junctions in the network—particularly between the OT and IT layers. DMZs effectively work as a buffer zone. So data can flow between systems, but with filtering and monitoring in place to ensure security protocols are followed.

Like this:

By clearly defining and segmenting the different layers of ICS and IT systems, the Purdue Model offers a structured approach to managing both operational efficiency and cybersecurity. 

While it was originally designed as an architecture framework, it’s since become an influential tool for delineating where to implement security controls and monitor for threats effectively.

• What Is OT Security?
• What Is IT/OT Convergence?
• What Are the Differences Between OT, ICS, & SCADA Security?
• What Is the Difference Between IT and OT? | IT vs. OT

What are the Purdue Model layers?

As noted, the Purdue Model organizes industrial networks into distinct layers representing different functions. 

Specifically, the model clearly defines which devices and systems reside within particular points, and what their role is in the overall architecture. 

Each layer separates critical systems and processes.

Let’s break down each one.

Level 0 - Physical process

At the foundation of the Purdue Model, we have Level 0, which includes the actual physical devices like sensors and actuators.

These devices gather and relay data about the process in real time, including things like pressure, temperature, or flow rates.

Devices interact directly with the process, feeding crucial information to the controllers in the next layer. Since these devices are critical for operational data, they’re highly vulnerable to direct physical attacks or system faults.

Level 1 - Intelligent devices

The next layer, Level 1, consists of intelligent devices, which monitor and manage the physical processes.

This includes systems like programmable logic controllers (PLCs) and remote terminal units (RTUs), which are essential for interpreting data from Level 0 and executing commands to maintain safe and efficient operation.

While crucial to maintaining control, their age and limited computing power can make them vulnerable to cyberattacks.

Level 2 - Local control and supervision

Level 2 involves the supervisory control and monitoring systems, such as HMIs (human machine interfaces) and SCADA (supervisory control and data acquisition) systems.

Operators use these components to oversee the process, manage alarms, and make real-time adjustments.

Level 2 is responsible for controlling specific sections of the facility. It acts as a link between human operators and automated systems.

Level 3 - Site-wide control and management

At Level 3, we have site-wide control systems, which support larger operations across the plant or site.

Systems like historians, alarm servers, and plant-level analytics are found here.

Level 3 typically handles broader functions like production scheduling and operational analysis. It serves as the first line of defense in the transition between the process control environment and the IT network.

Level 3.5 - Demilitarized zone (DMZ)

Although not originally part of the Purdue Model, the introduction of Level 3.5, or the DMZ, is considered essential for modern ICS security.

The DMZ acts as a buffer zone between the IT and OT environments. It regulates and filters traffic between the two areas. Its primary role is to protect critical OT systems from unauthorized access while still allowing necessary data flow to and from enterprise networks.

Level 4 - Business logistics systems

Level 4 focuses on the business side of operations, including business logistics systems such as ERP (enterprise resource planning), CRM (customer relationship management), and other systems crucial for business operations.

These systems connect to the broader enterprise network. Data from the industrial environment is integrated here to aid in decision-making and planning.

Level 5 - Enterprise network

At the top of the Purdue Model is Level 5, which handles overall corporate IT functions, like email, file storage, and other enterprise services.

This level typically has no direct contact with the industrial control system components but may request data from lower levels for business analytics. Level 5 is the most removed from the operational aspects of ICS but critical for supporting business operations.

What are industrial control systems?

To better understand how the Purdue Model applies to securing critical infrastructure, let’s walk through what industrial control systems actually are and how they work.

Industrial control systems manage and automate operational processes across numerous industries, including manufacturing, energy, and transportation. Essentially, ICSs are composed of devices, systems, networks, and controls used to operate and/or automate industrial processes.

At the core of an ICS, you'll find the controllers mentioned earlier, like PLCs or RTUs that direct processes based on sensor inputs and pre-defined conditions. As explained, controllers execute commands that adjust machinery and production processes so that operations run smoothly and efficiently.

ICSs work by collecting data from the field via sensors that monitor physical process variables (like temperature, pressure, etc.), process the data, and trigger actions to control equipment. 

Essentially, ICSs maintain optimal conditions for industrial operations. They’re designed to manage everything from assembly lines to power generation with precision and reliability.

Here’s why this matters.

The automation provided by ICSs increases productivity and safety—but it also plays a crucial role in critical infrastructure sectors, including:

• Energy
• Water and wastewater systems
• Transportation
• Manufacturing
• Food and agriculture
• Healthcare

So by automating routine tasks and responses, ICSs minimize human errors, reduce operational costs, and increase the overall efficiency of industrial operations.

Originally, ICSs were isolated systems. But with advancements in technology, they’ve become more interconnected with business networks and the internet. Which does increase efficiency but also exposes them to cybersecurity risks.

Modern ICSs integrate sophisticated cybersecurity measures to mitigate risks and ensure continuous, safe operations.

How are industrial control systems different from general computing systems?

Industrial control systems differ from general computing systems because they’re designed to control and monitor physical processes in real time, while general computing systems handle data processing and software applications.

As explained, ICSs include components like PLCs, which control equipment and processes. These controllers execute the instructions for keeping the machinery running smoothly. Basically, ICSs work in the background to automate physical processes.

General computing systems, on the other hand, are typically more versatile, able to run a range of software for different purposes—but they aren’t built for controlling industrial equipment.

Here’s where the Purdue Model provides structure. 

By segmenting industrial and general computing systems into distinct layers, the model ensures that these fundamentally different systems can coexist without compromising operational efficiency or safety.

The segmentation reduces the likelihood of delays or disruptions in ICS processes because it minimizes interference by isolating real-time systems from general computing activities.

Here's another key difference: ICSs work in real time. Which means they need to respond to changes immediately to keep things running. If an ICS fails to act on time, it could lead to safety issues or operational downtime. 

The Purdue Model addresses this challenge by maintaining strict boundaries between IT and OT systems, using security tools to regulate communication and protect critical real-time processes from interference.

While modern business environments also demand real time, fast processing to avoid delays and financial losses, the stakes are different for ICSs. When it comes to an industrial control system, delays can lead to immediate physical risks, such as equipment damage or safety hazards. Which are more critical than the financial or operational setbacks caused by slow general computing systems.

Also, industrial control systems often operate in harsh environments. They might be exposed to high temperatures, dust, or electromagnetic interference. For this reason, they’re built to withstand these conditions. General computing systems usually don’t need the same level of protection since they’re used in cleaner environments, like offices or homes.

Plus: ICSs have unique security needs. Again, a breach in an ICS system could lead to disruptions in power grids, manufacturing lines, or water treatment plants—posing real-world risks. General computing systems, while still vulnerable to cyberattacks and their consequences, don’t typically pose the same level of physical danger when compromised.

The Purdue Model’s layered structure ensures not only the protection of ICS components but also operational continuity, enabling secure communication between IT and OT without compromising either system.

What are the main ICS architecture security challenges?

Industrial control systems face unique security challenges due to their purpose, structure, and the environments in which they operate, including but not limited to:

• Real-time operational demands
• Outdated infrastructure
• Environmental constraints
• Proprietary systems and protocols
• Lack of cybersecurity expertise in ICS environments

Unlike general IT systems, ICSs manage real-time processes that effectively power industries like manufacturing, energy, and utilities. Which adds several layers of complexity to securing these environments.

It’s worth noting: The Purdue Model provides a foundational blueprint for addressing a lot of the challenges listed below.

Let’s take a look at ICS architecture security challenges in detail.

Real-time operational demands

One of the main challenges with ICS security is the real-time operational requirements. ICS environments control physical processes that cannot afford delays.

For example: If an ICS is responsible for regulating the temperature of machinery or controlling a power grid, any latency or disruption could cause damage to equipment, loss of production, or even endanger public safety.

Security measures, like updates or scans, could potentially interfere with real-time demands. And that makes introducing security solutions more complex than in traditional IT systems.

Outdated infrastructure

Many ICSs still run on legacy infrastructure that wasn’t built with modern cybersecurity in mind.

When industrial control systems were originally designed, they were isolated from the internet and often physically separated from external threats.

However: As organizations increasingly connect ICSs to their corporate networks for remote monitoring and management, the outdated infrastructure presents major vulnerabilities.

Legacy systems often don’t support modern security protocols or patches. And retrofitting them with cybersecurity measures can be difficult, costly, or impossible without replacing the entire system.

Environmental constraints

As explained, industrial environments are often harsh—electrically noisy, dirty, or subject to extreme temperatures. And these kinds of physical conditions definitely impact how security solutions can be deployed.

Network security tools, like firewalls or intrusion detection systems, are typically designed for cleaner, more controlled environments if they’re hardware-based. Which makes them harder to implement in ICS settings.

Not to mention, the need for uninterrupted service in these environments means there’s very little room for downtime. And that makes regular security maintenance or updates difficult.

Proprietary systems and protocols

ICS environments are built using a wide variety of proprietary systems and communication protocols. Which means applying standardized security practices is no easy feat.

Each vendor may use its own software, hardware, and network protocols, which complicates integration with existing security tools.

Also: Many ICS protocols—like Modbus or DNP3—were designed with functionality, not security, in mind. As a result, protocols often lack features like encryption or authentication.

Lack of cybersecurity expertise in ICS environments

Another significant challenge is the gap in cybersecurity knowledge among ICS professionals.

ICS environments are typically managed by engineers and operators who specialize in controlling physical processes but may not have cybersecurity expertise.

Conversely, cybersecurity professionals may not fully understand industrial processes.

This divide can lead to misaligned priorities, where keeping the system running efficiently is prioritized over implementing robust security practices.

The Purdue Model’s layered structure can work as a guide for tackling the unique technology challenges of ICS environments.

While the Purdue Model cannot solve all challenges outright, its emphasis on network segmentation and controlled interactions can offer a starting point for designing an effective ICS security strategy.

What kinds of cyberthreats commonly impact ICS?

ICS cyberthreats continue to grow in frequency and sophistication.

These systems, once isolated from external networks, are now more interconnected than ever, making them vulnerable to a variety of cyberattacks.

While industrial control systems have made great strides in operational efficiency, they now face many cybersecurity challenges.

This is where the Purdue Model for ICS security is often considered particularly relevant.

The model provides a template for identifying where specific threats are most likely to occur. It also helps determine the appropriate defenses for each layer.

Let's explore some of the most prominent threats that ICS environments are up against, including:

• Indirect attacks on ICSs
• Direct attacks targeting ICS components
• Denial of service (DoS) attacks
• Manipulation of data and commands
• Vulnerabilities in outdated systems

Indirect attacks on ICS

Many ICS cyberattacks are indirect, meaning they often target IT systems but ultimately affect the OT side. 

For instance, malware designed for general-purpose computing environments, like Windows, can penetrate the corporate IT network and later find its way to ICS systems.

Example: NotPetya (2017) is another prominent case where malware, initially targeting IT environments, caused widespread disruption to OT operations. This ransomware spread through corporate networks and indirectly affected critical infrastructure sectors, highlighting how vulnerabilities in IT can cascade into OT environments.

Direct attacks targeting ICS components

Unlike indirect attacks, direct attacks intentionally target PLCs and RTUs.

These attacks focus on the critical components that control and monitor industrial processes. The objective is to disrupt or manipulate their operation. In many cases, attackers are looking to compromise physical safety or cause operational damage by manipulating the control systems at the heart of ICS environments.

Example: Triton/Trisis (2017) targeted Schneider Electric’s Triconex safety controllers, which are responsible for shutting down industrial processes in case of dangerous conditions. The malware aimed to manipulate these safety systems and could have disabled critical safety mechanisms, potentially leading to catastrophic physical damage or compromised safety. While the attack was stopped before causing real harm, it underscored the ongoing evolution of ICS threats, showing that advanced, targeted attacks remain a significant concern for critical infrastructure.

DoS and DDoS attacks

Denial of service (DoS) and distributed denial of service (DDoS) attacks aim to overwhelm ICS networks with illegitimate traffic, disrupting or shutting down operations. These attacks can be highly disruptive, particularly in sectors where ICS must run continuously, such as energy and water.

DoS attacks typically involve a single source, while DDoS uses multiple compromised systems to flood the target, making it more difficult to mitigate. Both types of attacks can prevent industrial control systems from functioning, leading to halted production, service outages, or delayed processes. Although recent cases are less frequent, both types are still a risk for critical infrastructure security.

Example: According to a study titled "Cyber Security in Industrial Control Systems: Analysis of DoS Attacks against PLCs and the Insider Effect" (Yılmaz et al., 2018), researchers conducted controlled simulations of DoS attacks on PLC devices. The attacks led to increased latency, with response times rising to 5280 ms, and caused significant disruptions to system operations, demonstrating how these attacks could delay critical control functions in real-world ICS environments. 

The rise of IoT devices has also introduced new potential vulnerabilities for DDoS attacks to exploit in ICS environments, making defense strategies essential for critical operations.

Manipulation of data and commands

Attackers can also put false data into ICS systems or issue malicious commands to disrupt operations. 

This is particularly dangerous because the operators might not immediately notice the issue. In some cases, the ICS might continue to function under erroneous data, leading to inefficiencies, equipment damage, or unsafe conditions. 

For instance, an attacker could send false signals to modify pressure levels in a pipeline, causing it to rupture or malfunction. This type of attack puts both the integrity and safety of the process at risk.

Example: Industroyer/Industroyer2 (2016) malware targeted Ukraine's power grid, manipulating data and sending unauthorized commands to remote terminal units (RTUs). These commands altered the state of critical infrastructure, such as turning circuit breakers on and off. The attack led to power outages and disrupted essential services, making clear the dangers of ICS data manipulation. The consequences of this kind of attack can be severe, as the manipulation can go unnoticed for an extended period, allowing attackers to cause substantial damage and service disruptions before detection.

Vulnerabilities in outdated systems

Many ICS environments rely on legacy systems that weren’t designed with cybersecurity in mind. These systems often run outdated software and have little to no protection against modern cyberthreats.

Additionally, patching legacy systems can be risky since updates may disrupt their operations. Which is why attackers often exploit these vulnerabilities, knowing that older systems lack the advanced defenses common in modern IT environments.

Example: In 2021, attackers exploited vulnerabilities in the Oldsmar water treatment plant, a facility using outdated systems with minimal cybersecurity measures. By remotely accessing the control systems, the attackers attempted to raise the level of sodium hydroxide in the water to dangerous levels. Luckily, the manipulation was caught in time by a plant operator, preventing potential harm. This incident highlights how legacy systems, which were not designed with modern cyber defenses, can be vulnerable to serious attacks that put public safety at risk.

The Purdue Model for ICS Security is considered relevant in addressing these threats by delineating the boundaries between IT and OT systems, ensuring clear communication controls, and emphasizing network segmentation.

By segmenting systems into distinct layers and establishing clear communication boundaries, it helps limit the spread and impact of the cyberthreats we just described.

What is the history of the Purdue Model?

The Purdue Model was originally developed in the early 1990s by the Purdue Laboratory for Applied Industrial Control (PLAIC) at Purdue University to provide best practices for organizing and managing ICS and their relationship with business networks.

Its primary goal was to define structured approaches for segmenting OT systems from corporate IT systems.

The model outlined a framework for managing the integration between industrial environments and business operations. The objective was to isolate OT processes from IT systems, which had begun to play a more significant role in industrial operations at the time.

The Purdue Model was initially based on the concept of "air-gapping," which involved keeping ICS and OT systems disconnected from the internet and corporate networks to avoid disruptions.

Over time, the Purdue Model became a foundational reference for industrial control systems and was adopted in various cybersecurity frameworks, including NIST 800-82 and API 1164.

Examining the Purdue Model’s role in modern ICS security

The Purdue Model has been a cornerstone of ICS architecture for decades, but today its application is being reexamined.

Again, it was initially developed to create a clear separation between OT and IT. However, as technologies have evolved, so have business needs. Both of which have made aspects of the model seem outdated to some.

In fact, a discussion on this topic titled “Is the Purdue Model Dead?” on the Unsolicited Response Podcast took place between Brad Hegrat, Joel Langill, and Dale Peterson in 2019.

Brad Hegrat argued that the model is outdated, largely because IT/OT convergence has made the separation the model once emphasized irrelevant. Joel Langill, however, acknowledged that while the network architecture might no longer be applicable, the model’s approach to layering and hierarchy still holds value for understanding system interactions and risks. Langill suggested that the model remains useful for helping map information flows and identifying potential security threats.

It's not surprising, then, that one of the key debates on the Purdue Model’s current role centers around the increased demand for real-time data from ICS environments.

Organizations are now integrating more cloud-based solutions and remote access systems. Which challenges the Purdue Model’s concept of rigid segmentation.

Again, some argue that the model was designed for an era when the idea of a closed, air-gapped system was feasible. Today, many systems no longer operate in isolation, potentially making the rigid hierarchy less applicable.

On the other hand, proponents of the Purdue Model often contend that while its network architecture may be evolving, the model still serves an important purpose. More specifically, its layered approach provides structure for network segmentation. Which ensures that industrial networks remain manageable and secure.

Supporters suggest that the model doesn’t need to be entirely replaced, but rather adapted to suit modern requirements—such as Industrial IoT and edge computing—which obviously demand more flexible data flows.

Plus, the rise of the IoT and edge devices has further blurred the lines between traditional IT and OT environments. Devices at the lowest levels of the Purdue Model—like sensors—are now capable of directly sending data to the cloud. They bypass the hierarchy that the model established.

Some suggest that a hybrid approach, which maintains key security principles while accommodating new technologies, could strike the right balance between the old and the new.

Ultimately, while the Purdue Model may no longer fit perfectly into today’s dynamic, interconnected environments, its foundational principles remain valuable.

The debate around the Purdue Model’s role in ICS security continues, with many agreeing that adaptation, rather than total abandonment, is the way forward.

Purdue Model for ICS Security FAQs