If you have sat through an OT architecture review, you have seen the diagram: a neat stack of boxes, labelled Level 0 at the bottom and Level 5 at the top, with a firewall somewhere in the middle. It is probably the most reproduced picture in industrial cybersecurity, and it is also one of the most misunderstood. 

The Purdue model was never meant to be a security framework. It started as a way to describe how a factory is organised. Security teams adopted it because it gave them something they badly needed: a shared vocabulary for where things live and who is allowed to talk to whom. Decades later, regulators, standards bodies and attackers all still reason about industrial networks in these terms. 

This blog is written for CISOs, OT security leads and architects who already know the basics and want a precise reference. We cover each of the Purdue model levels with concrete examples, the Level 3.5 industrial DMZ, how the model maps to IEC 62443 and NIST SP 800-82, where it breaks down in modern plants, and the guidance published recently that changes how you should apply it. 

What is the Purdue model? 

The Purdue model, formally the Purdue Enterprise Reference Architecture (PERA), was developed at Purdue University in the late 1980s and early 1990s by Theodore Williams and colleagues. Its original goal was computer-integrated manufacturing: showing how business planning, plant operations, control systems and physical equipment fit together. 

It was later adopted into the ISA-95 standard family, which defines a functional hierarchy between enterprise and control systems. Industrial cybersecurity then borrowed it, because a hierarchy of functions maps naturally onto a hierarchy of trust. The more directly a system touches the physical process, the more carefully you want to control what can reach it. 

Two ideas sit underneath everything else: 

1. Each level should communicate mainly with the level directly above and below it. A business laptop should not be talking to a PLC. 

2. Traffic crossing between the enterprise side and the plant side should pass through a controlled, monitored point. That is the job of the industrial DMZ. 

Purdue model levels at a glance 

Naming varies a little between sources. Some diagrams label Level 4 as site business planning and Level 5 as the enterprise, others fold them together. Do not argue about the labels in a workshop. Agree on what lives where in your own environment and document it. 

Level 0: The physical process 

Level 0 is where the real world happens: temperature probes, flow meters, pressure transmitters, motor drives, valve actuators, conveyor sensors. These devices measure and move physical things. 

Examples: 

• A level sensor in a water tank 

• A variable frequency drive controlling a pump motor 

• A pressure transmitter on a gas pipeline 

• A circuit breaker actuator in a substation 

Why it matters for security. Most Level 0 devices have little or no authentication, and many speak simple protocols such as 4-20 mA analog signals, HART or fieldbus links. You rarely attack them over an IP network. Instead, attackers aim for the layers above and manipulate what these devices are told to do. Smart instruments with IP connectivity are a growing exception, and they deserve the same inventory discipline as anything else. 

What to do here: physical access control, tamper detection, and engineering for safe failure. A cyber event should never be able to push the process into an unsafe state without an independent safeguard stopping it. 

Level 1: Basic control 

Level 1 holds the devices that read Level 0 inputs and decide what to do: programmable logic controllers (PLCs), remote terminal units (RTUs), DCS controllers and safety instrumented system (SIS) controllers. 

Examples: 

• A Siemens, Rockwell or Schneider PLC running a bottling line 

• An RTU at a remote pumping station 

• A safety controller that trips a furnace on over-temperature 

Why it matters for security. Controllers execute logic that physically changes the process. Protocols such as Modbus/TCP, EtherNet/IP, PROFINET and S7comm were designed for reliability, not authentication, so a reachable controller will often accept commands from anyone who can talk to it. The 2017 Triton (TRISIS) malware, which targeted a safety controller, shows what happens when Level 1 is reached: attackers can tamper with the very system meant to prevent disasters. 

What to do here: 

• Lock controllers into run mode where possible and restrict program or download access 

• Allow only named engineering workstations to write to controllers 

• Monitor for unexpected logic changes and unusual function codes 

• Keep safety controllers on separate, tightly controlled networks 

Level 2: Area supervisory control 

Level 2 is where operators see and steer the process. It contains HMIs, local SCADA servers, alarm management systems and, importantly, engineering workstations. 

Examples: 

• A control-room HMI showing a treatment plant's pumps and tanks 

• A SCADA server polling a group of RTUs 

• An engineering laptop used to program PLCs 

Why it matters for security. Level 2 is the first point where Windows-based systems appear in large numbers, so it inherits IT-style risks: unpatched operating systems, USB media, shared accounts and remote access tools. The 2021 Oldsmar water treatment incident, where an operator watched a cursor move on an HMI that had remote access software enabled, is a clear example of how a supervisory layer exposed to remote access can become the attack path. 

