OT Security

Purdue Model

A hierarchical reference model that divides industrial control system environments into defined levels, providing a conceptual foundation for network segmentation and security zone design in OT environments.

Where you will see it: Relevant in industrial environments, critical infrastructure, and wherever IT networks connect to operational technology systems.

What it is

The Purdue Model organizes industrial enterprise functions into a hierarchy of levels numbered zero through four, with an additional Industrial Demilitarized Zone between the OT levels and the enterprise IT level. Level 0 contains the physical process itself: sensors, actuators, and the machinery being controlled. Level 1 contains the devices that directly control the process: PLCs, RTUs, and intelligent electronic devices. Level 2 contains the supervisory systems that monitor and control Level 1 devices: SCADA systems, DCS systems, HMI workstations, and engineering stations. Level 3 contains site-wide operations: production management systems, historian servers, and batch management systems. Level 4 is the enterprise IT network containing business systems such as ERP, email, and corporate applications. Each level communicates primarily with the levels immediately above and below it, and transitions between distant levels should cross explicit boundaries.

Key points

Divides ICS environments into five levels from field devices at Level 0 to enterprise IT at Level 4.
Defines the Industrial Demilitarized Zone as a buffer between OT levels and the enterprise network.
Provides a shared vocabulary for describing where technologies and threats operate in industrial architectures.
Increasingly challenged by cloud connectivity, remote access, and converged IT/OT networks that do not fit the model cleanly.
Still the dominant reference model in ICS security frameworks including IEC 62443 and NIST SP 800-82.

How it works in broad strokes

Level 0 is the physical process: the sensors measuring temperature, pressure, flow, and position, and the actuators such as valves, motors, and pumps that respond to control signals.
Level 1 is basic control: the PLCs, RTUs, and IEDs that read Level 0 sensors and drive Level 0 actuators according to programmed logic, executing control loops at millisecond to second timescales.
Level 2 is supervisory control: the SCADA servers, DCS controllers, HMI workstations, and engineering workstations that configure Level 1 devices, display process state, and allow operators to intervene.
Level 3 is site operations: the historian servers that record process data over time, the manufacturing execution systems that schedule production, and the batch management systems that coordinate complex multi-step processes.
The Industrial Demilitarized Zone sits between Level 3 and Level 4 and contains systems that need to exchange data in both directions: data historians that replicate upward to enterprise reporting systems, patch management servers, and remote access jump hosts that provide controlled access inward.
Level 4 is the enterprise IT network: business applications, corporate email, ERP systems, and general IT infrastructure that has no direct control relationship with the physical process.

Concrete example

A food manufacturing plant uses the Purdue Model as the foundation for its network architecture. Sensors and actuators on the production floor are at Level 0. PLCs controlling mixers, ovens, and packaging machines are at Level 1, connected to HMI workstations and a SCADA server at Level 2 over a dedicated control network. A historian server at Level 3 collects production data and replicates it upward through the IDMZ to an enterprise reporting system at Level 4. The IDMZ contains only the historian replication service and a jump host for remote access. Firewall rules between each layer ensure that enterprise systems cannot initiate connections to OT systems, and that the only permitted upward data flow from Level 3 is historian replication to the designated enterprise server.

Why it matters

The Purdue Model gives security architects a shared reference for where assets live in an industrial environment and where boundaries should exist. Its core principle, that OT levels should be isolated from enterprise IT with controlled data flow between them, remains sound even as specific implementations have evolved.

Security angle

The IDMZ is the most security-critical element. It should contain only systems that genuinely need to bridge OT and IT, with firewalls on both sides and no direct connections passing through.
Data flow between levels should be intentional and minimized. A historian pushing data upward is appropriate; enterprise applications reaching into Level 2 to query PLCs directly is not.
Engineering workstations at Level 2 are a high-value target because they have authorized access to Level 1 devices and are often more reachable from corporate networks than the PLCs themselves.
Remote access into OT levels should terminate in the IDMZ on a jump host, not tunnel directly to Level 2 or Level 1 devices.
Lateral movement between sites at the same Purdue level is a risk the model does not address explicitly. Segmenting sites from each other horizontally matters as much as vertical separation.

Common pitfalls

Treating the Purdue Model as a compliance checkbox rather than as a design principle. A network diagram that labels levels correctly but routes traffic freely between them provides no actual security benefit.
Assuming the model maps directly to modern architectures. Cloud-connected sensors, remote monitoring platforms, vendor maintenance tunnels, and software-as-a-service SCADA solutions create connectivity that bypasses the traditional level hierarchy entirely.
Placing too many systems in the IDMZ or allowing direct connections through it. An IDMZ that becomes a general-purpose network segment loses its function as a controlled boundary.
Ignoring east-west traffic within levels. The Purdue Model focuses on north-south communication between levels, but lateral movement between devices at the same level is a real attack path that requires its own segmentation controls.

DEEP DIVE

▾

Origins and intent: a manufacturing model adopted for security

The Purdue Enterprise Reference Architecture was developed at Purdue University in the early 1990s, primarily by Theodore Williams and colleagues working on the PERA model for manufacturing enterprise integration. Its original purpose was not security but integration: it provided a framework for understanding how different functional systems in a manufacturing enterprise related to each other and how information should flow between them. The model described business functions, not network topology, and it was adopted by the ISA-95 standard for enterprise-control system integration, which formalized the levels and their functional definitions.

The model's adoption as a security architecture came later, as ICS networks began to be connected to corporate IT networks and the need for organized segmentation became apparent. Security practitioners found the Purdue levels a useful vocabulary for describing where devices lived and where boundaries should be enforced. IEC 62443, the ICS security standard family, uses the concepts of zones and conduits that align with Purdue level thinking. NIST SP 800-82, the guide to industrial control system security, references the model as a framework for understanding ICS architecture.

