What Is the Purdue Model, and Why Does It Matter to Critical Infrastructure?

By Timehri Networks LLC
Operational Technology and Critical Infrastructure Cybersecurity

Modern water, wastewater, energy, manufacturing, and transportation organizations depend on operational technology to monitor equipment and control physical processes. These environments may contain supervisory control and data acquisition systems, human-machine interfaces, programmable logic controllers, remote terminal units, sensors, pumps, valves, motors, and other industrial equipment.

As operational technology becomes increasingly connected to business networks, remote users, vendors, cloud services, and the internet, organizations need a clear way to separate systems according to their functions and cybersecurity risks.

The Purdue Model provides a practical framework for doing this.

What Is the Purdue Model?

The Purdue Model is a hierarchical representation of how industrial control and enterprise systems are organized. It divides an organization’s technology environment into levels, beginning with the physical industrial process and extending upward through control systems, operations management, business systems, and external networks.

The model originated from the Purdue Enterprise Reference Architecture and later influenced the ISA-95 enterprise-control system integration standard. ISA describes ISA-95 as defining interfaces between control functions and enterprise functions based on the hierarchical Purdue Reference Model.

In simple terms, the Purdue Model helps an organization answer three questions:

1. What does each system do?
2. Where should that system be located?
3. Which other systems should it be allowed to communicate with?

The model is widely used to help structure industrial automation and operational technology environments. It is also useful when designing cybersecurity zones, network segmentation, firewall rules, remote-access pathways, monitoring systems, and incident-response plans.

The Purdue Model Levels

The Purdue Model is commonly represented using Levels 0 through 5. A separate Level 3.5 is often added to represent an industrial demilitarized zone between business and operational networks.

Level 0: The Physical Process

Level 0 represents the actual physical process being monitored or controlled.

In a water or wastewater environment, Level 0 may include:

• Pumps
• Motors
• Valves
• Tanks and reservoirs
• Clarifiers
• Filters
• Chemical-feed equipment
• Blowers
• Gates
• Pipes
• Physical treatment processes

This is where digital commands produce real-world consequences.

For example, a command sent from a control system may start a pump, open a valve, increase chemical dosing, or change the operating speed of a motor.

The primary concern at Level 0 is the safe and reliable operation of the physical process.

Level 1: Intelligent Devices and Basic Control

Level 1 contains the devices that directly monitor and control the physical process.

Typical Level 1 equipment includes:

• Programmable logic controllers
• Remote terminal units
• Intelligent electronic devices
• Variable-frequency drives
• Process sensors
• Local control panels
• Instrumentation

A programmable logic controller might receive a tank-level measurement and automatically start or stop a pump based on its programmed logic.

Because these devices can directly affect physical operations, unauthorized access or configuration changes at Level 1 can create serious safety, environmental, and service-continuity consequences.

Level 2: Supervisory Control

Level 2 contains the systems operators and engineers use to supervise the process.

Examples include:

• Human-machine interfaces
• SCADA operator workstations
• Local SCADA servers
• Alarm-management systems
• Engineering workstations
• Process visualization systems

An operator may use an HMI to view tank levels, acknowledge alarms, start equipment, change an operating setpoint, or investigate an abnormal condition.

Engineering workstations may also be used to program or modify controllers. For this reason, they should be treated as highly sensitive assets and should not normally be used for email, general web browsing, or routine office activities.

Level 3: Site Operations Management

Level 3 supports the overall management of plant or operational activities.

Systems at this level may include:

• Central SCADA servers
• Operational historians
• OT domain services
• Asset-management systems
• Backup servers
• Network-management platforms
• Patch-management systems
• Antivirus-management servers
• Operations reporting systems
• Engineering repositories

Level 3 may collect information from lower-level control systems and make that information available to authorized operational personnel.

This level often forms the upper boundary of the core OT environment.

Level 3.5: The Industrial Demilitarized Zone

Level 3.5 is commonly used to represent the industrial demilitarized zone, frequently abbreviated as IDMZ.

The IDMZ is a controlled buffer between the organization’s business network and its operational technology network. Its purpose is to prevent direct communication between enterprise systems and sensitive control systems.

Systems placed in the IDMZ may include:

• Remote-access gateways
• Jump servers
• Historian replication servers
• Secure file-transfer systems
• Patch repositories
• Authentication proxies
• Cybersecurity monitoring collectors
• Vendor-access platforms

For example, an employee working remotely should not connect directly from the internet to an HMI or engineering workstation. The employee should first authenticate through an approved secure-access platform, enter a controlled intermediary environment, and then access only the specific OT resources required for the job.

The IDMZ is not simply another network segment. It is an important security boundary that should be protected by tightly configured firewalls, restrictive access rules, logging, monitoring, and strong authentication.

Level 4: Enterprise Business Systems

Level 4 contains the organization’s traditional information technology systems.

These systems may include:

