Level 3.5 DMZ

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.

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?