Purdue Model Limitations and Alternatives for Modern OT

Understanding the Purdue Model

The Purdue Enterprise Reference Architecture (PERA) organizes industrial control systems into a five-level hierarchy. Each level separates a different function, from enterprise IT down to the physical process.

1. Level 4-5, Enterprise Network: ERP, email, business logistics. Standard IT infrastructure.
2. Level 3.5, Industrial DMZ: The boundary between IT and OT. Firewalls, proxies, patch servers.
3. Level 3, Site Operations: Plant-wide control, engineering workstations, historians.
4. Level 2, Supervisory Control: SCADA, HMIs, DCS. The systems operators interact with daily.
5. Level 1, Basic Control: PLCs, RTUs, drives. The devices that execute control logic.
6. Level 0, Physical Process: Sensors, actuators, valves. The physical world.

The model assumes that traffic flows vertically between levels, and that each level boundary acts as a security checkpoint. That assumption held when plants were air-gapped and every connection was physical.

It no longer holds.

Where the Model Breaks

The Purdue Model was designed for manufacturing process optimization, not cybersecurity. Three forces have eroded its effectiveness:

Remote access bypasses every layer. Vendor VPNs create persistent tunnels from Level 0 to the enterprise. One compromised credential gives attackers a direct path to safety controllers, skipping Levels 1 through 4 entirely.

Technical detail: A typical vendor VPN terminates at the enterprise firewall (Level 4-5) and tunnels directly to a jump host that can reach PLCs at Level 1. From a network perspective, this collapses the entire Purdue hierarchy into a single hop. The five-level separation exists on the whiteboard but not on the wire.

IIoT sensors skip the hierarchy. Edge gateways transmit telemetry directly to cloud platforms, bypassing every Purdue layer. A temperature sensor at Level 0 sends data to AWS without touching Levels 1, 2, or 3. This creates unmonitored ingress points deep inside OT.

Cloud analytics collapse Levels 3-4. When historians replicate to cloud dashboards, the distinction between site operations (Level 3) and enterprise (Level 4) disappears. A compromised cloud account can reach plant data that was supposed to be isolated behind two layers of firewalls.

The Industrial DMZ Problem

The Purdue Model's answer to IT/OT separation is the Industrial DMZ at Level 3.5. In theory, it acts as a controlled buffer. In practice:

• Single point of failure. One DMZ breach exposes every asset on both sides of the boundary.
• Bottleneck for all traffic. Vendor access, IIoT telemetry, and cloud sync all funnel through the same chokepoint.
• Visibility ends at the boundary. Once past the DMZ, lateral movement inside OT goes undetected. The DMZ logs show "connection allowed" but cannot see what happens next.

Compliance Gaps

Modern compliance frameworks expect controls that the Purdue Model was never designed to provide:

• NIST 800-171 requires continuous monitoring and audit logging of access to controlled information. The Purdue Model has no built-in logging at the level boundary.
• CMMC Level 2 mandates least-privilege access control per system, not per network layer. Purdue's coarse segmentation groups dozens of assets into the same trust zone.
• NIS2 requires incident detection and reporting timelines that assume visibility into lateral movement. A flat OT network behind a DMZ provides none.

Alternatives to the Purdue Model

Zero Trust Architecture

Zero Trust replaces the "trust but verify" model with "never trust, always verify." Every connection, whether from inside or outside the network, is authenticated and authorized before access is granted.

Applied to OT, this means:

• Microsegmentation: Each asset or small group of assets gets its own security boundary. Compromising one PLC does not grant access to the adjacent HMI.
• Continuous verification: Device identity, user identity, and session context are checked on every connection, not just at the perimeter.
• Least privilege: An operator who needs to read a PLC register does not get write access to the entire OT subnet.

Technical detail: In a zero trust OT architecture, segmentation happens at Layer 3 (IP routing) rather than Layer 2 (VLANs). Each micro-segment gets its own subnet with explicit routing rules. Traffic between segments passes through a policy enforcement point that inspects source, destination, protocol, and identity before forwarding. This eliminates the broadcast domain problem that flat OT networks suffer from.

Software-Defined Networking (SDN)

SDN decouples the control plane from the data plane, making network behavior programmable rather than static.

• Dynamic path control: Network routes adjust in real-time based on policy, load, or threat state. A detected anomaly can trigger automatic isolation of the affected segment.
• Centralized visibility: A single control plane sees all traffic flows across IT and OT, making it possible to detect lateral movement that the Purdue Model's per-layer approach misses.
• Policy as code: Segmentation rules are defined centrally and pushed to all enforcement points, reducing the configuration drift that plagues manually managed firewall rules.

