The Purdue model is a reference architecture that groups industrial systems into numbered levels, from sensors at Level 0 up to business systems at Levels 4 and 5. Security teams use it to decide where firewalls go and which levels may talk to each other. It is a planning aid, not a standard you certify against.
Where does the model come from?
NIST's guide to operational technology security (SP 800-82 Revision 3) cites the Purdue Enterprise Reference Architecture as the origin of the idea, and notes that the ISA-95 standard grew from the Purdue Reference Model for Computer Integrated Manufacturing. The model was built to describe how plants integrate control and business systems. Security use came later, because the levels happen to map neatly onto trust boundaries.
NIST lists it as one option, next to ISA-95 levels and the three-tier industrial IoT architecture. It says organizations may use one of these models or a mix to organize segmentation. Nothing in the guide makes Purdue mandatory.
What do the levels mean?
In NIST's description, the field level covers devices usually found at Purdue Levels 0, 1 and 2: sensors and actuators, controllers and local supervisory equipment. The operations management level covers monitoring and management of field devices and the Level 3 components. A demilitarized zone bridges operations and enterprise tiers. Levels 4 and 5 hold business and enterprise systems.
Level 0 is the hard one. NIST notes that many Field I/O devices and protocols cannot be authenticated, so data can potentially be replayed, modified or spoofed. NIST recommends a risk-based choice about where to add compensating controls, such as digital twins or a separate monitoring network for field I/O, to catch incorrect data.
How is it used for segmentation?
NIST gives a concrete firewall rule: connections should be permitted only between adjacent levels, tiers or zones. Its example is that firewall rules should prevent Level 4 devices from communicating directly with Level 2, 1 or 0 devices.
It also flags outbound traffic. Practice varies on how tightly to control connections leaving the control network, and NIST suggests making outbound rules as strict as inbound ones, because unmanaged outbound paths from lower levels are a significant risk.
A constructed example: a bottling plant has a historian server at Level 3 that engineers want to query from the office network. Instead of opening a rule from the office straight to the controllers, the team places a replica of the historian in the DMZ. The office reads the replica, the replica pulls from Level 3, and no office device ever has a route to Level 2 or below.
Where does the model fall short?
Real plants have shortcuts. Cloud analytics, remote vendor access and industrial IoT sensors that report to the internet cut across the neat layers. NIST accounts for this by presenting the industrial IoT three-tier model beside Purdue, and by discussing zero trust. On zero trust, it cautions that a full implementation might not be practical for devices that lack support, and suggests applying it to compatible devices at the higher levels, Levels 3, 4, 5 and the DMZ.
Two other limits are worth stating. A diagram of levels says nothing about which flows are legitimate until you inventory them. And adjacency rules only help if firewalls are configured and reviewed. A level model with an "any to any" rule between Levels 3 and 2 provides no protection.
How to check or apply this
- Inventory OT assets and map each to a level or zone. If you cannot place a device, that is a finding.
- List every flow between levels with its owner and purpose.
- Write firewall rules so that only adjacent levels connect, and review them at a fixed interval.
- Put a DMZ between the operations and enterprise tiers, and keep shared services there.
- Apply outbound rules as strictly as inbound ones from the control network.
- For Level 0, decide where data integrity checks or separate monitoring are justified by process risk.
- Treat remote vendor and cloud paths as extra zones with their own rules, not exceptions.
Safeguard's asset discovery and dependency scanning cover software assets and their known vulnerabilities, for example in the applications that sit at the upper levels. It is not an OT network security product.
Quick check
Is the Purdue model a compliance requirement?
No. NIST presents it as one of several models that can organize OT network segmentation. You can use it, use ISA-95 or IIoT tiers, or combine them.
What is the simplest firewall rule the model suggests?
Allow connections only between adjacent levels. For instance, Level 4 devices should not talk directly to Level 2, 1 or 0 devices.
Sources
Last reviewed: 18 October 2026.