What to do here: 

• Application allow-listing on HMIs and engineering stations 

• Individual accounts with role-based access, not shared operator logins 

• Strict control over removable media and laptops 

• No direct internet access and no unmanaged remote access software 

Level 3: Site operations 

Level 3 supports the whole site: data historians, manufacturing execution systems (MES), OT Active Directory or authentication servers, patch and antivirus staging servers, and file servers for engineering data. 

Examples: 

• A process historian collecting tags from across the plant 

• An MES that schedules production batches 

• A WSUS or patch staging server for the OT network 

• A local domain controller serving OT users 

Why it matters for security. Level 3 is the aggregation point. It touches many Level 2 systems and also has legitimate reasons to exchange data with the business. That makes it attractive, and it is where IT-style compromises most often turn into OT problems. Domain trust relationships between corporate and OT Active Directory are a frequent culprit. 

What to do here: 

• Separate OT identity infrastructure from corporate identity wherever practical 

• Keep Level 3 servers hardened and patched on a managed schedule 

• Use allow-listed, one-directional or brokered data flows to the business 

• Collect logs centrally and watch them 

Level 3.5: The industrial DMZ 

The model's original diagram goes 0 to 5. Practitioners added Level 3.5 because the jump from site operations to the enterprise network needed its own control layer. It is not part of the original Purdue model, but it is now treated as essential. The US Department of Energy has described this abstract layer as essential to keep communications separated as OT and IT converge. 

What belongs here: 

• Jump servers or remote access gateways for vendors and engineers 

• Historian replicas that the business can query instead of the real historian 

• Patch and antivirus relays 

• File transfer or data diode systems 

• Reverse proxies for dashboards and APIs 

The rules that make a DMZ real: 

• No direct sessions between Level 4 and Levels 0 to 3. Every flow terminates in the DMZ and a new session starts on the other side 

• Deny by default, in both directions. Outbound rules deserve as much care as inbound ones 

• Multi-factor authentication on every remote path 

• Full logging of what crosses the boundary, with someone actually reviewing it 

• No shortcuts: if there is a second, undocumented path around the DMZ, you do not have a DMZ 

In practice, the most common failure is not a badly built DMZ. It is a perfectly good DMZ sitting next to a forgotten cellular modem, vendor VPN or dual-homed engineering laptop. 

Level 4: Site business planning and logistics 

Level 4 is the plant's business network: ERP, email, scheduling, inventory, reporting and corporate user devices. 

Examples: 

• SAP or Oracle ERP pulling production totals 

• A supply-chain system ordering raw materials 

• Business analysts building reports from plant data 

Why it matters for security. This is where most intrusions start: phishing, stolen credentials, ransomware. The goal is not to make Level 4 invulnerable. It is to make sure that when Level 4 is compromised, the damage stops there. Colonial Pipeline in 2021 illustrates the difference between a compromised business network and a compromised process. The ransomware hit IT systems, but the company halted pipeline operations as a precaution because it could not be confident it could separate the two safely. 

Level 5: Enterprise network and external connectivity 

Level 5 covers the wider corporate network, headquarters systems, cloud platforms, partner links and the internet. 

Examples: 

• Corporate data centres and SaaS platforms 

• Cloud-hosted analytics or predictive maintenance services 

• Third-party connections to suppliers and service providers 

Why it matters for security. Cloud analytics and remote monitoring are now routine, which means data and sometimes control paths extend beyond the enterprise boundary. Treat any cloud service that ingests OT data as part of your attack surface, and apply the same scrutiny you would to a new Level 3.5 component. 

How the Purdue model maps to IEC 62443 and NIST SP 800-82 

The Purdue model is a map. The standards tell you what to do with it. 

ISA/IEC 62443 takes the Purdue idea and formalises it into zones and conduits. A zone is a group of assets sharing the same security requirements. A conduit is the controlled communication channel between zones. Rather than just drawing levels, you perform a risk assessment (IEC 62443-3-2), assign target security levels to each zone, and select technical requirements (IEC 62443-3-3) to meet them. A single Purdue level may contain several zones, and a zone can span more than one level. 

NIST SP 800-82 uses the Purdue model as its example architecture for segmented OT networks. Revision 3, published in September 2023, provides an OT overlay for the SP 800-53 control catalog and detailed guidance on firewalls, DMZs and segmentation, with an explicit reminder that security controls must be evaluated against their effect on safety and performance. 

