Origin and purpose
The Purdue Model was developed in 1992 by Theodore J. Williams and the Industry-Purdue University Consortium for Computer Integrated Manufacturing (CIM). Its original goal was not cybersecurity. It was a reference architecture for data flows in fully automated manufacturing plants, a structural map showing which systems live at which functional level and how information should travel between them.
Williams described the model as a way to rationalize the complex layering of systems in a large industrial enterprise: field devices feeding controllers, controllers feeding supervisory systems, supervisory systems feeding operations management, and operations management feeding the business network. That hierarchy was depicted as six numbered levels, each with a defined functional role. The insight that a PLC and an ERP system belong to different functional tiers with different latency requirements, different update cycles, and different failure consequences was the model's primary contribution.
Cybersecurity practitioners adopted PERA years after its publication, recognizing that the same functional hierarchy that described data flows also described attack paths. An adversary seeking to manipulate a physical process must traverse the levels from top to bottom. Each level boundary is therefore a logical place to implement a security control. The ISA-99 committee, which produced the IEC 62443 standard, explicitly adopted the Purdue level hierarchy as the conceptual foundation for its Zone and Conduit model. NIST SP 800-82 uses the same level numbering as its architecture reference throughout its guidance on OT security.
PERA was not designed as a security model. Theodore Williams designed it as an enterprise information architecture reference for manufacturing. The security community adapted it because the functional hierarchy it describes maps naturally onto defensive segmentation boundaries. This origin matters: the model describes where things are and how data should flow, not specifically which security controls to apply at each boundary. IEC 62443 provides the security specification that fills that gap.
The six levels explained
Each level of the Purdue Model represents a functional tier within the industrial enterprise, defined by the types of systems that reside there and the nature of the data they handle. As you move down from Level 5 toward Level 0, systems have more direct access to physical processes and fewer intrinsic security capabilities. Systems at lower levels depend on the architectural defenses applied at higher levels to compensate for their lack of built-in security features.
Level 5
Enterprise network
IT zoneEnterprise network
Email, file servers, corporate IT infrastructure, internet connectivity, enterprise WAN. This level has no direct connection to operational systems. It handles corporate business functions and is the entry point for threats originating from the internet or compromised corporate systems. Standard IT security controls (endpoint protection, SIEM, firewalls, email filtering) apply here.
Level 4
Site business / logistics
IT zoneSite business planning and logistics
ERP systems (SAP, Oracle), MES business logic, production scheduling, HR and financial systems at the site level, supervisor desktops, engineering workstations connected to the business network. Level 4 connects business planning functions to the manufacturing operations below. It receives production data from Level 3 and uses it for scheduling, inventory, and reporting. This is where IT-OT data integration most commonly creates security exposure when not properly controlled.
Industrial DMZIndustrial Demilitarized Zone (iDMZ)
Data historians, remote access jump servers, patch management servers, antivirus update servers, OT network monitoring dashboards, data diodes, OPC tunneling endpoints, MQTT brokers for OT-to-IT data transfer. The iDMZ was not in the original Purdue Model. It was added by security practitioners to address the problem of direct IT-to-OT connectivity. Nothing from Level 4 or above should ever have a direct network path into Level 3 or below. All traffic crossing the IT/OT boundary must terminate in the iDMZ first. This is the most security-critical boundary in modern ICS architecture.
OT zoneSite manufacturing operations and control
Manufacturing Execution Systems (MES), plant historians (OSIsoft PI, AVEVA, AspenTech), data acquisition servers, OPC servers, batch management systems, laboratory information systems (LIMS), reporting and analytics servers. Level 3 manages production workflow across the entire plant site. It orchestrates the processes running in Level 2. The historian at Level 3 collects data from SCADA and DCS at Level 2 for trend analysis, reporting, and regulatory compliance. OPC servers in this level aggregate device data for enterprise consumers.
Level 2
Area supervisory control
OT zoneArea supervisory control
SCADA systems, Distributed Control Systems (DCS), Human-Machine Interfaces (HMIs), engineering workstations, alarm management systems. Level 2 supervises and monitors specific processes or areas within the plant. Operators interact with physical processes through HMIs at this level. DCS and SCADA systems send commands down to Level 1 controllers based on setpoints, operator inputs, and automated logic. Engineering workstations at this level configure PLCs and are high-value targets because they have both network access and the ability to modify control logic.
OT zoneBasic process control
Programmable Logic Controllers (PLCs), Remote Terminal Units (RTUs), Intelligent Electronic Devices (IEDs), Safety Instrumented System (SIS) controllers, drive controllers. Level 1 devices receive commands from Level 2 supervisory systems and translate them into direct control actions on field devices at Level 0. PLCs execute control logic in millisecond scan cycles. RTUs connect field hardware in remote or distributed locations back to Level 2. These devices were designed for deterministic real-time control, not for security. Most lack authentication, encryption, or the ability to run security agents.
OT zonePhysical process
Sensors, transmitters, analyzers, actuators, valves, motors, pumps, drives, conveyor systems, robots, safety instrumented system (SIS) final elements. Level 0 is the physical world. These devices measure real process variables (temperature, pressure, flow, level, position) and execute control actions on physical equipment. They have the most direct consequence on safety, product quality, and environmental compliance. Most Level 0 devices communicate using simple serial or fieldbus protocols (HART, Profibus, Foundation Fieldnet, or direct 4-20 mA) with no network stack and therefore no network-based attack surface, but they are entirely dependent on the integrity of the Level 1 controllers that command them.
Why the level boundaries matter for security
The security value of the Purdue Model comes from treating each boundary between levels as a place to enforce controlled, inspected, and logged communication. In a flat network where every device can reach every other device, an attacker who compromises any single point has lateral access to everything. The Purdue level boundaries are the structural basis for eliminating that condition.
Security failure
Flat, unsegmented network
No enforced boundaries between levels. A corporate email workstation at Level 5 can reach a PLC at Level 1 with no network controls in between. This was the architecture of most industrial sites before security became a priority.
In 2017, the NotPetya ransomware started in office IT networks and spread freely to production OT systems because there were no effective barriers between them. Entire factories and ports were disabled for days. Companies that believed their industrial operations were secure found out painfully that a single infected IT link can cripple an entire production network.
An engineering workstation compromised by spear phishing has direct access to every PLC and HMI on the plant network. The only limit on lateral movement is the attacker's time and patience, not the network architecture.
Correct architecture
Purdue-segmented network
Enforced boundaries at the major level transitions. The iDMZ at Level 3.5 is the primary IT/OT boundary. No Level 4 or Level 5 system has a direct network path to Level 3 or below. All cross-boundary traffic terminates in the iDMZ first, where it can be inspected and logged.
If ransomware compromises a corporate workstation at Level 4 or 5, it cannot reach Level 2 DCS or Level 1 PLCs directly. It must overcome the iDMZ firewall and its explicit deny-all default posture before it can affect OT systems. This isolation gives the security team time to detect and contain the IT-side incident before it becomes an OT outage.
Within the OT zone, additional segmentation by process cell or production line limits blast radius further. A compromise in one production area cannot propagate to an adjacent area without crossing another controlled boundary.
The iDMZ at Level 3.5: the most important modern addition
The industrial Demilitarized Zone (iDMZ) was not part of Williams' original 1992 model. It was added by security practitioners over the following decade as the realities of IT/OT connectivity made a strict air gap between Levels 3 and 4 impractical. Today, the iDMZ at Level 3.5 is widely considered the single most important security control in any converged IT/OT architecture.
The iDMZ has a specific and narrow purpose: it is the only place where systems that need to communicate with both the IT side and the OT side are allowed to exist. A data historian that pulls process data from SCADA at Level 2 and serves it to enterprise analytics at Level 4 should not sit at Level 3 with an open path to both networks. It should sit in the iDMZ, where firewall rules explicitly define what it can initiate connections to and what connections it will accept.
What belongs in the iDMZ (Level 3.5)
Data historians (read-only replicas)
Historian servers that pull data from OT-side sources but are accessible to IT-side analytics and reporting consumers. The iDMZ placement means historians have no persistent connection into the OT zone beyond scheduled data collection.
Remote access jump servers
Bastion hosts or jump boxes that require explicit authentication before allowing any session into the OT network. Vendors and remote engineers connect to the jump server; the jump server provides controlled, session-specific, recorded access to OT systems.
OPC tunneling and data transfer endpoints
OPC tunneling endpoints (such as Cogent DataHub) that accept outbound connections from the OT side and expose OPC data to IT consumers. The OT-side instance initiates the outbound connection; no inbound port on the OT network firewall needs to be opened.
MQTT brokers for UNS data transit
An MQTT broker in the iDMZ receives Sparkplug B publications from edge nodes or OPC servers in the OT zone (outbound connections from OT) and exposes topic subscriptions to IT-side consumers. The broker is the single controlled egress point for OT data.
Patch and update servers
Patch distribution servers that receive updates from IT-side sources and stage them for controlled deployment into OT systems. OT devices never connect directly to the internet to retrieve updates; they pull from the iDMZ-hosted server after IT-side validation.
OT network monitoring dashboards
Passive OT monitoring tools (Claroty, Dragos, Nozomi) that collect visibility data from the OT network and present it to security operations teams on the IT side. Their management interfaces sit in the iDMZ; their OT-facing sensor taps are passive read-only.
The iDMZ rule: all IT-originated traffic must terminate in the iDMZ. No Level 4 or Level 5 system should ever initiate a connection that reaches Level 3 or below directly. This is not just a best practice; the January 2026 CISA/NCSC-UK joint guidance on OT connectivity explicitly states that all connections with the OT environment should be initiated as outbound connections from within the OT environment. The iDMZ enforces this by acting as the only permitted transit point and by applying deny-all default inbound rules on the OT-facing firewall.
Where the Purdue Model meets its limits
The Purdue Model was designed for a world where the IT and OT zones were functionally separate and data flowed in one direction: upward from sensors to enterprise systems. Several developments over the past decade have created tension with that assumption, without necessarily invalidating the model's core organizing principle.
IIoT devices
Sensors that bypass the hierarchy
Modern IIoT sensors and edge devices increasingly communicate directly with cloud platforms over cellular or WiFi, bypassing the Purdue level hierarchy entirely. A connected pressure transmitter that publishes to AWS IoT Core does not fit neatly into any level. These devices create connectivity paths that circumvent the iDMZ, since their communications originate at Level 0 or 1 but terminate in the cloud rather than in the OT network. Organizations must decide whether to route IIoT cloud traffic through a controlled proxy in the iDMZ or to treat IIoT devices as a separate zone with their own conduit rules.
Cloud analytics
No defined place for cloud in the original model
The original Purdue Model has no cloud tier. Historian replication to cloud data lakes, remote SCADA access through cloud-hosted gateways, and AI/ML model deployment into edge nodes all require data paths that the six-level hierarchy does not explicitly accommodate. The practical resolution is to treat cloud platforms as a logical extension of Level 5, with all connectivity flowing through the iDMZ (for OT-originated data) or through the Level 5 enterprise perimeter (for IT-to-cloud traffic), never directly from OT levels to cloud without passing through a controlled boundary.
Flat OT networks
Many plants never implemented the segmentation in the first place
The Purdue Model describes a desired architecture. Many real industrial networks are flat, with PLCs, HMIs, historians, and engineering workstations on the same network segment with no enforcement boundaries between them. Implementing proper Purdue-aligned segmentation in a running plant is technically complex, requires coordinated downtime, and demands cooperation between OT and IT teams who may not have a history of working together. The model is well understood; its implementation at legacy sites remains an ongoing challenge rather than a completed baseline.
Remote operations
Bidirectional data flows that the model did not anticipate
The Purdue Model assumes upward data flow: sensor data rises through the levels to reach enterprise consumers. Modern operations require downward flows as well: configuration updates pushed from cloud-based tools to field controllers, patch files distributed from IT-side repositories to OT devices, and remote operations center commands sent to plant-floor systems. Each downward flow is a potential attack vector if not controlled, because it provides a path for malicious content to travel toward the physical process. The iDMZ handles this by staging all downward-bound content for inspection before it can proceed into the OT zone.
The mainstream position, held by SANS Institute, IEC 62443 working groups, and the DoD's November 2025 Zero Trust for Operational Technology guidance, is that the Purdue Model's core principle of functional separation remains valid and its level taxonomy remains the authoritative vocabulary for describing OT architecture, even as the physical topology of modern industrial networks differs from what Williams originally described. Adapt the implementation; retain the principle.
How SWTB products map to the Purdue levels
Software Toolbox products sit at specific points in the Purdue architecture and are designed to work with the level boundaries rather than create uncontrolled paths through them. Understanding where each product lives in the hierarchy, and what boundary it manages, is important for both deployment planning and security architecture reviews.
Level 3.5 iDMZ
Cogent DataHub: the iDMZ data transfer anchor
DataHub is specifically architected for deployment in the iDMZ. The OT-side DataHub instance (at Level 3 or below) initiates an outbound connection to the IT-side or iDMZ-hosted instance; no inbound port needs to be opened on the OT network firewall. This outbound-only connection model directly implements the CISA/NCSC-UK 2026 guidance that all OT environment connections should be initiated from within the OT environment. Data diode mode enforces one-way-only data flow from OT to IT, making reverse connections architecturally impossible. The iDMZ DataHub instance becomes the single controlled point through which OPC data crosses the Level 3.5 boundary.
Level 3
TOP Server: OPC server at the Level 3 data collection layer
TOP Server is typically deployed at Level 3, where it aggregates real-time data from Level 2 SCADA and Level 1 PLC devices and exposes it as OPC DA and OPC UA to Level 3 consumers (historians, MES, reporting) and, via the iDMZ, to Level 4 enterprise systems. Placing TOP Server at Level 3 concentrates all OT device connections in the OT zone: Level 4 enterprise applications never need direct protocol-level access to PLCs or SCADA. This reduces the number of processes with direct device protocol access and limits the inbound connection surface on lower-level devices to a single, auditable OPC server.
Level 3
OPC Router: auditable cross-level data routing
OPC Router is deployed at Level 3 to create explicit, documented data flows between OT-side OPC sources and IT-side databases, cloud platforms, and enterprise systems. Its visual workflow model produces an auditable record of which data flows from which OT source to which IT destination under which conditions. For IEC 62443 conduit documentation requirements, OPC Router's workflow export is a practical artifact for security reviews. Rather than undocumented direct connections from historians to enterprise databases, OPC Router creates controlled, inspected, and logged data pipelines across the Level 3-to-4 boundary via the iDMZ.
Level 2–3 edge
N3uron: edge platform at Level 2/3 with iDMZ-hosted broker
N3uron edge nodes are typically deployed at Level 2 or Level 3, where they collect data from Level 1 and Level 2 devices using built-in protocol drivers and publish to an MQTT broker using Sparkplug B over TLS. For Purdue-aligned architectures, the MQTT broker is hosted in the iDMZ. N3uron's outbound MQTT connection from the OT zone to the iDMZ-hosted broker follows the same outbound-only principle as DataHub tunneling: no inbound port needs to be opened on the OT-side firewall. IT-side analytics, cloud pipelines, and the Unified Namespace all subscribe from the iDMZ broker, never connecting directly into the OT zone.
Level 3–4
Historian and Lakehouse Connectivity: bridging Level 3 to enterprise
SWTB's Historian and Lakehouse Connectivity service addresses the specific problem of securely replicating OT historian data to cloud data lakes and enterprise analytics platforms. In Purdue terms, this is the Level 3-to-Level 4/5 data path via the iDMZ. The service is designed to flow data upward through the iDMZ to cloud targets without creating persistent inbound connections into the OT zone, maintaining the boundary integrity that the Purdue Model requires.
Frequently asked questions
Is the Purdue Model the same as ISA-95 and ISA-99?+−
These are related but distinct. ISA-95 (IEC 62264) is an international standard for integrating enterprise and control systems. It uses the same level numbering as PERA (Levels 0 through 4) because it was developed with explicit reference to the Purdue work. ISA-95 and the Purdue Model are sometimes used interchangeably, but ISA-95 is a more formalized international standard with specific guidance on integration models, object models, and data exchange, while PERA is the broader reference architecture it drew from.
ISA-99 (now IEC 62443) is a security standard series for Industrial Automation and Control Systems. It explicitly adopted the Purdue level hierarchy as the structural basis for its Zone and Conduit model, where zones group assets at similar security levels and conduits are the controlled pathways between zones. IEC 62443 provides the security specification that PERA does not: specific guidance on what security controls to implement at each level and boundary, how to assess security levels, and how to manage the security lifecycle of OT systems.
What is the difference between the Purdue Model and Zero Trust?+−
The Purdue Model is a segmentation architecture: it defines where different types of systems should be placed and what the boundaries between zones should look like. It assumes that systems within a zone are more trusted than systems crossing a boundary, and that firewalls at zone boundaries enforce the security policy.
Zero Trust is a security philosophy that challenges the idea that network location should determine trust. Under Zero Trust, no system, user, or device is trusted by default, regardless of where it sits in the network. Every access request must be verified, authorized, and continuously monitored.
In practice, these are complementary rather than competing. The Purdue Model defines the structural zones; Zero Trust principles define the verification and access control policy applied at each boundary. The iDMZ at Level 3.5 is a natural place to implement Zero Trust controls: every connection crossing the boundary must be explicitly authenticated and authorized, not merely passed through because it came from a trusted network segment. The DoD's November 2025 Zero Trust for Operational Technology guidance explicitly treats the Purdue Model's zone taxonomy as the architectural foundation to which Zero Trust verification is applied.
My site already has a historian at Level 3. Do I need an iDMZ?+−
It depends on what network connections your historian has. If your historian at Level 3 has both a direct connection to Level 2 SCADA systems for data collection and a direct connection to Level 4 enterprise systems for reporting and analytics, it is bridging the IT/OT boundary directly. Any compromise of the historian, or of the Level 4 system that connects to it, creates a path into your OT network.
The iDMZ-aligned approach is to separate the historian's two roles. The OT-facing data collection function should be in the OT zone (Level 3), and the IT-facing data serving function should be in the iDMZ. Cogent DataHub's tunneling model is one way to implement this: the OT-side DataHub instance collects from the historian and tunnels data outbound to an iDMZ-hosted instance, which then serves enterprise consumers. The historian itself never needs an inbound connection from the IT network.
If implementing a full iDMZ is not immediately feasible, the minimum compensating control is to ensure that the historian's IT-facing connection has no route into the OT zone: the historian should have no routing path to Level 1 or Level 2 systems beyond what is required for its scheduled data collection queries. Firewall rules should enforce this explicitly, not by convention.
Does the Purdue Model apply to water/wastewater or oil and gas SCADA, or is it just for manufacturing?+−
The Purdue Model applies across all industrial sectors, not just manufacturing. Water and wastewater utilities, oil and gas pipeline operators, electric utilities, chemical plants, and transportation infrastructure all use the same level taxonomy to describe their OT architecture. The specific systems at each level differ by industry, but the structural relationships are consistent.
For geographically distributed systems like pipeline SCADA or water distribution networks, the Purdue levels describe a logical rather than a physical hierarchy. A remote pump station might have only Level 0 and Level 1 devices, with the Level 2 SCADA system hosted centrally at the operations center. The communication path between the remote RTU (Level 1) and the central SCADA (Level 2) crosses a wide-area network, which introduces additional security considerations around encrypted communications and secure remote access that do not apply in a co-located plant environment.
NotPetya is often cited as the reason to implement Purdue segmentation. What happened?+−
In June 2017, the NotPetya malware began spreading globally, initially through a compromised update mechanism for a Ukrainian accounting software package. The malware used multiple propagation techniques including the EternalBlue exploit for Windows SMB and credential theft, allowing it to spread rapidly across networks without requiring any user interaction after the initial infection.
Several major manufacturing and logistics companies suffered severe disruptions because their IT and OT networks were connected without effective segmentation between them. Once NotPetya reached the corporate IT network, it had unobstructed paths to production systems: HMI workstations running Windows, SCADA servers, and MES systems. Factories, shipping terminals, and pharmaceutical production lines were halted for days to weeks. Maersk shipping, Merck pharmaceutical, and Mondelez food manufacturing were among the most heavily affected. Total losses were estimated above $10 billion across all affected organizations.
The lesson was stark: these were not targeted attacks against industrial systems. NotPetya had no specific OT capability. It was a general-purpose Windows network worm that caused catastrophic OT damage solely because the network architecture allowed it to move freely from IT to OT without encountering any controlled boundary. Proper iDMZ implementation would not have prevented the IT-side infection but would have contained it to the IT zone, preventing any direct impact on production systems.
Where does a Unified Namespace (UNS) fit in the Purdue Model?+−
A Unified Namespace is a logical data architecture built on an MQTT broker, not a physical network tier. In Purdue terms, a correctly implemented UNS has its MQTT broker hosted in the iDMZ at Level 3.5. OT-side publishers (N3uron edge nodes, OPC servers, DCS systems with MQTT capability) connect outbound from the OT zone to the broker. IT-side subscribers (analytics platforms, cloud services, enterprise applications) connect to the broker from Level 4 or above. The broker is the single controlled point where all OT data surfaces to IT consumers.
This architecture preserves the Purdue segmentation principle while enabling the UNS's goal of making all OT data available in a standardized topic namespace. The MQTT broker in the iDMZ becomes the "single source of truth" layer for the enterprise, and the OT zone remains protected behind the Level 3.5 boundary. N3uron and Cogent DataHub both support this architecture pattern, with N3uron publishing Sparkplug B to the iDMZ broker and DataHub tunneling providing the controlled OPC data path through the same boundary.
