Industrial DMZ Design: Building the OT/IT Buffer Zone at Level 3.5

01Key takeaways

1. 01

   An industrial DMZ is a buffer network at Purdue Level 3.5 that brokers data between IT and OT so neither side connects directly to the other.

2. 02

   The core design rule is no pass-through: a session terminates inside the DMZ and a new, separately authorized session continues, so there is no straight Level 4 to Level 2 path.

3. 03

   Host the right services in the DMZ: a patch and anti-malware mirror, a historian replica, a remote-access broker, a file-transfer relay, and replicated directory or time services.

4. 04

   IEC 62443 conduits and NIST SP 800-82 both expect this buffer; the DMZ is where many zones-and-conduits decisions become concrete firewall rules and hosts.

5. 05

   For publish-only flows out of OT, such as historian or log export, a one-way path reduces the inbound reachability a dual-firewall DMZ still technically allows.

02What an industrial DMZ is

An industrial DMZ, sometimes written IDMZ or OT DMZ, is a dedicated network segment that separates an enterprise IT network from an operational technology network. In the Purdue reference model it sits at Level 3.5, between Level 3 (site operations, including historians and engineering systems) and Level 4 and 5 (business and enterprise systems). It is the only place where IT and OT are allowed to exchange data.

The defining property is not the firewall count or the VLAN scheme. It is the rule that no device in OT talks directly to a device in IT, and the reverse is also true. Every cross-boundary flow lands on a host inside the DMZ first. That host re-originates the traffic. The result is two short, controlled conversations instead of one long, end-to-end one.

Short version: an industrial DMZ is a buffer zone where IT and OT meet through brokers and replicated copies, never through a direct connection between the two networks.

03Why the buffer zone matters

Operational networks were built for reliability and long life, not for adversaries. Many run legacy protocols with no authentication, devices that cannot be patched on a normal cycle, and equipment that stays in service for fifteen years or more. The cheapest way to protect them is to make sure attacks cannot reach them in the first place.

Real intrusions reflect this. MITRE ATT&CK for ICS catalogues techniques such as exploitation of remote services and lateral movement through engineering workstations and remote-access tooling. These techniques depend on a usable network path from the compromised foothold to the control system. An industrial DMZ exists to break that path. If a corporate machine is compromised, the attacker reaches the DMZ boundary and finds a broker, not a plant.

This is also where the model becomes concrete. Articles on the Purdue model and on IEC 62443 zones and conduits explain why the boundary should exist. This article covers how to build the boundary so that the explanation survives contact with a real firewall rule set and a real change request.

04The reference architecture: dual firewalls and broker hosts

The common reference design uses a dual-firewall DMZ: one firewall faces IT, one faces OT, and the DMZ sits between them. Two firewalls from different vendors reduce the chance that a single bug or misconfiguration opens both boundaries at once. A single firewall with three or more interfaces is a lower-cost variant, but it concentrates the entire boundary in one device and one rule base.

Inside the DMZ live broker and replica hosts. A broker terminates a connection from one side and starts a fresh one to the other, applying its own authentication and inspection. A replica holds a copy of data that one side reads instead of reaching across the boundary. Neither pattern allows a packet from Level 4 to land on a Level 2 device. The cardinal rule, repeated in CISA and ISA guidance, is that no protocol traverses the DMZ untouched.

IT-facing firewall

Restricts which enterprise hosts and services may reach DMZ brokers and replicas, and blocks everything else inbound to the DMZ.

OT-facing firewall

Restricts which DMZ hosts may reach which OT zones and services, and denies any flow that would let IT traffic reach OT directly.

Broker host

Terminates a session and re-originates it, so the end-to-end path is split into two separately authorized hops.

Replica host

Holds a copy of OT data, such as historian records, that IT reads without ever connecting into the OT zone.

05Which services belong in the DMZ

A DMZ is only useful if it hosts the services that would otherwise tempt someone to open a direct IT-to-OT rule. Identify every cross-boundary need first, then place a broker or replica for each one inside the buffer zone.

• Patch and anti-malware staging: an internal mirror that pulls updates from IT, which OT systems then read from the DMZ, so OT never reaches the internet or the enterprise update server directly.
• Historian replica: a copy of plant historian data placed in the DMZ for reporting and analytics, so business users query the replica and never the primary historian in OT.
• Remote-access broker: a hardened jump host or gateway where vendor and engineer sessions terminate, are authenticated and recorded, before a separate session continues into OT.
• File-transfer relay: a staging server for moving engineering files, configurations and reports, replacing direct shares between the two networks.
• Replicated directory and time: a read-only domain controller and an NTP source so OT authentication and clocks do not depend on a live link into the enterprise domain.
• Reverse proxy or web relay: for any HMI or dashboard that must be viewed from IT, presented through a proxy in the DMZ rather than by exposing the OT host.

Keep the DMZ minimal. Every host added is another asset to patch, monitor and harden. If a service does not need to bridge IT and OT, it does not belong in the buffer zone.

06Practical design rules for the build

The architecture diagram is easy. The discipline is hard. These rules are what keep an industrial DMZ from quietly decaying into a flat segment with a firewall in front of it.