Where the Purdue model starts to break 

Here is the honest part. A strictly layered plant is increasingly rare. Several forces are bending the model out of shape: 

• IIoT and smart sensors that connect straight to cloud platforms and skip Levels 1 to 3 entirely 

• Remote vendor access via cellular routers, VPN appliances and third-party tools 

• IT/OT convergence projects such as unified namespace architectures, where data flows more freely between layers by design 

• Virtualisation and containers that put Level 2 and Level 3 workloads on shared infrastructure 

• Wireless and 5G private networks that cut across the physical layout the model assumed 

• Legacy systems with 15 to 25 year lifecycles, which means modern controls cannot be installed on much of what the model protects 

None of this makes the Purdue model obsolete. It makes it a starting point. The practical lessons: 

1. Use it to find your shortcuts. Draw your real network and mark every path that bypasses Level 3.5. Those paths are your priority list. 

2. Be willing to micro-segment inside a level. A flat Level 2 with fifty unrelated systems is a single blast radius. 

3. Do not assume a level is trustworthy because of where it sits. Which brings us to zero trust. 

Latest developments you should know about 

The guidance landscape has moved quickly. These are the updates most relevant to anyone applying the Purdue model today. 

NIST SP 800-82 Revision 4: initial public draft 

NIST began the revision with a pre-draft call for comments in January 2026, then published the initial public draft of SP 800-82 Revision 4 on September 21, 2026. Public reporting indicates the draft realigns the guide with NIST Cybersecurity Framework 2.0 and brings in stronger zero trust concepts. The comment period runs through November 30, 2026, so there is still time for your team to contribute. If your OT programme is mapped to Revision 3, begin reviewing what will change. 

Zero trust guidance for OT (April 2026) 

In late April 2026, CISA, the US Department of War, the Department of Energy, the FBI and the Department of State jointly published what has been described as the first comprehensive guidance on applying zero trust principles to operational technology. It treats an accurate asset inventory as foundational. The takeaway for Purdue users: zero trust does not replace segmentation, it adds continuous verification on top of it. A device in Level 2 is not trusted just because it is in Level 2. 

Secure Connectivity Principles for OT (January 2026) 

The UK's NCSC, with CISA, the FBI and other international partners, released Secure Connectivity Principles for Operational Technology. It sets out eight principles for designing, securing and managing connectivity into OT environments, including that all connectivity should be logged and monitored and that organisations should establish an isolation plan, meaning a tested way to cut OT off from external networks quickly when needed. These are framed as desirable end-states rather than minimum requirements, and they apply directly to how you design your Level 3.5 and any remote access path. 

Asset inventory and a definitive view of OT architecture (2025) 

In August 2025, CISA and partners released Foundations for OT Cybersecurity: Asset Inventory Guidance for Owners and Operators. It was followed in late September 2025 by joint guidance on maintaining a definitive record of your OT architecture. The message is consistent: you cannot apply a Purdue model to a network you cannot see. Your diagram is only as good as the inventory behind it. 

Internet-exposed OT devices remain a live problem 

In mid-2026, CISA warned of malicious activity against internet-exposed PLCs in the water and wastewater sector, including access paths through undocumented cellular modems, according to industry reporting. That is the Purdue shortcut problem in its purest form: a perfectly designed hierarchy undone by a modem nobody documented. 

Regulation is raising the floor 

In the EU, the NIS2 Directive has pushed OT-heavy sectors toward formal risk management, supply-chain accountability and incident reporting. Together with the US guidance above, the direction is clear: regulators increasingly expect demonstrable asset visibility, controlled connectivity and defensible segmentation, which is exactly what a well-applied Purdue model supports. 

Practical checklist: applying the Purdue model today 

Use this as a working checklist for your next architecture review. 

1. Build the inventory first. Passive discovery for OT, active where safe, reconciled against engineering records. 

2. Map real flows, not intended ones. Capture actual communications between levels and compare them with your diagram. 

3. Find every bypass of Level 3.5. Cellular routers, vendor laptops, dual-homed servers, forgotten VPNs. 

4. Enforce deny-by-default at each boundary, inbound and outbound, with rules tied to named assets and protocols. 

5. Break sessions in the DMZ. No direct IT-to-OT connections. Use jump hosts with MFA and session recording. 

6. Separate identity. OT directory services should not trust the corporate domain by default. 

7. Segment within levels where assets differ in criticality, particularly Level 2 and Level 3. 

8. Monitor at the boundaries and inside the zones with OT-aware detection that understands industrial protocols. 

