The Level 3.5 DMZ matters because it is the buffer between enterprise IT and operational technology, reducing direct exposure of control systems. Security teams should enforce one-way or tightly brokered traffic, inspect transfers, harden jump hosts and historians, and log all cross-zone activity. Weakness here often becomes the path into the plant network.
Why the Level 3.5 DMZ is the control point that changes the security posture
The Level 3.5 DMZ matters because it is the control point where enterprise IT traffic is separated from operational technology. That boundary lets security teams prevent routine corporate connectivity from becoming direct plant access, and it creates a place to enforce brokered exchanges, content inspection, and strict logging before anything reaches control assets.
In practice, the DMZ is where security intent becomes enforceable architecture. If the zone is treated as a passive subnet instead of an active buffer, the purdue model collapses into a flatter trust structure and the plant inherits the exposure of the enterprise side.
When the DMZ is properly designed, it also becomes the place to contain services that need to bridge both environments, such as historians, jump hosts, update relays, and file transfer gateways. Those services are useful only if they are hardened, narrowly scoped, and monitored as high-value assets.
What security teams should enforce across the boundary
The most important design choice is whether traffic crosses the boundary in a one-way, tightly brokered, or directly bidirectional pattern. The safer the environment, the more the DMZ should minimize trust, validate transfers, and avoid letting enterprise systems initiate unrestricted paths into controllers, engineering workstations, or other sensitive OT assets.
Security teams should also treat the DMZ as a policy enforcement zone, not just a routing segment. That means inspecting files and sessions, limiting protocols to what the process truly needs, and hardening any jump host or historian that sits in the middle so it cannot become a shared pivot point.
Operationally, the zone is only as strong as its exceptions. Temporary remote access, vendor connections, misconfigured firewall rules, and convenience paths through the DMZ often become the long-lived routes attackers use when they first reach the plant network.
Why weak segmentation becomes an attack path
A poorly controlled Level 3.5 DMZ creates a predictable compromise path: an attacker lands in enterprise IT, reaches the bridge layer, and then uses that trusted intermediary to move toward OT. Once that happens, the boundary no longer separates business risk from process risk, it merely delays the transition.
Attackers favor this zone because it often contains the exact services that must talk to both sides, which makes it a concentration point for credentials, remote sessions, file movement, and operational telemetry. The same convenience that helps operations can also help lateral movement if trust is not tightly constrained.
Logging and monitoring matter here because the DMZ is one of the few places where cross-zone behavior can be seen in context. Without strong records, teams may know that traffic crossed the boundary, but not whether it was expected, modified in transit, or used as a foothold for further movement.
Risk and Threat Considerations
The main risk is boundary failure: once the DMZ becomes permissive, it can turn a segmented architecture into a shared trust plane. That increases exposure for control systems, remote access services, and supervisory assets that were supposed to be insulated from enterprise compromise.
Failure mechanism: Weak rules, over-trusted jump hosts, unrestricted file exchange, or poorly monitored historian traffic give an attacker a practical bridge from IT into OT, often without needing to touch a controller directly.
Impact: The result can be unauthorized visibility, disruption, unsafe command reach, or a broader plant compromise that is harder to contain because the boundary component itself has become part of the attack path.
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 Zero Trust (SP 800-207) and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SC-7 — Boundary Protection | Level 3.5 DMZ is a boundary control between enterprise and OT networks. |
| AU-2 — Event Logging | Cross-zone activity in a DMZ needs auditable records for investigation and monitoring. | |
| AC-4 — Information Flow Enforcement | The DMZ exists to control how data and commands move between trust zones. | |
| Recommendation — Enforce boundary protections to broker and limit traffic crossing into OT. Log boundary events so OT-to-IT crossings are traceable and reviewable. Apply flow controls to restrict what may traverse the DMZ. | ||
| NIST Zero Trust (SP 800-207) | SP 800-207 — Zero Trust Architecture | The DMZ pattern aligns with minimizing implicit trust across zones. |
| Recommendation — Use Zero Trust principles to broker and verify every cross-zone exchange. | ||
| CIS Controls v8 | CIS-13 — Network Monitoring and Defense | Monitoring boundary crossings is central to detecting abuse of the DMZ. |
| Recommendation — Monitor DMZ traffic and alert on unexpected cross-zone behavior. | ||
Practitioner Guidance
What to verify: Confirm that every cross-zone flow has an owner, a business purpose, and a defined allow rule. If you cannot explain why the flow must exist, it should not cross the DMZ.
What good looks like: The DMZ contains only the minimum bridging services, each one is hardened and separately logged, and no direct enterprise path reaches OT without inspection or brokering. For a useful reference architecture, OT Security Guide covers the Purdue model, industrial DMZ design, and segmentation patterns.
What to measure: Track the number of approved cross-zone services, the volume of exception-based access, and the age of any remote access or transfer rule that bypasses the normal control path.
Practitioner takeaway: Treat Level 3.5 as a security choke point, not a convenience zone, because the quality of that boundary usually determines whether an OT incident stays contained or reaches the plant.