Level 3.5 DMZ is the industrial demilitarised zone between plant operations systems and enterprise networks. It is a controlled buffer for data exchange, remote access and patch flows, so defenders use it to reduce direct trust between IT and OT and to limit lateral movement if either side is compromised.
What a Level 3.5 DMZ does in industrial networks
A Level 3.5 DMZ is the controlled buffer between plant operations and enterprise IT, designed to let necessary traffic cross boundaries without creating a direct trust relationship. It is typically where organisations place inspection points, jump access, patch staging, historians, and tightly governed data transfer services.
Its value is architectural, not merely physical. By separating operational technology from business networks, it helps preserve availability and safety if enterprise systems are compromised, while also limiting the blast radius if an OT-adjacent system is attacked.
How the Level 3.5 DMZ fits the Purdue model
The term comes from industrial network zoning and is closely associated with the Purdue model, where Layer 3 contains site operations and Layer 4 contains enterprise functions. The Level 3.5 DMZ sits between them as a brokered zone for controlled exchanges, often with firewalls, protocol gateways, or other inspection controls enforcing what is allowed in each direction.
This buffer is especially important in mixed IT and OT environments because the two sides usually have different uptime requirements, patch cadences, and acceptable control patterns. The DMZ lets defenders reduce direct routing and direct management access across that boundary, which is why it is often treated as a core segmentation layer in OT security guidance.
Common traffic and trust patterns
In practice, the DMZ is where organisations centralise flows that would otherwise create unnecessary cross-domain exposure. Typical examples include historian replication, remote vendor access through controlled entry points, patch and update staging, file transfer services, and one-way or highly filtered data movement from plant systems to business systems.
The security goal is to make each service explicit and reviewable. Instead of allowing broad reachability from enterprise networks into control environments, the DMZ forces traffic to pass through choke points where access, protocol behaviour, and session handling can be constrained and monitored.
That design also helps support zero trust-style boundary reduction, because the buffer zone breaks the assumption that systems on either side should implicitly trust one another. NIST SP 800-207 Zero Trust Architecture is useful here as a conceptual reference for how segmentation and least privilege should shape trust decisions across the boundary.
Why this boundary matters operationally
A Level 3.5 DMZ is not a convenience layer, it is part of the resilience design for industrial environments. If enterprise IT is breached, the DMZ helps prevent immediate pivoting into plant operations; if an OT-hosted system is compromised, it limits direct access back into business services and can reduce the chance of lateral movement across the environment.
The same logic applies to patching and remote administration. When those functions are forced through a controlled zone, defenders can inspect, log, and stage activity rather than exposing control assets directly to broad enterprise reachability. That makes the DMZ one of the main places where architecture and monitoring reinforce each other, rather than being separate tasks.
Risk and Threat Considerations
Level 3.5 DMZs fail when they become too permissive, poorly monitored, or functionally overloaded. If remote access, file exchange, and management traffic are all collapsed into a weakly governed buffer, attackers can use that shared trust boundary to bridge IT and OT, stage payloads, or pivot laterally after an initial compromise.
Failure mechanism: A misconfigured or overtrusted DMZ can expose protocols, credentials, jump paths, or shared services that let an attacker move from enterprise systems into plant-facing assets, or from a compromised OT-adjacent host back toward business systems.
Impact: The result can be loss of segmentation, broader lateral movement, disrupted operations, and a much larger incident blast radius than the organisation expected from a “buffer” zone.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, NIST CSF 2.0, CIS Controls v8 and NIST Zero Trust (SP 800-207) set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Level 3.5 DMZs implement controlled boundary protection between IT and OT zones |
| Recommendation — Enforce boundary controls to restrict and inspect traffic crossing the OT and enterprise divide. | ||
| NIST CSF 2.0 | PR.PS-01 — Configuration Management | DMZ effectiveness depends on securely configured segmentation, firewalls, and broker services |
| Recommendation — Harden and maintain DMZ configurations so only approved services and routes remain exposed. | ||
| CIS Controls v8 | CIS-12 — Network Infrastructure Management | Industrial DMZs are network segmentation and management controls that reduce lateral movement |
| Recommendation — Segment the OT boundary and monitor network infrastructure changes that weaken the DMZ. | ||
| ISO/IEC 27001:2022 | A.8.20 — Network security | The term is about securing network boundaries and traffic between business and plant zones |
| Recommendation — Apply network security controls to govern, filter, and monitor all cross-zone communications. | ||
| NIST Zero Trust (SP 800-207) | 5.1 — Zero Trust Architecture logical components | A Level 3.5 DMZ is an architectural trust-reduction pattern aligned to zero trust principles |
| Recommendation — Use zero-trust principles to eliminate implicit trust across the IT/OT boundary. | ||
Practitioner Guidance
Why practitioners should care: Treat the Level 3.5 DMZ as a governed security boundary, not a convenience network. Its controls should be justified by the exact traffic and trust relationships they support, especially for remote access, patch distribution, and plant-to-enterprise data flows.
What to watch for: Review the DMZ whenever services begin to accumulate “temporary” exceptions, direct admin access, or bidirectional shortcuts. Those are the conditions that usually turn a buffer into a bypass.
Practitioner takeaway: The most effective DMZs are narrow, explicit, and monitored, because their job is to mediate trust, not merely to separate subnets.
Related resources from NHI Mgmt Group
- When does AI agent access become a board-level security concern?
- What is the difference between network trust and request-level identity trust?
- What is the difference between scope-based authorization and object-level authorization in MCP?
- What is the difference between tool-level access and data-level access for AI agents?