• Email
• Financial applications
• Customer-information systems
• Human-resources systems
• Billing platforms
• Business databases
• Collaboration tools
• General employee workstations
• Corporate identity services
• Internet-access systems

The enterprise network normally requires information from operational systems for reporting, planning, billing, compliance, and management purposes.

However, that business need does not justify unrestricted access to the OT network.

A compromised employee laptop or email account at Level 4 should not provide an attacker with a direct pathway to a SCADA server, HMI, PLC, or other critical control asset.

Level 5: External Networks

Level 5 represents networks and services outside the organization’s internal enterprise environment.

Examples may include:

• The public internet
• Cloud services
• External partners
• Equipment vendors
• Remote support organizations
• Government portals
• Third-party service providers
• External data centers

External connectivity may provide legitimate operational and business benefits, but it also introduces risk.

No external network should have unrestricted direct access to critical controllers or supervisory systems. External connections should pass through approved security controls and be limited to documented business or operational requirements.

How Information Moves Through the Model

The Purdue Model traditionally reflects a controlled flow of information between adjacent levels.

At the lower levels, sensors provide information about physical conditions. Controllers process that information and operate equipment. SCADA and HMI systems allow operators to supervise the process. Operations-management systems aggregate and store information. Business systems use selected operational information for reporting and organizational decision-making.

A simplified flow might look like this:

Physical equipment → Controller → SCADA system → Operations system → Business application

Commands generally move downward, while operational data moves upward.

In practice, modern environments are more complex. Wireless systems, cloud platforms, remote sites, mobile devices, industrial internet-of-things technologies, and vendor connections may not fit perfectly into a rigid hierarchy.

NIST SP 800-82 Revision 3 nevertheless includes the Purdue Model as a useful high-level example while emphasizing that OT security must account for unique performance, reliability, and safety requirements.

The Purdue Model should therefore be treated as a logical starting point rather than an inflexible physical design.

Why the Purdue Model Matters for Cybersecurity

The primary cybersecurity value of the Purdue Model is separation.

Without defined boundaries, an industrial organization may operate a flat network where business computers, servers, operator stations, engineering systems, and controllers can communicate too freely.

A flat environment increases the possibility that a compromise originating in email, remote access, a vendor account, or an employee workstation will spread into the control system.

The Purdue Model helps organizations establish distinct security zones so that:

• Enterprise users cannot directly access controllers.
• Vendors receive limited and temporary access.
• Business systems receive only the operational data they need.
• Engineering workstations are isolated from routine office activity.
• Remote facilities communicate only with approved systems.
• Cybersecurity monitoring can identify abnormal communication.
• A compromise in one zone is less likely to spread throughout the organization.

CISA, EPA, and the FBI have identified network segmentation and reduced exposure among the important actions water and wastewater organizations can take to protect their systems from malicious cyber activity.

The Purdue Model and Network Segmentation

Network segmentation divides an environment into smaller, controlled security zones.

A utility might establish separate zones for:

• Corporate IT
• The industrial demilitarized zone
• Central SCADA systems
• Drinking-water treatment
• Wastewater treatment
• Water distribution
• Wastewater collection
• Remote pumping stations
• Engineering systems
• Physical security systems
• Vendor-managed equipment

Firewalls and access controls can then regulate communications between these zones.

For each permitted connection, the organization should understand:

• Which device initiates the communication
• Which device receives it
• Which protocol is used
• Which network port is required
• Whether communication must be encrypted
• How the user or device is authenticated
• Who owns the connection
• Why the connection is operationally necessary
• How the activity is logged and monitored

The preferred approach is generally to deny communication unless it has been specifically reviewed and authorized.

The Purdue Model Is Not a Security Product

The Purdue Model is an architectural framework. It is not a firewall, monitoring platform, antivirus application, or cybersecurity certification.

Placing systems into boxes on a network diagram does not make them secure.

The boundaries shown in the architecture must be enforced through technical and administrative controls, including:

• Firewalls
• Access-control lists
• Network routing restrictions
• Multifactor authentication
• Secure remote access
• Privileged-access management
• Account management
• Endpoint protection
• Configuration management
• Logging and monitoring
• Tested backups
• Incident-response procedures
• Employee and vendor training

An organization can have a well-designed Purdue diagram and still remain vulnerable if its firewall rules permit excessive access, vendor accounts are uncontrolled, passwords are shared, or systems are exposed directly to the internet.

The Purdue Model Is Not the Same as ISA/IEC 62443

The Purdue Model and ISA/IEC 62443 are related but serve different purposes.

The Purdue Model organizes systems according to functional levels. ISA/IEC 62443 provides a broader cybersecurity framework for industrial automation and control systems.

ISA/IEC 62443 uses the concepts of zones and conduits:

• A zone groups assets with similar security requirements.
• A conduit represents controlled communication between zones.

An organization may use the Purdue Model to understand its functional architecture and then apply zones and conduits to design the actual security boundaries.

Not every asset at the same Purdue level must belong to the same zone.