• No pass-through: never write a rule that lets an IT subnet reach an OT subnet, even via the DMZ. Traffic must terminate on a DMZ host and be re-originated.
• No dual-homed hosts: a DMZ server must not have one interface in IT and another in OT. A single network interface that bridges both boundaries defeats the entire design.
• Deny by default in both directions, with each allowed flow documented down to source, destination, port and business reason.
• Initiate outward where possible: prefer flows that OT or the DMZ initiates outbound, rather than IT initiating sessions inbound toward OT.
• Separate the management plane: administer DMZ hosts and firewalls through a dedicated, isolated path so management never becomes a hidden back channel across the boundary.
• Treat the DMZ as untrusted by both sides: OT does not trust the DMZ, and IT does not trust the DMZ, so a compromised broker still cannot reach into OT freely.

If you can draw a single TCP session that begins on a Level 4 host and ends on a Level 2 device, the DMZ has failed, no matter how many firewalls it contains.

07How the DMZ maps to standards and compliance

An industrial DMZ is not an optional refinement; major OT security frameworks assume it. NIST SP 800-82 Rev. 3 describes network segmentation and a DMZ between corporate and control networks as a core architectural control. ISA/IEC 62443 expresses the same idea as zones and conduits: the DMZ is a set of zones, and every allowed flow is a defined, monitored conduit.

The mapping is useful because it turns abstract requirements into concrete artifacts. A 62443-3-3 system requirement for zone boundary protection becomes a firewall rule and a broker host. A risk assessment that assigns a security level to an OT zone becomes the strictness of the conduit rules at the DMZ edge. Auditors and regulators, including those applying the EU NIS2 Directive and sector rules, increasingly expect this documentation to exist and to match the live configuration.

NIST SP 800-82 Rev. 3

Recommends a DMZ between enterprise and control networks and network segmentation to limit reachability into OT.

ISA/IEC 62443 zones and conduits

Models the DMZ as zones joined by defined conduits, each conduit carrying only the flows its risk level permits.

CISA defense-in-depth guidance

Treats the DMZ as one layer among many, paired with monitoring, hardening and least-privilege access.

08Common pitfalls that hollow out the DMZ

Most failed industrial DMZs were built correctly and then eroded. The architecture stays on the diagram while the rule base drifts. These are the patterns to watch for and audit against.

• Rule creep: a series of temporary any-to-any or broad exceptions that gradually turn the buffer zone into a transit path.
• Pass-through rules disguised as DMZ flows: a rule that technically references a DMZ subnet but really allows IT to reach OT addresses.
• Dual-homed or bridging hosts added for convenience, such as a backup server or a vendor laptop with interfaces in two zones.
• A management or monitoring tool reaching from IT straight into OT, reintroducing the very path the DMZ removed.
• Unpatched, unmonitored DMZ hosts that become the attacker's staging ground because the buffer zone was treated as low risk.
• Trusting the DMZ as if it were OT, so a single compromised broker grants broad downstream access.

The defense is periodic verification, not a one-time design review. Re-derive the allowed flows from the firewall configuration and confirm that none of them describe a direct IT-to-OT conversation.

09Where one-way transfer fits in the buffer zone

A dual-firewall DMZ reduces reachability, but it does not remove it. Each allowed flow is still a path that policy, a credential, or a compromise could turn bidirectional. For the flows that only ever need to go one way, the buffer zone can be strengthened by removing the return path entirely rather than filtering it.

Publish-only conduits are the natural candidates. Historian export to the DMZ replica, log and event forwarding to a SOC, and backup replication outward all share one property: OT publishes, IT consumes, and OT should never receive a session back. Placing a one-way transfer path on these conduits means the inbound route does not exist to be misused, which is a stronger guarantee than a firewall rule that merely promises not to allow it.

Use brokers for conduits that need a conversation, and one-way transfer for conduits that only need publication. The DMZ is where you decide, flow by flow, which is which.

10Validation and a build roadmap

Build the DMZ as a sequence, not a single cutover. Start by inventorying every existing IT-to-OT flow, because you cannot replace paths you have not found. Then place brokers and replicas for each legitimate need, migrate flows onto them, and only then remove the old direct rules.

• Inventory and document every current cross-boundary flow, including the undocumented ones found by inspecting traffic.
• Stand up the DMZ segment, both firewalls, and a deny-by-default baseline before adding any host.
• Deploy brokers and replicas one service at a time, validating each in a maintenance window.
• Migrate each flow to its broker or replica, then remove the corresponding direct rule.
• Verify no direct path remains by tracing flows from the firewall configuration, not from the diagram.
• Add continuous monitoring of DMZ hosts and boundary traffic, and schedule recurring rule-base reviews.

Plan for the long term too. As OT data demand grows, resist the urge to add direct rules under deadline pressure. Add a broker or a replica instead. The discipline of routing every new requirement through the buffer zone is what keeps the DMZ meaningful five years after it was built.

11Closing thought

An industrial DMZ works because it changes a question from "which traffic do we allow between IT and OT?" to "how does IT get the data it needs without ever touching OT?" The first question invites exceptions. The second forces brokers, replicas and one-way paths, none of which leave a straight line into the plant.

Build it flow by flow, host by host, and verify it from the configuration rather than the diagram. The reward is concrete: when a corporate machine is compromised, the attacker reaches a buffer zone and stops, because the path they were counting on was never there.

FAQFrequently asked questions

SRCSources of record