How does Level 3.5 DMZ work?

How Level 3.5 DMZ Changes the Purdue Model Boundary

Level 3.5 is not a separate control system layer so much as a deliberately placed buffer between plant operations and enterprise IT. It exists to keep business services from talking straight into control environments, which is why it is usually built around tightly scoped interfaces, jump paths, historians, patch staging, remote access brokers, and other controlled services rather than open network transit.

The practical effect is a change in trust boundaries. Instead of treating IT and OT as directly connected peers, the DMZ forces traffic to pass through a smaller, inspectable zone where protocols, destinations, and data flows can be constrained. In a well-run design, that reduces the blast radius of compromise and makes it harder for enterprise-side issues to cascade into operational systems.

A useful way to think about it is that Level 3.5 supports controlled exchange, not convenience. It is meant to broker specific business needs, such as reporting, file transfer, patch distribution, and remote administration, while keeping those services from becoming a general-purpose bridge into plant networks. The OT Security Guide covers the Purdue Model, industrial DMZ design, segmentation, and the protocol and conduit patterns that make that boundary work in practice.

What Actually Sits in the DMZ and Why That Matters

Level 3.5 typically hosts systems that need to touch both sides of the boundary, but should not belong fully to either side. Common examples include data historians with replication controls, secure file-transfer services, update repositories, remote access gateways, bastion hosts, reporting relays, and protocol-aware proxies. Their job is to mediate, normalize, or restrict communication rather than expose plant assets directly.

This matters because the DMZ is only effective if it contains services that are deliberately hardened and narrowly permitted. If the zone becomes a dumping ground for shared services, ad hoc admin tools, or uncontrolled integrations, it stops being a buffer and starts becoming a high-value compromise point. The design assumption is that a compromise in enterprise IT should not automatically translate into direct control of OT assets.

Traffic inspection is central here. The DMZ is where teams often validate payloads, constrain source and destination pairs, enforce authentication, and apply protocol filtering before anything reaches the operational side. That is why this zone is often paired with industrial firewalls, unidirectional gateways where appropriate, and explicit allowlists instead of broad routing rules.

Why Level 3.5 Exists in Real Operations, Not Just Diagrams

In live environments, the Level 3.5 DMZ solves a set of very practical problems. Operations still need business reporting, engineering support, vendor access, patching, backups, and data exchange, but those needs should not force a flat trust model. The DMZ gives security teams a place to stage and inspect that exchange without putting enterprise users, enterprise devices, and control assets on the same trust plane.

The most important operational benefit is containment. If a corporate endpoint, identity, or application is compromised, the attacker should encounter a narrower set of services in the DMZ rather than a direct route to controllers, HMIs, or engineering workstations. The opposite direction matters too: if an OT asset is affected, the DMZ helps prevent easy lateral movement back into enterprise systems.

Used well, the zone also improves change control. New integrations, new ports, and new data feeds can be approved against a smaller boundary rather than negotiated across the whole plant network. That makes it easier to review dependencies, log access, and separate duties between business IT, OT operations, and security monitoring.

Risk and Threat Considerations

The main risk is false confidence. A DMZ does not create security by itself, it only reduces trust if the services inside it are tightly controlled, monitored, and kept minimal. If the zone is overstuffed with exposed services, weak admin paths, or poorly governed remote access, it becomes a high-value pivot point instead of a barrier.

Failure mechanism: An attacker who compromises an enterprise host, vendor path, or DMZ service can use the zone as a staging area for credential theft, protocol abuse, or lateral movement toward plant systems. Weak segmentation, shared credentials, or permissive firewall rules turn the buffer into a bridge.

Impact: The result can be broader than information loss. In an OT environment, the downstream effect may include unauthorized access to operational data, disruption of control communications, unsafe command paths, or delayed detection of an intrusion that has already moved closer to the process layer.

Practitioner Guidance

What to verify: Confirm that every service in Level 3.5 has a named purpose, a bounded trust relationship, and an explicit owner. If a system exists only because it is “between” IT and OT, treat it as a design smell until its data flows, authentication method, and allowed destinations are documented.

Decision rule: If a connection can be removed and the business process still functions, remove or narrow it; if it cannot, constrain it to the smallest possible protocol, source, destination, and time window. The DMZ should mediate necessary exchange, not host general connectivity.

What good looks like: OT and enterprise networks never talk directly except through approved brokered services, remote access is controlled through a single hardened path, and logs from the DMZ are used to prove which data crossed the boundary and when.

Practitioner takeaway: Level 3.5 works best when it is treated as a policy enforcement zone, not a convenience subnet, because the security value comes from shrinking and observing trust, not from the label on the diagram.

Related resources from NHI Mgmt Group

• What breaks when CMMC Level 2 certification is not in place for DoD work?
• How should teams use agentic AI for low-level engineering work?
• How should security teams apply browser-level controls to reduce risk in cloud and hybrid work environments?
• What do security teams get wrong about preparing entry level staff for IAM and AI security work?