This history matters because it explains why the Purdue Model has both strengths and limitations as a security tool. It was designed to describe how an integrated manufacturing enterprise should work, and it does that well. It was not designed to describe how adversaries move through networks, how remote connectivity creates exposure, or how cloud architectures change data flow patterns. Applying it effectively requires understanding what it was built to do and where it needs to be supplemented with other thinking.

The levels in practice: what actually runs where

In real industrial environments, the clean level separations of the Purdue Model are often messier than the diagram suggests. Level 0 and Level 1 are usually the most clearly defined: physical sensors and actuators connect to PLCs and RTUs over dedicated field buses or discrete wiring, and those connections are relatively straightforward to map and protect. The control logic running in Level 1 devices is the closest thing to a hard boundary in most ICS environments because changing it requires either physical access to the device or access through a programming connection from Level 2.

Level 2 and Level 3 tend to blur in practice. Engineering workstations, SCADA servers, and historian systems sometimes run on shared infrastructure or communicate over the same network segment. In smaller facilities, a single server may perform both supervisory control functions and site operations functions simultaneously. These consolidations are often driven by cost and operational convenience, but they compress the boundaries that the model assumes exist and that security architectures depend on.

The IDMZ is where the most architectural discipline is required and where it is most often missing. In environments that have implemented an IDMZ, it frequently contains far more systems than intended: patch management servers, antivirus update mirrors, remote access infrastructure, vendor connection points, and data exchange services have all accumulated there over time. An IDMZ that has become a general-purpose network segment provides much weaker isolation than one that contains only the minimum necessary systems with explicitly defined data flows in both directions.

The Industrial Demilitarized Zone as a security control

The IDMZ is the architectural element that translates the Purdue Model's conceptual level separation into an actual security boundary. It sits between the OT levels and the enterprise IT network and contains systems that need to exchange data across that boundary. A well-designed IDMZ has a firewall facing the OT network, a separate firewall facing the enterprise network, and systems in between that are purpose-built for data exchange rather than general computing. No connection should pass directly through the IDMZ from one side to the other: all data transfers should terminate at a system inside the IDMZ and originate from that system toward the other side.

The historian replication pattern is the canonical example of correct IDMZ design. A Level 3 historian collects process data from the OT environment. A separate replication service inside the IDMZ pulls data from the Level 3 historian and makes it available to enterprise reporting systems. Enterprise systems query the IDMZ replication service, not the Level 3 historian. The OT firewall permits only the replication connection from the IDMZ into Level 3. The enterprise firewall permits only query connections from enterprise systems into the IDMZ. No path exists from the enterprise network into the OT environment, and no path exists from the OT environment into the enterprise network.

Remote access through the IDMZ follows a similar pattern. Vendors and remote operators authenticate to a jump host or remote access server located inside the IDMZ. From the jump host, they can access specific OT systems over permitted connections with session logging. The jump host is the single point of control: it enforces who can connect, what they can access, and provides a complete record of all activity. No VPN or direct tunnel should bypass this architecture by routing remote connections directly into OT network segments.

Where the model struggles: cloud, remote access, and IT/OT convergence

The Purdue Model was developed before cloud computing, ubiquitous internet connectivity, and software-as-a-service platforms existed. Modern industrial environments increasingly include cloud-connected sensors that send data directly to cloud platforms, vendor-managed devices that phone home to support portals, remote monitoring services that connect from the internet, and SCADA-as-a-service solutions where supervisory systems run outside the plant network entirely. None of these fit the traditional level hierarchy, and all of them create connectivity paths that the Purdue Model does not account for.

IT/OT convergence creates additional pressure on the model. Organizations looking to reduce costs and improve operational visibility increasingly run OT systems on shared IT infrastructure, use enterprise identity systems to manage OT access, and route OT data through enterprise network paths. These convergences are often justified by operational and financial benefits, but they collapse the level boundaries that the model relies on and can create exposure that neither the IT team nor the OT team fully owns or understands.

The appropriate response is not to abandon the Purdue Model but to treat it as a starting point rather than a complete solution. Modern ICS security frameworks, including IEC 62443 and the guidance in NIST SP 800-82 revision 3, acknowledge that the traditional model must be extended with zone and conduit analysis that accounts for non-traditional connectivity. The underlying principle, that different levels of criticality and risk should be separated by controlled boundaries, remains valid regardless of whether the specific level definitions map cleanly to the actual environment.

Using the Purdue Model for practical security architecture

The practical value of the Purdue Model in security work is as a structured way to ask where things are, what they communicate with, and whether those communication paths are appropriate. A security assessment that maps an OT environment against Purdue levels will quickly identify deviations: devices at Level 2 that communicate directly with Level 4 without crossing an IDMZ, remote access connections that terminate inside Level 1 rather than in the IDMZ, historians that accept connections from enterprise systems rather than pushing data upward through a controlled path.

Each deviation from the intended architecture is a potential finding, but not every deviation is equally significant. A Level 3 historian that has one additional connection to an enterprise reporting system may represent a minor policy exception. A direct connection from a corporate laptop network into a Level 1 PLC subnet is a critical architectural gap. Prioritizing findings requires understanding which deviations create paths that an attacker could exploit to move from a lower-privilege environment into a high-consequence control network.

The model also provides a vocabulary for communicating architecture decisions to stakeholders who are not network engineers. Explaining to operations managers and executive sponsors that the goal is to ensure that business systems cannot reach control systems directly, and that any data exchange crosses a monitored boundary, is easier with a reference model that has intuitive level labels than with raw network topology diagrams. The Purdue Model's enduring value is partly in its clarity as a communication tool, which is why it persists even as the underlying network architectures have evolved considerably beyond what the model originally described.