Trout Approach: Micro-DMZs Instead of a Shared Boundary

The Purdue Model concentrates all IT/OT security at a single shared DMZ. The Trout Access Gate takes the opposite approach: replace the shared DMZ with per-asset boundaries.

How it works. Each OT asset (or small group of related assets) gets its own Micro-DMZ. The Access Gate acts as a dedicated proxy in front of each asset, authenticating, inspecting, and logging every connection at the asset level rather than at the plant boundary.

This changes the security model fundamentally:

• No lateral movement. Compromising one device gives zero access to any other. There is no shared trust zone to move through.
• Identity at the asset level. Every session is tied to a user identity, a device identity, a protocol, and a timestamp. Vendor access is scoped to specific assets with time limits.
• Incremental rollout. You do not need to redesign the entire network. Start with the most critical assets, wrap each one in a Micro-DMZ, and expand over time.
• No network redesign. The Access Gate overlays on your existing infrastructure. Keep your current VLANs, IP addresses, and routing. No re-cabling, no downtime.

Technical detail: The Access Gate sits inline as a Layer 3 proxy between zones. It intercepts connection requests, authenticates the source (user + device), checks the request against a per-asset policy, and either forwards or blocks. Because it operates at Layer 3, it works with any OT protocol (Modbus, OPC-UA, EtherNet/IP, PROFINET) and does not require agents on the endpoints. A 20-year-old PLC gets the same per-asset boundary as a modern engineering workstation.

Compliance alignment:

• CMMC: Per-asset access control maps directly to AC (Access Control) and AU (Audit) practices. Each Micro-DMZ generates its own audit trail.
• NIS2: Asset-level session logging provides the incident detection and reporting evidence that NIS2 requires.
• NIST 800-171: Continuous monitoring happens at each boundary, not just at the plant perimeter.

Converged IT/OT Architectures

These architectures accept that IT and OT will share infrastructure and focus on maintaining security boundaries within a converged network.

• Unified policy enforcement: The same security rules apply to IT and OT traffic, adapted for protocol and latency requirements. No more separate firewall rulesets that fall out of sync.
• Shared identity infrastructure: IT authentication systems (Active Directory, SAML providers) extend to OT access control, giving operators a single credential rather than separate IT and OT passwords.
• Cross-domain visibility: A single monitoring platform sees both IT and OT traffic, enabling correlation that catches attacks spanning both domains.

Practical Steps for Transition

Moving away from the Purdue Model does not require a forklift replacement of your network. Here is a phased approach:

Step 1: Map Your Actual Traffic

Before changing anything, understand what your network actually looks like. The Purdue diagram on the wall rarely matches reality. Map every connection: VPN tunnels, IIoT gateways, cloud replication, vendor access paths. Identify where traffic bypasses the intended hierarchy.

Step 2: Identify Critical Assets

Not every device needs the same level of protection. Prioritize assets where a compromise has safety, production, or compliance consequences. Safety controllers, SCADA servers, and historians with CUI are typical starting points.

Step 3: Deploy Per-Asset Segmentation

Wrap critical assets in their own security boundaries. This can be micro-DMZs (Trout Access Gate), firewall rules per subnet, or a combination. Start with the highest-risk assets and expand.

Step 4: Enforce Identity-Based Access

Replace shared VPN tunnels with identity-aware access. Every session should be tied to a specific user, scoped to a specific asset, and limited in time. This eliminates the "one VPN key opens everything" problem.

Step 5: Establish Continuous Monitoring

Deploy logging at each segmentation boundary, not just at the plant perimeter. Baseline normal traffic patterns and alert on deviations. This is where the Purdue Model's per-layer approach fails: you need visibility inside OT, not just at the edge.

Conclusion

The Purdue Model served manufacturing well for decades. It was built for a world where plants were air-gapped, connections were physical, and the biggest risk was a misconfigured PLC. That world no longer exists.

Remote access, IIoT, and cloud analytics have bypassed every layer of the hierarchy. The Industrial DMZ concentrates risk at a single chokepoint instead of distributing defense across the network.

The path forward is per-asset security boundaries: zero trust enforcement at the device level, identity-aware access, and visibility into lateral movement. Whether through Micro-DMZs, SDN, or converged architectures, the principle is the same. Stop trusting the network layer. Verify every connection.