Purdue Model Explained: Network Zones in Manufacturing

TL;DR

The Purdue Model (also known as the Purdue Enterprise Reference Architecture) defines six levels from physical processes (Level 0) to the enterprise network (Level 5).
Between Level 3 (Manufacturing Operations) and Level 4 (Enterprise IT) lies the Industrial DMZ as the central security barrier.
Each level has its own security requirements. Traffic between non-adjacent levels should generally not be permitted.
The EU Machinery Regulation 2023/1230 supports this approach by requiring that network connections to machines must not create safety risks.
Even without a multi-million investment, you can achieve effective basic segmentation with VLANs and a dedicated firewall.

Why Network Zones in Manufacturing Are Essential

If an attacker penetrates your office network, they should not be able to control your production equipment in the next step. That is the basic principle. The implementation is naturally more complex, and that is exactly what the Purdue Model is for.

The Purdue Enterprise Reference Architecture Model (PERA) was developed at Purdue University in the 1990s, originally not as a security model but as a reference architecture for integrating enterprise systems with manufacturing systems. The ISA (International Society of Automation) later adopted it as the foundation for the ISA-95 standard and the security standard ISA/IEC 62443.

Today, the Purdue Model is the de facto standard for segmenting OT networks. Even though modern architectures (such as Zero Trust for OT) go beyond it, it remains the best foundation for a structured network segmentation in manufacturing.

The Six Levels of the Purdue Model

Level 0: Physical Process

Level 0 is the physical world. This is where sensors and actuators directly measure and influence the production process:

Temperature sensors, pressure transmitters, flow meters
Valves, motors, heaters, pumps
Variable frequency drives, servo motors
Light barriers, proximity switches, limit switches

These devices are often not network-capable systems in the traditional sense. They communicate via analog signals (4-20 mA, 0-10 V) or via fieldbuses (Profibus, AS-Interface, IO-Link). However, there are increasingly sensors with Ethernet connectivity or wireless interfaces (Bluetooth, LoRaWAN, 5G).

Security relevance: Level 0 is the safety domain. If a sensor monitoring a safety-relevant function (such as pressure in a boiler) is manipulated, it can directly lead to physical damage. Protective measures at this level are primarily physical in nature: access controls to control cabinets, seals on wiring, documentation of all changes.

Level 1: Basic Control

Level 1 contains the control systems that directly regulate the physical process:

Programmable Logic Controllers (PLC (SPS))
Remote Terminal Units (RTU)
Safety controllers
Intelligent drives with their own control logic

These devices read sensor data from Level 0, process it according to the programmed control logic, and issue commands to the actuators. A PLC typically operates in a fixed cycle of a few milliseconds. Any delay in this cycle can affect product quality or, in the worst case, lead to hazardous conditions.

Security relevance: PLC systems are the primary attack target in the OT world. Malware such as Stuxnet (2010) and TRITON/TRISIS (2017) demonstrated that attackers are capable of manipulating control programs. Securing SCADA and PLC systems requires specific measures. Hardening Level 1 systems (firmware updates, access controls, program integrity) is one of the most important measures.

Level 2: Process Monitoring

Level 2 encompasses the systems with which operating personnel monitor and control the production process:

SCADA systems (Supervisory Control and Data Acquisition)
HMI panels (Human Machine Interface)
Engineering workstations (for PLC programming)
Data historians (local process data archives)
Alarm management systems

At this level, Windows-based systems typically run. The SCADA software visualizes the production process, collects alarms, and allows operators to change parameters or intervene manually. Engineering workstations are used for programming and configuring the PLC systems at Level 1.

Security relevance: Level 2 is particularly vulnerable because IT-typical operating systems (Windows) run in an OT context here. The systems often cannot be patched (because the SCADA vendor has not approved the update) — a typical problem of patch management in OT — and antivirus software is sometimes incompatible. At the same time, these are the systems through which an attacker gains access to the controllers at Level 1.

Level 3: Manufacturing Operations

Level 3 is the level of production management and planning:

Manufacturing Execution System (MES)
Batch management systems
Laboratory Information Management Systems (LIMS)
Central historian servers
Production planning and scheduling
Quality management systems

These systems coordinate the entire production process. The MES translates customer orders from the ERP system into specific machine allocations and production sequences. It collects production data from all lines and makes it available for analysis.

Security relevance: Level 3 is the highest level of the OT world and simultaneously the interface to IT. Data flows must be carefully controlled here. The MES needs access to the control systems at Level 2 (downward) and to the ERP system at Level 4 (upward). It is therefore a bridge system with special protection requirements.

