The Purdue Model is not a network security model – it just acquired that reputation.
Technical Definition: The Purdue Model (formally PERA – Purdue Enterprise Reference Architecture) is a reference architecture developed at Purdue University in 1994 for structuring information flows in manufacturing enterprises. It defines five hierarchical levels – from sensors and actuators at Level 0 to enterprise business systems at Level 4/5 – describing how information should flow between them.
Level overview: Level 0 – physical process (sensors, actuators). Level 1 – sensing and control (PLCs, DDC). Level 2 – supervisory control (HMI, local SCADA). Level 3 – operations and MES. Level 4 – enterprise (ERP, business systems). Level 5 – cloud and external services.
The most common misconception: Despite appearing in nearly every OT security presentation, the Purdue Model was never designed as a network security model. Grouping all sensors together and all PLCs together – because they happen to be on the “same Purdue level” – is a misapplication that creates networks which don’t reflect how production actually works. Adding a DMZ between IT and OT (the typical “modified Purdue” approach) doesn’t go very far in practice.
The right framework for OT network segmentation: IEC 62443-3-2 “Zones & Conduits” – where you design security zones based on process dependencies and risk profile, not technology type. Key design dimensions to hold in mind simultaneously:
- Process dependency – Keep assets that depend on each other and support the same production process together. Segmentation must not create new risks at sensitive points.
- Blast radius – Ensure independent parts of production can’t disrupt each other if one is compromised.
- Visibility and control – Design the network so that security monitoring of all critical traffic is feasible and manageable. Complexity is the enemy.
- Isolation resilience – Can you run production without connectivity to IT networks or cloud? For how long? How difficult is reconnection?
- Cross-cutting dependencies – Segmentation isn’t just about the network. What crosses your boundaries and can short-circuit the separation? Backups, Active Directory, remote access, data collection, clock synchronisation.
- Legacy and end-of-life systems – Every facility has systems nobody dares decommission. How do you protect them – and how do you protect the rest of the network from them?
HubMind’s view: We use Purdue levels as a shared vocabulary for mapping integration architectures and information flows – but we design security zones using IEC 62443-3-2 Zones & Conduits. A security architecture needs to reflect how the process actually works, not how levels happen to be labelled.
External links: The original PERA is documented at pera.net. For the proper security framework: read IEC 62443-3-2 and see the HubMind entry on Zones & Conduits. NIST SP 800-82 is also useful – but note that it muddies the picture a little with its Purdue references.
« Back to Glossary Index