9. Plan for isolation. Rehearse how you cut OT off from the enterprise, and what the plant can still do when you do. 

10. Protect safety systems separately, and test them as part of your cyber exercises. 

11. Map zones to IEC 62443, assign target security levels, and record the justification. 

12. Revisit it regularly. Architecture drifts. Review after every major change, vendor engagement or acquisition. 

Common mistakes we see in the field 

• Treating the diagram as the defence. The drawing is not the network. Verify it. 

• A DMZ that allows any-to-any outbound. Egress control is where many compromises are finally stopped. 

• Putting the historian directly in front of the business. Use a replica in the DMZ. 

• Shared admin credentials across IT and OT. One stolen password then opens both worlds. 

• Ignoring Level 1. Many programmes invest heavily at Levels 3 to 5 and have almost no visibility into controller traffic. 

• Assuming an air gap exists. Most do not, once you count modems, USB media and maintenance laptops. 

Key takeaways 

• The Purdue model splits an industrial environment into functional levels, from the physical process (Level 0) up to the enterprise and internet-facing layer (Level 5). 

• Level 3.5, the industrial DMZ, is the single most important control point. Almost every serious IT-to-OT intrusion path crosses it, or goes around it. 

• The model is a reference architecture, not a compliance checklist. Its security value comes from segmentation, controlled conduits and visibility at each boundary. 

• Cloud analytics, IIoT, remote vendor access and cellular connections have weakened the strict hierarchy. Treat Purdue as a baseline to adapt, not a drawing to defend. 

• Recent guidance from CISA, NCSC-UK and partners, and the new NIST SP 800-82 Revision 4 draft, point toward asset visibility, tightly managed connectivity and zero trust principles layered on top of segmentation. 

Frequently asked questions 

What are the Purdue model levels? 

The Purdue model organises an industrial environment into levels: Level 0 (physical process), Level 1 (basic control), Level 2 (area supervisory control), Level 3 (site operations), Level 4 (site business planning), and Level 5 (enterprise and external networks). Level 3.5, the industrial DMZ, sits between Levels 3 and 4 and is widely used in security designs. 

What is Level 3.5 in the Purdue model? 

Level 3.5 is the industrial demilitarised zone. It is a buffer layer between the OT network (Levels 0 to 3) and the business network (Levels 4 and 5), where jump servers, data replicas and remote access gateways live so that no direct session ever crosses between IT and OT. 

Is the Purdue model still relevant? 

Yes, but not as a rigid rulebook. It remains the common language for OT segmentation and underpins guidance such as NIST SP 800-82 and IEC 62443. Cloud connectivity, IIoT and remote access mean you need to adapt it, add micro-segmentation and layer zero trust principles on top. 

What is the difference between the Purdue model and ISA-95? 

ISA-95 is a standard that defines the functional hierarchy and information exchange between enterprise and control systems. The Purdue model is the reference architecture that inspired it. In security conversations, the two are often used interchangeably to describe the same levels. 

How does the Purdue model relate to IEC 62443? 

IEC 62443 turns the Purdue idea into an engineering method. You group assets into zones, define conduits between them, assess risk, and assign security levels. Purdue levels are a convenient starting point for defining those zones. 

Does zero trust replace the Purdue model? 

No. Recent government guidance treats zero trust as an addition to segmentation, not a substitute. Purdue-style zoning limits where an attacker can move, and zero trust makes every request prove itself. 

What is the biggest weakness of the Purdue model? 

It assumes traffic follows the hierarchy. Real networks are full of shortcuts such as cellular modems, vendor VPNs and cloud-connected devices that quietly bypass the layers. 

How Shieldworkz can help 

Shieldworkz is an end-to-end industrial OT cybersecurity company covering SCADA, OT and IoT environments across critical infrastructure. We bring services, platform and solutions together so that customers do not have to stitch several vendors into one programme. 

For teams working on their Purdue architecture, that typically means: 

• OT asset discovery and architecture review to build the real map of what is connected and where the shortcuts are 

• Segmentation and DMZ design aligned with IEC 62443 zones and conduits 

• Continuous monitoring and threat detection that understands industrial protocols across Levels 0 to 3.5 

• Compliance support for IEC 62443, NIST SP 800-82 and NIS2 requirements 

• Incident response readiness, including isolation planning and tabletop exercises 

If you would like an independent view of how your environment lines up against the Purdue model and the latest guidance, speak to a Shieldworkz OT security specialist to schedule an architecture assessment.