It originated in work on computer-integrated manufacturing and influenced the functional hierarchy used by ISA-95 and IEC 62264. Security architects commonly adapt the layers to reason about trust boundaries, communication paths, and placement of an industrial DMZ.
The model is a way to describe functions, not a mandatory network blueprint. Layer numbering and the familiar “Level 3.5” DMZ vary among implementations, and a modern environment may include cloud services, edge computing, wireless systems, IIoT devices, remote operations, and shared platforms that do not fit a simple vertical hierarchy. Architecture decisions should follow actual functions, hazards, ownership, and data flows.
Key points
Map what existsPlace assets by operational function and dependency rather than by device name, supplier, IP range, or an idealized diagram.
Identify required flowsDocument source, destination, direction, protocol, timing, purpose, and failure behavior before designing boundaries.
Enforce separationUse firewalls, proxies, unidirectional gateways, an IDMZ, or other suitable controls to prevent unnecessary direct communication between distant trust levels.
Document exceptionsRecord cloud, remote, safety, mobile, and cross-site connections that bypass or extend the hierarchy, assign owners, and apply compensating controls.
Important limitationA Purdue diagram is not evidence of segmentation or safety. Flat routes, shared credentials, unmanaged maintenance links, vulnerable boundary services, or poorly designed failure behavior can defeat the intended architecture and disrupt operations.