Beyond Purdue. Micro-DMZs for Modern OT.
The Purdue Model defined OT security for decades. But remote access, IIoT, and cloud analytics have eroded every layer. It's time for a new boundary — one per asset.
The Purdue Model Is Showing Its Age
Designed for air-gapped plants with static topologies, the five-level Purdue hierarchy assumed that physical separation equals security. That assumption no longer holds.
Why the Purdue Model and Its DMZ No Longer Hold.
Three forces erode the hierarchy while the Industrial DMZ concentrates risk instead of distributing defense.
Single Point of Failure
A single DMZ breach exposes every asset on both sides of the boundary. Adding new connections requires firewall rule changes that lag weeks behind operations.
Everything Funnels Through One Bottleneck
Vendor access, IIoT telemetry, and cloud sync all share the same DMZ chokepoint. One overloaded boundary trying to broker all IT/OT traffic.
Visibility Ends at the DMZ
Lateral movement inside OT goes completely undetected. Once past the DMZ, attackers move freely across flat plant networks.
Micro-DMZs. One Per Asset.
Replace the Shared DMZ with Per-Asset Boundaries.
Instead of one shared DMZ for the entire plant, wrap every OT asset in its own boundary. Each Micro-DMZ acts as a dedicated proxy — authenticating, inspecting, and logging every connection at the asset level.
Five Reasons to Move Beyond Purdue.
Zero Lateral Movement
- Compromising one device gives zero access to any other
- No flat network, no shared trust zone
- Every connection scoped to a single asset boundary
- Breach containment is automatic and immediate
- Compromising one device gives zero access to any other
- No flat network, no shared trust zone
- Every connection scoped to a single asset boundary
- Breach containment is automatic and immediate
Zero Lateral Movement
Download the Full Whitepaper.
Get the complete analysis: why the Purdue Model breaks, how Industrial DMZs fail to scale, and the technical architecture behind Micro-DMZs.
What You'll Learn
Why the five-level Purdue hierarchy fails against modern threats. How remote access, IIoT, and cloud analytics erode every security boundary.
The Micro-DMZ Architecture
Technical deep-dive into asset-level proxy boundaries. How to deploy Micro-DMZs incrementally without network redesign.
Common Questions About Micro-DMZs.
boundary per asset. Micro-DMZs replace the shared Industrial DMZ with dedicated, identity-aware proxies at every OT endpoint.
No. The Purdue Model remains a useful reference architecture for understanding OT network layers. Micro-DMZs evolve its security intent — isolation and controlled access — by enforcing boundaries at the asset level instead of relying on a single shared DMZ at Level 3.5.
Micro-segmentation typically means adding VLANs or firewall rules to limit lateral movement within a flat network. Micro-DMZs go further: each asset gets a dedicated proxy that authenticates, inspects, and logs every connection. It's not just network isolation — it's identity-aware, protocol-aware access control per device.
Yes. Micro-DMZs deploy inline as network proxies — no agents, no software changes on endpoints. Legacy PLCs, HMIs, and SCADA systems that can't run modern security software are protected without modification.
Each vendor session is authenticated and scoped to a specific asset. No shared VPN tunnel, no broad network access. The vendor connects through the asset's Micro-DMZ proxy, which enforces time-limited, audited, protocol-level access — then closes the session automatically.
IIoT devices connect through their own Micro-DMZ proxy, which controls and inspects outbound telemetry. Cloud connectivity is allowed per policy — specific endpoints, specific protocols, specific schedules — without exposing the broader OT network to internet-facing attack surfaces.