The Industrial DMZ: The Central Security Barrier

Between Level 3 and Level 4 lies the Industrial DMZ (Demilitarized Zone). It is the heart of the Purdue architecture from a security perspective.

The DMZ contains systems that must be reachable from both the IT and OT sides but do not directly belong to either IT or OT:

Jump servers for remote access to OT systems
Replicated historian servers (mirror data from Level 3 for IT access)
Data transfer servers (files exchanged between IT and OT)
Patch management servers for OT (download patches from the internet, make them available for OT)
Anti-malware update servers

The core principle of the DMZ: No direct traffic between IT (Level 4/5) and OT (Level 0-3). All communication runs through DMZ systems. The firewalls on both sides of the DMZ are configured so that:

From IT to DMZ: Only defined connections to DMZ services are allowed
From DMZ to OT: Only defined connections to required OT systems are allowed
From IT to OT directly: Completely blocked
From OT to IT directly: Completely blocked

This model ensures that an attacker who has compromised the IT network cannot directly access OT systems. They must first compromise a DMZ system, which represents an additional hurdle.

Level 4: Enterprise IT

Level 4 is the classic enterprise network:

ERP system (SAP, Microsoft Dynamics, etc.)
Email servers
File servers
Intranet and collaboration tools
Business intelligence and reporting

From an OT perspective, Level 4 is "the IT." The systems at this level use data from production (via the DMZ), but they have no direct access to control systems.

Level 5: Enterprise Network / Internet

Level 5 encompasses the enterprise-wide network, connections between sites, and internet access:

WAN connections between sites
VPN gateways
Internet proxy and web filters
Cloud services
External partner networks

Security relevance: Level 5 is the entry point for external attackers. From here, they work their way down through the levels. Each security layer they must overcome increases the effort and the chance of being detected.

Implementing the Purdue Model in Practice

The model sounds clear and logical in theory. However, implementation in an established mid-market company is full of challenges.

Assessing the Current State

The first step is an honest inventory. Map your network as it actually is, not as it should be. Typical findings during this exercise:

There is no real separation between IT and OT. Everything is connected to the same core switch.
The SCADA server has an IP address from the office subnet.
The machine manufacturer has installed a VPN router directly on the machine that has its own internet connection (bypassing the enterprise network).
The engineering workstation is in the maintenance engineer's office and simultaneously serves as their regular workstation, with an email client and internet access.
There is no segmentation between different production areas.

These findings are not pleasant, but they are the starting point for improvements.

Defining the Target State

Assign each system to a Purdue level. You will find that some systems cannot be clearly assigned. A typical example: The historian server that collects data from the SCADA world (Level 2/3) and is simultaneously used by the IT department for reporting (Level 4). The solution: Two historian instances. One at Level 3 for data collection, one in the DMZ for IT access, with unidirectional replication between them.

Pragmatic Segmentation

You do not need a perfect Purdue architecture right away. A pragmatic basic segmentation with three zones is a good start:

Zone 1 - Enterprise (Level 4/5): Office IT with all standard systems. Normal IT security measures apply here.

Zone 2 - DMZ: Bridge systems connecting both worlds. At minimum: A jump server for remote access to OT and a data transfer server for exchange between ERP and MES.

Zone 3 - Production (Level 0-3): All OT systems. Internally, you can further segment later (separate VLANs for different production lines), but the IT/DMZ/OT separation is the most important first step.

Between the zones, firewalls are placed (or a Layer 3 switch with ACLs as an interim solution). The rules:

Enterprise → DMZ: Allowed, but only to defined services
DMZ → Production: Allowed, but only to defined services and protocols
Enterprise → Production: Blocked
Production → Enterprise: Blocked
Production → DMZ: Allowed for defined data flows (e.g., historian replication)

Typical Resistance and How to Address It

"We've always done it this way." The legacy structure works — why change anything? A concrete threat scenario helps here: "If employee X opens a phishing email, the attacker can reach the production control in three steps. Do you want to leave it like that?"

"Segmentation makes everything slower." Modern firewalls and switches process industrial protocols without measurable latency. The concern is technically unfounded, but you should take it seriously and, if in doubt, disprove it with a measurement.

"The machine manufacturer needs direct access." Then they get access through the jump server in the DMZ. With their own account, multi-factor authentication, and logging. Not through an unsecured VPN router that bypasses the enterprise network and connects directly to the internet.

"It costs too much." A basic segmentation with managed switches (VLANs) and a dedicated firewall typically costs between 5,000 and 20,000 euros for a mid-market site. That is a fraction of what a production shutdown due to a ransomware attack costs.

Modern Extensions of the Purdue Model

