The Purdue Model Explained: A Practical Guide to OT Network Segmentation

If you have worked on an industrial network, you have probably seen it drawn as a stack of levels: field devices at the bottom, the enterprise at the top, and a firewall somewhere in the middle. That picture is the Purdue model, and it remains the most common way to describe and segment operational technology (OT) networks.

Where the Purdue model comes from

The model grew out of the Purdue Enterprise Reference Architecture, developed at Purdue University in the 1990s to describe how manufacturing enterprises are organized, from the plant floor to business planning. Its hierarchy was later adopted in the ISA-95 standard for integrating enterprise and control systems. Security practitioners took it up because it gives every system a place, and that makes it easy to reason about which systems should talk to which.

The levels, one by one

Level 0: the physical process

Sensors, actuators, motors, valves and drives: the devices that measure and change the physical world. They usually talk to controllers over fieldbus or simple I/O.

Level 1: basic control

Programmable logic controllers (PLCs), remote terminal units (RTUs), intelligent electronic devices (IEDs) and safety controllers. They read Level 0 and execute the control logic that keeps the process running.

Level 2: supervisory control

Human-machine interfaces (HMIs), SCADA servers, distributed control system (DCS) consoles and engineering workstations. Operators watch and steer the process from here, and engineers change control logic from here.

Level 3: site operations

Historians, manufacturing execution systems (MES), site domain controllers, patch and antivirus servers, and other systems that manage production across a whole site.

Level 3.5: the industrial DMZ

A buffer zone between operations and the enterprise. Nothing should pass straight from Level 4 to Level 3 or below. Instead, brokered services sit in the DMZ: a replicated historian that business users can read, a jump server for approved remote access, a staging point for patches and antivirus updates.

Levels 4 and 5: the enterprise

Business systems such as ERP, email and file shares at Level 4, and the wider enterprise network and internet at Level 5. Some versions of the model merge the two.

Why the levels matter for security

The value of the model is not the diagram. It is the rule that follows from it: traffic should only flow where the process needs it to, and every crossing between levels should be deliberate.

In practice, that means:

• Controllers only talk to the supervisory systems that need them. An office laptop at Level 4 has no reason to reach a PLC at Level 1.
• No direct path from the enterprise to control. Every crossing goes through the DMZ, where it can be inspected, logged and limited.
• Remote access lands in the DMZ, not on the control network. Vendors connect to a jump host with multi-factor authentication and recorded sessions, not to an engineering workstation.
• Data leaves, commands do not. Most of what the enterprise needs from OT is data. Where possible, that flow can be made one-way. Our guide to data diodes and unidirectional gateways explains when that is the right answer.

Turning the model into a segmentation plan

Start with what you actually have

Most real networks do not match the diagram. Over the years, sites add a connection for a vendor, a dual-homed workstation, a flat VLAN shared by two production lines. The first step is to map the real network: every asset, its level, its IP range and the paths between them. An agentless asset inventory that records each asset’s network segment and Purdue level does most of this work.

Define zones and conduits

Group assets that share a function and a level of criticality into zones. A packaging line’s PLCs and HMIs might form one zone; the safety system, another. Then define the conduits, the permitted paths between zones, with the protocols and directions each one allows. This is the language IEC 62443 uses, and the Purdue levels are a natural starting point for it.

Enforce, then verify

Firewalls, VLANs and access lists enforce the plan. Then verify it: compare the configuration of every switch, router and firewall against the intended design, and look for the exceptions that crept back in. Configuration analysis is far less risky in OT than active probing, and it shows the paths the network allows, not just the ones you happen to observe.

Common mistakes

• One big Level 2/3 network. Separating the site from the enterprise is a good start, but a flat network inside the site still lets an incident spread from one line to every line.
• Dual-homed machines. A workstation with one network card in the enterprise and one in the control network quietly bypasses every firewall.
• Firewall rules nobody owns. “Any to any” rules added for a commissioning project and never removed.
• Forgetting the safety system. Safety instrumented systems deserve their own zone, with the strictest conduit on the site.

Is the Purdue model out of date?

Cloud analytics, wireless sensors and edge devices do not always fit neatly into the levels, and some argue the model is obsolete. The hierarchy is less strict than it was, but the principle behind it is not: group systems by function and trust, and control every path between groups. Treat the model as a vocabulary and a starting point, not a rulebook.

How Novaigu helps

Mission Guard builds a structured view of your Purdue levels automatically: every network segment at each level, the assets in each IP range, and the logical architecture with its VLANs, so you can see where reality differs from design. Its configuration analysis checks your network devices against the hardening standards you choose. UDR carries data out and updates in between levels and sites over encrypted, one-way links, and our secure design and segmentation service can plan and deliver the changes with your team.