BLOG

Author
Denrich Sananda

Date
09-03-2026

OT Cybersecurity

What Is the Purdue Model? A Guide for OT Security Teams

If you work in operational technology security, you have heard the term Purdue Model more times than you can count. It appears on every OT architecture diagram, inside every IEC 62443 assessment, and in every NERC CIP compliance discussion. Yet in most organizations, the people responsible for securing industrial control systems have never had it explained to them clearly - beyond a five-level diagram on a slide deck.

This post does exactly that. It explains what the Purdue Model is, why it was built, what each level means in practice for your facility, and where its limits are in a world of cloud-connected OT systems and IT/OT convergence.

No theory for its own sake. If you operate a manufacturing plant, a water treatment facility, an oil and gas pipeline, or a power generation asset in North America - this is the foundation your security architecture is built on.

 

73% of organizations experienced intrusions impacting OT systems in 2024

 -  a sharp jump from 49% in 2023. The majority of these attacks exploited weak or absent network segmentation between IT and OT environments: precisely what the Purdue Model was designed to prevent.

Source: Fortinet 2024 State of Operational Technology and Cybersecurity Report

 

What Is the Purdue Model and Where Did It Come From?

The Purdue Model - formally known as the Purdue Enterprise Reference Architecture (PERA) - was developed in the early 1990s at Purdue University under Theodore Williams. It was originally designed as a reference architecture for industrial automation: a structured way to organise the communication between physical processes, control systems, and business networks in a manufacturing environment.

Its timing was not accidental. The 1990s saw the first major wave of IT integration into industrial environments. Facilities that had previously run on entirely isolated, proprietary control networks were beginning to connect to corporate networks - and eventually to the internet. The Purdue Model gave engineers a logical, hierarchical framework for managing those connections safely.

Three decades later, it is still the most widely recognized reference architecture in ICS/OT security. Regulatory frameworks including NERC CIP, NIST SP 800-82, and ISA/IEC 62443 all reference or mirror Purdue-style network segmentation as a baseline requirement.

 

KEY

The Purdue Model does not tell you what technology to buy. It tells you how to organise your network architecture so that a compromise at one level cannot automatically propagate to the next.

 

The Purdue Model Levels Explained: What Each Zone Means for Your Facility

The model divides an industrial enterprise into six levels (Level 0 through Level 5), each representing a distinct functional layer with its own communication requirements and security controls. Understanding what sits at each level is essential before you can define meaningful security boundaries.

 

Level

Name

What Lives Here

Security Focus

5

Enterprise / Corporate Network

ERP, business systems, corporate IT

Standard IT controls, user authentication

4

Site Business Planning & Logistics

Production scheduling, plant-level IT

DMZ separation from Level 3

3

Site Operations & Control

SCADA servers, Historian, DCS management

OT-specific monitoring, patch management

2

Area Supervisory Control

HMI, operator workstations, engineering stations

Application whitelisting, access controls

1

Basic Control

PLCs, DCS controllers, RTUs

Physical security, protocol filtering

0

Physical Process

Sensors, actuators, field devices

Tamper detection, signal integrity

 

The security discipline of OT comes from enforcing boundaries between these levels - particularly between Levels 2/3 (OT) and Levels 4/5 (IT). This boundary is where most successful attacks on industrial infrastructure have crossed. The Colonial Pipeline attack in 2021 began in the IT network and the operator shut down the OT pipeline proactively because the boundary between the two was not tight enough to guarantee separation. The architecture was not the problem - the failure to enforce it was.

 

Why the Purdue Model Still Matters in 2026 - Despite Its Age

A common objection from IT security professionals entering the OT space is that the Purdue Model is outdated - designed before cloud computing, remote access, and IIoT devices changed the nature of industrial connectivity. That objection is partially valid but largely misses the point.

The Purdue Model is not a product or a standard - it is a conceptual framework for thinking about network segmentation. Its core principle - that physical process control systems should not be directly accessible from enterprise business systems, and certainly not from the internet - has not become less true because connectivity has expanded. If anything, it has become more important.

What Purdue still does well:

  • Provides a common language for OT security discussions between plant engineers, IT teams, and executive leadership.
  • Anchors compliance conversations - NERC CIP Electronic Security Perimeters, IEC 62443 zones and conduits, and NIST SP 800-82 all map to Purdue-style architecture.
  • Establishes a baseline for segmentation that stops lateral movement during incidents.
  • Remains the most effective defense against ransomware propagation across IT/OT boundaries.

Where Purdue shows its age:

  • It assumes a hierarchical, unidirectional data flow that no longer reflects modern industrial environments with cloud historians, remote vendor access, and mobile HMI applications.
  • It does not address the security of individual devices - a PLC at Level 1 may have a known, unpatched vulnerability regardless of where it sits in the architecture.
  • It was designed before the concept of Zero Trust - it assumes that devices within a level are implicitly trustworthy, which is no longer a safe assumption.

 

INSIGHT

The right approach for 2026: use the Purdue Model to define your zones and segmentation baseline, then layer IEC 62443 security levels and Zero Trust access controls on top. Purdue is the map - it is not the entire security program.

 