For example, a drinking-water treatment PLC and a wastewater-treatment PLC may both be located at Level 1. However, they support different processes and may need to be placed in separate security zones.

Applying the Purdue Model to Water and Wastewater Utilities

A water or wastewater utility can begin applying the model through five practical steps.

1. Inventory the Environment

Identify the utility’s:

• SCADA servers
• HMIs
• PLCs
• RTUs
• Engineering workstations
• Historians
• Firewalls
• Network switches
• Remote sites
• Wireless systems
• Vendor connections
• Cloud services
• Business applications

The utility cannot properly segment assets it has not identified.

2. Assign Systems to Logical Levels

Determine the function of each system and place it at the appropriate Purdue level.

The purpose is not to force every device into a perfect category. The purpose is to understand its role, operational importance, and relationship to other systems.

3. Document Communications

Identify how data and commands move between systems.

Unexpected pathways often appear during this process, including:

• Direct access from business workstations to SCADA servers
• Unrestricted vendor connections
• Dual-connected servers
• Unsupported remote-access tools
• Controllers communicating with external networks
• Remote stations with excessive network permissions

4. Establish Security Boundaries

Use firewalls, VLANs, routing controls, authentication, jump servers, and an IDMZ to separate environments.

Prioritize the boundaries between:

• External networks and enterprise IT
• Enterprise IT and the IDMZ
• The IDMZ and OT
• Operations systems and supervisory systems
• Supervisory systems and controllers
• Separate plants and remote facilities

5. Monitor the Boundaries

Review firewall, authentication, VPN, server, endpoint, and OT network activity.

Examples of events requiring investigation include:

• A business workstation attempting to contact a PLC
• A vendor accessing the environment outside an approved window
• Unexpected controller-programming activity
• New communication between operational zones
• Repeated failed logins
• An HMI communicating with an unknown internet address
• Unauthorized changes to firewall rules
• New or unapproved devices appearing on the OT network

Common Misunderstandings

“Every level requires a separate physical network.”

Not necessarily. Smaller organizations may combine some functions because of operational, staffing, or financial limitations.

However, combining functions should not eliminate necessary trust boundaries. Security controls should reflect the consequences of compromise.

“Systems at the same level should communicate freely.”

Not necessarily. Assets at the same level may support different facilities, processes, safety functions, or vendors.

Communication should be based on operational necessity rather than only on the Purdue level.

“The model eliminates the need for risk assessments.”

No. The model helps organize the environment, but each organization must evaluate its own threats, vulnerabilities, operational consequences, architecture, staffing, and recovery capabilities.

“The Purdue Model prevents cyberattacks.”

No architecture can guarantee that an incident will never occur.

A properly implemented architecture can reduce exposure, restrict attacker movement, improve visibility, and limit the consequences of a compromise.

Does the Purdue Model Still Apply to Modern OT?

The Purdue Model remains useful, but modern industrial environments do not always follow a perfectly linear hierarchy.

Cloud analytics, edge computing, industrial internet-of-things devices, managed security services, remote work, distributed operations, and direct data integrations have created new communication patterns.

Organizations should not abandon security boundaries merely because technology has changed.

Instead, they should adapt the model by:

• Creating clearly defined security zones
• Authenticating users and devices
• Restricting communication by application and purpose
• Protecting remote and cloud connections
• Monitoring traffic between zones
• Applying least privilege
• Verifying access continuously
• Maintaining operationally tested recovery capabilities

The modern objective is not rigid adherence to a diagram. It is preserving controlled trust boundaries between business systems, operational systems, controllers, and physical processes.

Conclusion

The Purdue Model is a framework for organizing industrial technology into functional levels, from the physical process at the bottom to enterprise and external networks at the top.

For critical-infrastructure organizations, its value lies in helping leaders, engineers, operators, IT professionals, and cybersecurity teams understand:

• Where critical assets belong
• How systems depend on each other
• Where security boundaries should be established
• Which communications should be permitted
• How an attacker might move through the environment
• Where monitoring and access controls are most important

The Purdue Model does not provide complete cybersecurity by itself. However, when combined with network segmentation, secure remote access, strong authentication, continuous monitoring, configuration management, tested backups, and incident-response planning, it provides a practical foundation for protecting operational technology.

For water and wastewater utilities, that protection supports more than computer security. It supports reliable service, safe treatment, environmental protection, regulatory responsibility, and public health.

About Timehri Networks

Timehri Networks LLC provides operational technology and critical-infrastructure cybersecurity services to water, wastewater, municipal, and industrial organizations.

Our services include:

• OT cybersecurity assessments
• SCADA architecture reviews
• Purdue Model and zone-mapping exercises
• IT/OT segmentation planning
• Firewall and remote-access reviews
• Passive OT monitoring strategies
• Microsoft Sentinel integration
• Incident-response planning
• Cybersecurity improvement roadmaps

Florida • Caribbean • East Africa

This article provides general educational information. Cybersecurity controls should be selected and implemented based on a site-specific operational, engineering, safety, and risk assessment.