The classic Purdue Model has limitations that become relevant in modern OT environments:

Cloud Connectivity

The original model has no concept of the cloud. However, modern production environments send data to cloud platforms for analytics, predictive maintenance, or centralized monitoring of multiple sites. The recommended approach: Cloud connections run through the DMZ, not directly from the production zone. An edge gateway in the DMZ collects the data, filters it, and forwards it encrypted to the cloud.

Wireless and IoT

Wireless sensors and IoT devices do not fit neatly into the hierarchical model. They are physically located at Level 0/1 but may communicate via their own wireless networks directly with cloud services. It is important to treat the wireless network as its own zone and route traffic through a gateway that sits at the appropriate Purdue level.

Zero Trust for OT

The Zero Trust concept (trust nobody, verify every access) is increasingly being applied to OT environments. It complements the Purdue Model by controlling access even within a level. However, implementation in OT is significantly more difficult than in IT because many OT protocols do not support authentication. Zero Trust for OT is therefore more of a long-term goal than an immediate action plan.

The Connection to the EU Machinery Regulation

The EU Machinery Regulation 2023/1230 requires from 2027 onward that the safety functions of a machine must not be impaired by digital connections. The Purdue Model provides the structural framework to ensure exactly that.

If a machine resides at Level 1/2 and its safety functions are protected from external access through proper network segmentation, a key requirement of the regulation is met. Conversely, if the machine is directly reachable from the internet or sits in the same network as office PCs, it will be difficult to argue compliance with the regulation.

For machine manufacturers who must CE-mark under the new regulation, recommending a Purdue-compliant integration in the operating instructions is a sensible approach. For operators, implementing proper segmentation is a key building block for complying with both NIS2 and the Machinery Regulation.

Case Study: Purdue Segmentation at a Metal Fabricator

A mid-market metal fabricator with 180 employees and three production halls implemented the Purdue Model in six months. The starting state: A flat network in which office PCs, SCADA servers, and PLC controllers communicated in the same subnet. The CEO had initiated the project after a ransomware attack at an industry peer led to three weeks of production downtime.

Months 1-2: Assessment. An external consultant, together with the IT manager and the maintenance manager, documented all network connections. The result: 47 OT devices (PLC, HMI, SCADA), three remote maintenance access points (one of which was a TeamViewer access that the machine manufacturer had set up in 2019 and never deactivated), and a direct connection from the ERP server to the MES server, which was in the same VLAN as the SCADA servers.

Months 3-4: Target architecture and procurement. Three zones defined: Enterprise, DMZ, and Production. Two dedicated firewalls procured (one between Enterprise and DMZ, one between DMZ and Production). A jump server set up in the DMZ. The firewall rules were developed jointly by IT and production engineering, with an explicit list of all permitted connections and protocols.

Month 5: Implementation. During a planned production shutdown (company holiday), the new firewalls were installed and the network zones configured. The TeamViewer access was deactivated and replaced by access through the jump server. All remote maintenance access now runs through the jump server with individual accounts and logging.

Month 6: Monitoring and fine-tuning. In the first weeks after the changeover, there were some connectivity issues (an IoT sensor that regularly sent data to a cloud service and was now blocked by the firewall; an old diagnostic tool that required a direct connection to the SCADA server). These were identified and specifically addressed in the firewall rules.

Total cost: Approximately 15,000 euros for hardware (firewalls, jump server) plus 12,000 euros for the external consultant. The IT manager estimated that he invested approximately 80 hours of his own time, the maintenance manager approximately 30 hours.

Result: A penetration test six months after implementation confirmed that an attacker who compromises an office PC can no longer directly access OT systems. The production technicians confirmed, after initial skepticism, that the segmentation does not impact operations.

Checklist: Implementing the Purdue Model

To conclude, a practical checklist for implementation:

Current network state documented (all connections between IT and OT)
Each OT system assigned to a Purdue level
At least three zones defined (Enterprise, DMZ, Production)
Firewall between Enterprise and DMZ installed and configured
Firewall between DMZ and Production installed and configured
No direct traffic between Enterprise and Production possible
Jump server in the DMZ set up for remote access to OT
All remote maintenance access routed through the jump server
Data flows between IT and OT documented through DMZ systems
Firewall rules configured according to the "default deny" principle
Segmentation within the Production zone started (e.g., separate VLANs per production line)
Monitoring at zone boundaries established
ISMS documentation updated (network diagram, asset assignment, firewall rules)

The assignment of your OT assets to Purdue levels can be documented in ISMS Lite together with criticality, dependencies, and zone rules, so you always have an audit-ready overview.