Purdue Model in Practice: How Industrial Sectors Apply It

The model is sector-agnostic by design, but its application varies significantly depending on the operational environment.

Manufacturing

In discrete and process manufacturing, Levels 0–2 are often where the highest density of legacy equipment resides - PLCs and HMIs that were installed before cybersecurity was considered an operational requirement. The key Purdue discipline here is ensuring that Level 2 engineering workstations cannot communicate freely with Level 4 business systems, and that remote vendor access to Level 1–2 devices is brokered through a DMZ, not granted direct IP access.

Energy and Utilities

Power generation and grid operators face the additional constraint of NERC CIP compliance, which mandates specific electronic security perimeters that map directly to Purdue boundaries. The Level 3/4 boundary - the Industrial DMZ - is where most energy sector security investments are focused. Unidirectional gateways (data diodes) at this boundary are increasingly common in transmission and generation assets.

Oil and Gas

Pipeline and upstream operations often involve geographically distributed assets communicating with a central SCADA system - making the Purdue Model more difficult to enforce consistently. Remote terminal units (RTUs) at Level 1 may communicate over public communication networks, creating boundary enforcement challenges that require compensating controls such as encrypted tunnels, application-layer firewalls, and anomaly detection.

 

Common Mistakes When Implementing Purdue Model Segmentation

Most organizations that claim to follow the Purdue Model have not actually enforced it fully. These are the most common gaps identified during OT security assessments:

 

  • Years of incremental growth have blurred Level 1/2/3 separation. Engineering workstations at Level 2 often have unrestricted access to Level 0 field devices and Level 4 business systems simultaneously.Flat OT networks: 
  • Remote access for OEMs and maintenance vendors is typically granted via persistent VPN connections that bypass Purdue boundaries entirely. This is one of the most common attack entry points.Unmanaged vendor access: 
  • The Level 3/4 boundary is the most critical control point in the architecture. Many facilities have a firewall at this boundary but no DMZ - allowing direct connections between OT and IT networks rather than brokered communication.No Industrial DMZ: 
  • PLCs and RTUs that cannot support modern authentication or encryption require network-level compensating controls (protocol filtering, anomaly detection) that are often absent.Legacy devices at Level 1–2 with no compensating controls: 
  • The model is drawn on a network diagram but not enforced through firewall rules, access controls, or monitoring. A documented architecture that does not match the live network provides no security value.Treating Purdue as a documentation exercise: 

 

Where to Start: A Pragmatic Approach for OT Security Teams

If your organization has never formally mapped its ICS architecture against the Purdue Model, the starting point is a network segmentation assessment - not a technology purchase. Before you can know what controls to put in place, you need an accurate picture of what is communicating with what, at which levels, and through which pathways.

From that baseline, the prioritisation is straightforward:

 

  • Identify and close direct IT/OT connections that bypass the Level 3/4 boundary.
  • Establish a formal Industrial DMZ with brokered data flows (historians, patch management, remote access) rather than direct connectivity.
  • Audit all remote access pathways - vendor, engineering, and operations - and enforce least-privilege access through a secure access gateway.
  • Deploy OT-native network monitoring at Level 3 to establish a baseline of normal traffic and detect anomalies in real time.
  • Map your current architecture against IEC 62443 security zones and conduits to identify gaps requiring compensating controls at Levels 1–2.

 

 

The Purdue Model is not a 1990s relic. It is the most practical framework for communicating OT network architecture across engineering and security disciplines - and it is the baseline from which every ICS security improvement program should start. The organizations that have been breached were not running a failed model. They were running a model they never fully enforced.

 

About Arista Cyber

Arista Cyber is an OT/ICS cybersecurity firm helping industrial organizations in North America and Europe secure their operational technology environments. Our assessments are grounded in the Purdue Model, IEC 62443, and NERC CIP - built around the operational realities of the facilities we protect, not generic IT security frameworks.


 

Frequently Asked Questions - Purdue Model & OT Security

Is the Purdue Model mandatory for ICS security compliance?

It is not a mandatory standard in itself, but the segmentation principles it defines are reflected in mandatory frameworks including NERC CIP (for electric utilities in North America) and IEC 62443 (globally recognized for industrial automation). Following the Purdue Model's segmentation logic puts you in alignment with both.

What is the difference between the Purdue Model and IEC 62443?

The Purdue Model defines how to organise and segment your network architecture. IEC 62443 defines what security requirements apply at each layer of that architecture - including access control, authentication, audit logging, and system resilience. Most mature OT security programs use Purdue to design the architecture and IEC 62443 to specify the security requirements within it.

Can the Purdue Model accommodate cloud connectivity and remote access?

Yes - but it requires extending the model beyond its original five levels. Cloud-connected historians, remote vendor access, and mobile HMI applications are typically managed through a formal Industrial DMZ at the Level 3/4 boundary, with strict controls governing what data can pass through and under what conditions. Zero Trust access principles are increasingly applied at this boundary to replace the implicit trust assumptions the original model made.