The OT DMZ is the most important network zone in an industrial security architecture and the one most commonly designed by people who have never operated a control system. The results are predictable.
The zone that matters most and fails most often
In enterprise IT security, the DMZ is a mature and well-understood construct. You put your public-facing web servers in it, you firewall both sides, and you accept that it is a contested zone, one that adversaries will reach but that contains them before they reach your internal network. The concept is sound, the tooling is mature, and the failure modes are well-documented enough that a competent network security engineer can avoid most of them.
In industrial network security, the DMZ occupies a fundamentally different role, faces fundamentally different constraints, and fails in ways that enterprise DMZ experience does not prepare you for. The OT DMZ is not a zone where you accept adversary presence. It is a zone that must mediate every data exchange between two environments, IT and OT, that have incompatible security models, incompatible availability requirements, and incompatible change management processes, while satisfying the operational needs of both. It must be transparent enough that engineers and operations staff can work productively across the boundary, and opaque enough that a full compromise of the IT environment cannot translate into access to the operational control systems.
That combination of requirements is genuinely difficult to satisfy. The OT DMZs I encounter in practice frequently satisfy neither: they are either so restrictive that operations teams route around them, creating shadow connectivity that bypasses the controls entirely, or so permissive that they provide only a nominal boundary between IT and OT, offering comfort rather than protection.
This post is about the design patterns that produce OT DMZs that actually work, that are operationally sustainable, architecturally sound, and defensible against the adversary techniques that are documented in the MITRE ATT&CK for ICS matrix. The design is more specific and more opinionated than much of what is written about OT DMZs, because the generic guidance, “implement a DMZ between IT and OT”, is not sufficient to produce a functional architecture. The details matter enormously.
Part 1: What the OT DMZ must accomplish: and what it must not become
Before designing the OT DMZ, it is necessary to be explicit about its purpose and its limits. Both are commonly misunderstood.
What the OT DMZ must accomplish:
The OT DMZ must mediate all data exchange between the IT environment and the OT supervisory environment. No direct routed path should exist between the IT network and the OT Level 2 network. Every data flow that crosses the IT/OT boundary must transit the DMZ, where it can be inspected, logged, and controlled. The DMZ is the chokepoint through which all boundary-crossing traffic flows, which means it must be designed to handle the full range of legitimate boundary-crossing use cases, not just the ones that were anticipated at design time.
The OT DMZ must host the systems that broker data across the boundary: historian replication servers, remote access jump hosts, patch management infrastructure, protocol translation services, time synchronisation infrastructure, and any other service that must interact with both IT and OT environments. By hosting these services in the DMZ rather than in either the IT or OT network, you ensure that their compromise does not immediately provide access to the more protected environment they face.
The OT DMZ must provide visibility into boundary-crossing traffic: logging sufficient to reconstruct what data crossed the boundary, in which direction, when, and from which systems. This logging is both an operational requirement, you need to be able to audit what your vendors accessed during a support session, and a security requirement, you need to be able to identify anomalous boundary-crossing behaviour in the event of an incident.
What the OT DMZ must not become:
The OT DMZ must not become a transit zone for general IT traffic. It is not a network through which corporate users access business applications, through which cloud workloads communicate with the internet, or through which any traffic flows that is not specifically related to IT/OT data exchange. Every additional traffic flow through the DMZ expands its attack surface and makes it harder to identify anomalous behaviour against the baseline of expected traffic.
The OT DMZ must not become a management plane for OT systems. The temptation to centralise OT system management in the DMZ, running patch management servers, antivirus consoles, and monitoring infrastructure that manage Level 2 systems from the DMZ, must be resisted. Management plane access to OT systems is high-privilege access that must be subject to OT-level security controls, not DMZ-level controls. Management traffic from the DMZ to Level 2 is a significant attack path that should be minimised or eliminated.
The OT DMZ must not become a permanent home for systems that were placed there temporarily. The DMZ has a chronic tendency to accumulate systems that were placed there for specific, time-limited purposes and never removed: a jump host provisioned for a vendor maintenance window, a file transfer server set up for a project data exchange, a historian replica created during a migration. Each of these residual systems is an unmanaged attack surface. Decommissioning processes for DMZ systems must be as rigorous as decommissioning processes for OT systems.
Part 2: Physical versus logical separation : a debate worth having
The first design decision in OT DMZ architecture is the most fundamental: should the DMZ be implemented as a physically separate network infrastructure, or as a logically separated segment within shared physical infrastructure using VLANs and routing controls?
This debate recurs in every OT network design project, and the commercial pressure is consistently toward logical separation, it is cheaper, it is faster to deploy, and it is easier to manage with enterprise network tooling. The security case for physical separation is consistently understated by the vendors and integrators who benefit from selling the simpler solution.
The case for physical separation rests on three arguments.
VLAN security depends entirely on the correctness of configuration. A misconfigured trunk port, a VLAN hopping attack exploiting the default VLAN on a trunk, or a firmware vulnerability in a managed switch can all result in traffic crossing VLAN boundaries in ways that the configuration intends to prevent. Physical separation eliminates this class of failure mode entirely. The physical medium through which IT traffic travels is different from the physical medium through which OT traffic travels, and no software configuration error or firmware vulnerability can bridge them.
Shared physical infrastructure is administered by someone. The switches, routers, and other physical infrastructure that implement VLAN-based separation must be administered, firmware updated, configurations changed, faults diagnosed. That administration is typically performed by IT network teams using IT tools and credentials. A compromise of the IT network management plane is therefore also a compromise of the physical infrastructure implementing OT network segmentation. Physical separation means that even if the IT network management plane is fully compromised, the physical infrastructure of the OT network remains under OT administrative control.
The operational lifecycle of OT and IT network equipment is different. IT network equipment turns over on three-to-five-year cycles, driven by enterprise refresh programmes and vendor end-of-support timelines. OT network equipment, particularly in the lower levels of the Purdue hierarchy, may remain in service for much longer. Shared physical infrastructure must satisfy the upgrade and replacement cadence of the enterprise, which may be incompatible with the change management constraints of the OT environment.
The practical counter-argument is cost and operational complexity. Physical separation requires more hardware, more cabling, more operational processes, and more staff time to maintain. In environments where budget is genuinely constrained, logical separation with rigorous VLAN security controls, including regular configuration audits, switch hardening, and access control for network management, is an acceptable second choice. But it is a second choice, not an equivalent one. The risk trade-off must be explicit and documented.
For the OT DMZ specifically, the zone whose entire purpose is to be the controlled boundary between IT and OT, physical separation is the appropriate default for any major energy operator. The DMZ’s value is entirely dependent on the reliability of its boundary properties. Implementing those properties on shared physical infrastructure that is administered through the IT network management plane introduces a dependency that undermines the architecture’s core purpose.
Part 3: Data diodes and unidirectional gateways : when to use them and when not to
The data diode, a hardware device that enforces one-way data flow at the physical layer, is the gold standard for specific IT/OT boundary use cases, and it is both undersold in generic OT security guidance and oversold by vendors as a universal solution. Understanding precisely when a data diode is the right architecture, and when it is not, requires being specific about the data flows you are trying to protect.
The data diode is the right architecture when:
The data flow is genuinely one-directional by operational requirement. Process data flowing from OT historian to IT analytics platform is the canonical example: the analytics platform needs to read process data, but there is no legitimate operational requirement for data to flow from the analytics platform back into the OT historian. A data diode enforces this one-directionality at the hardware layer, not through a firewall rule that can be misconfigured, not through a software policy that can be overridden, but through the physical impossibility of electrical signal propagation in the reverse direction. An adversary who fully compromises the IT analytics platform cannot reach the OT historian through a data diode, because there is no electrical path through which to do so.
The same argument applies to security monitoring data flows: syslog from OT systems flowing to a security SIEM, network tap data flowing to an OT network detection and response platform, alarm and event data flowing to an enterprise operations centre. All of these are one-directional by design, and all of them are appropriate candidates for data diode implementation.
The data diode is not the right architecture when:
Legitimate bidirectional communication is required. Remote access for engineering workstations, patch deployment to Level 2 systems, time synchronisation from enterprise NTP infrastructure, and any other use case that requires traffic to flow from IT to OT cannot be implemented over a data diode. These use cases require a bidirectional conduit, a firewall-mediated path through the DMZ with explicit, minimal, audited firewall rules. The attempt to force bidirectional requirements through a data diode architecture results in operational workarounds that bypass the diode entirely, which is worse than a properly designed bidirectional conduit.
Industrial protocol translation that requires request-response semantics. OPC-DA polling, Modbus read/write transactions, and many other industrial protocol interactions require the IT-side system to send a request and receive a response. A data diode cannot support this interaction model. OPC-UA publish-subscribe, where the OT system pushes data to a subscriber without a request-response cycle, can be implemented over a data diode. The protocol architecture must match the data flow architecture.
Practical implementation considerations:
Commercial data diode products, Waterfall Security Solutions’ Unidirectional Security Gateway, Owl Cyber Defense’s OPDS series, and the Fox DataDiode, all implement the basic one-way hardware enforcement principle, with software components on each side that handle the protocol translation required to make one-way hardware transmission useful for specific application data formats. The software components are the part of the architecture that requires most careful design: they must support the specific protocols and data formats used in the operator’s environment, they must handle protocol translation reliably, and their own security must be maintained with the same rigour as any other OT boundary component.
The operational model for data diode maintenance deserves attention. Data diode hardware is simple and reliable, the physics of one-way optical transmission do not fail in unexpected ways, but the software components require updates, the protocol connectors require configuration changes when the OT environment changes, and the monitoring infrastructure around the diode must be maintained. These operational requirements are frequently underestimated in diode deployment projects and lead to diodes that technically function but whose protocol connectors are misconfigured or out of date.
Part 4: Firewall architecture for the OT DMZ: the rules that matter
For the bidirectional conduit that any real-world OT environment requires, firewall architecture is the primary control mechanism. The firewall rules governing traffic between the OT supervisory zone, the OT DMZ, and the IT network are among the most consequential security configuration decisions in the entire OT architecture. They are also, in most environments I have reviewed, among the worst documented and worst maintained.
The principles that should govern OT DMZ firewall architecture are:
Default deny on all interfaces, with explicit allow rules for each required flow. This is the standard principle for any security-relevant firewall, but it is particularly important in OT contexts where the baseline traffic is highly regular and predictable. A default-deny rule set makes anomalous traffic immediately visible as a policy violation, rather than hiding it within a permissive rule set that allows broad traffic categories.
Rules should be as specific as possible. An allow rule permitting TCP traffic from historian server A on the OT side to historian replication server B on the DMZ side, on port 1433 only, in the outbound direction only, is a materially more secure rule than one permitting TCP traffic from the OT historian VLAN to the DMZ on all database ports. The specificity of rules determines the precision of the boundary: a precisely specified rule set allows only exactly the traffic required for legitimate operation, while a broadly specified rule set allows a much larger volume of traffic that an adversary could exploit.
Rules must have documented owners and business justifications. Every rule in the OT DMZ firewall rule set must have a named owner, the person or team responsible for the application or service that requires the traffic, and a documented business justification. Rules without owners or justifications are candidates for removal. The discipline of maintaining this documentation is operationally burdensome but essential: the alternative is a rule set that grows over time with no mechanism for identifying and removing rules that are no longer required.
Rule sets must be regularly reviewed. Every firewall rule in the OT DMZ should be reviewed at least annually, and any rule that cannot be validated as still required should be removed. This review should be conducted by the security architecture function with input from the operational and engineering teams that own the applications the rules support. Experience suggests that a significant fraction of firewall rules in mature OT environments have no identifiable current owner and no identifiable current purpose, they persist because nobody has had the authority or the motivation to remove them.
Application-layer inspection where supported. Where the firewall platform supports application-layer inspection for industrial protocols, parsing Modbus, DNP3, or OPC-UA traffic to validate that transactions conform to expected patterns, this capability should be enabled. Application-layer inspection that verifies a Modbus transaction is a legitimate read request for a defined register range is a materially stronger control than a rule that permits TCP traffic on port 502 without inspecting the content. Not all industrial protocol firewalls support robust application-layer inspection for all relevant protocols; the selection of firewall platform should account for the specific protocol mix in the operator’s environment.
Part 5: The jump host:architecture and operational model
The remote access jump host in the OT DMZ is the system through which all remote sessions to the OT supervisory zone are mediated. Its architecture and operational model are among the most security-critical design decisions in the entire OT DMZ, because it represents the controlled entry point for all remote access, including vendor access, which is consistently one of the most exploited attack vectors in OT environments.
Jump host placement and connectivity:
The jump host should be placed in the OT DMZ, not in the OT supervisory zone or the IT network. Its inbound connections come from the IT-side remote access gateway, the VPN termination point or the Zero Trust Network Access broker, and its outbound connections go to specific systems in the OT supervisory zone using the specific protocols required for remote management. The jump host has no connectivity to the internet. It has no direct connectivity to the IT network. Its outbound connectivity to the OT supervisory zone is governed by firewall rules that are as specific as operationally possible: specific destination systems, specific ports, specific protocols.
Session recording and audit:
Every session that transits the jump host must be recorded. The recording must capture the full session content, keyboard input, screen output, file transfers, not just connection metadata. Session recordings must be stored in a tamper-evident repository that is accessible to the security operations and audit functions but not modifiable by the session participants or the jump host administrators. This recording capability serves multiple purposes: it is a deterrent to insider misuse, it provides the forensic record required to investigate suspected incidents, and it provides the audit trail required by regulatory frameworks that mandate logging of privileged access to critical systems.
The session recording function must be implemented at the jump host, not at the endpoint. Session recording that depends on endpoint agents or endpoint cooperation can be disabled by a compromised endpoint or a malicious insider with administrative access to the endpoint. Recording at the jump host captures the session stream regardless of endpoint state.
Vendor access management:
Vendor access to the OT environment through the jump host must be managed through a defined process that includes: individual named vendor accounts (never shared service accounts), time-limited access grants that correspond to specific maintenance windows, MFA for all vendor authentication, session recording as standard, and a post-session review process that verifies the vendor’s activities were consistent with the stated purpose of the access.
The access grant process should require a named sponsor within the operator’s organisation, an engineer or manager who can confirm that the vendor access is required and who takes responsibility for the scope of access granted. The sponsor should receive a notification when vendor access is initiated and when it terminates. Post-session reviews should be conducted for any vendor session involving changes to OT systems, not reading data, but making changes, and any session that triggers anomaly alerts from the network monitoring infrastructure.
Jump host hardening:
The jump host is a high-value target: an adversary who compromises it gains mediated access to the OT supervisory zone through the existing legitimate access paths. Its hardening requirements are correspondingly stringent. The jump host operating system should be stripped to the minimum required function, no email clients, no web browsers, no general-purpose productivity software, no development tools. Only the protocols required for remote session brokering should be installed and enabled. The operating system should be patched on an accelerated schedule relative to standard OT change management timescales, the jump host faces the IT network and is therefore exposed to IT-side vulnerabilities. Its patch cycle should reflect that exposure. Administrative access to the jump host itself should be tightly controlled and separately audited.
Part 6: Time synchronisation, DNS, and other infrastructure services: the overlooked attack surface
The OT DMZ architecture must address a set of infrastructure services, time synchronisation, name resolution, software update distribution, that are often treated as implementation details but represent significant attack surface if not designed carefully.
Time synchronisation is critical in OT environments: process historians require accurate timestamps for data correlation, security logs require accurate timestamps for forensic analysis, and some industrial protocols use time synchronisation for sequence-of-events recording and protection relay coordination. The architecture challenge is that enterprise NTP infrastructure sits in the IT network, while OT systems require synchronisation without a direct IT/OT network path.
The appropriate architecture uses a dedicated NTP server in the OT DMZ that synchronises upstream to enterprise NTP or an external time source, and to which OT systems synchronise downstream. The OT DMZ NTP server receives time from IT-side infrastructure (one-directional, inbound to DMZ) and distributes time to OT systems (one-directional, outbound from DMZ to OT). No OT system synchronises directly against IT network time sources, and no time synchronisation traffic crosses directly between the IT network and the OT supervisory zone.
DNS presents a more complex challenge. OT systems typically use IP addresses rather than hostnames for system identification, a reflection of their age and design philosophy, which reduces but does not eliminate DNS dependencies. Where DNS is required in the OT environment, a dedicated OT DNS resolver in the OT DMZ should serve OT systems, with no OT system directly querying IT-side or external DNS infrastructure. DNS queries from OT systems that reach external resolvers are a covert channel that adversaries have exploited in documented OT intrusions.
Software update distribution for OT systems that can be patched must use a dedicated update distribution infrastructure in the OT DMZ, not direct connectivity from OT systems to internet update sources or IT patch management infrastructure. An update distribution server in the OT DMZ receives updates from IT-side patch management infrastructure through a defined, controlled inbound path, validates the updates against vendor-published hashes, and makes them available to OT systems through a separate, OT-side distribution mechanism. The validation step, confirming that software received from the IT environment matches vendor-published values before deploying it to OT systems, is a defence against the supply chain attack scenario in which compromised software is introduced through the patch management pipeline.
Part 7: Monitoring the DMZ, what to look for
The OT DMZ that is correctly designed and operated generates a predictable, characterisable traffic pattern. Every legitimate traffic flow through the DMZ is defined by a firewall rule with a documented business justification. Every device in the DMZ is known and managed. Every remote access session is initiated through the jump host and recorded. Deviations from this pattern are the signal that something requires investigation.
The monitoring architecture for the OT DMZ should capture:
All firewall rule hits, logged to a security SIEM with sufficient detail to identify source, destination, protocol, and rule matched. Rule hits that do not correspond to the expected pattern for the time of day, the systems involved, or the protocol used are anomaly signals. A historian replication flow that suddenly begins transferring dramatically more data than its historical baseline is worth investigating. A firewall rule that has not been hit for six months may indicate that the service it supports is no longer operational, or that traffic has found an alternative path.
All remote access session events: session initiation, authentication, duration, systems accessed, and session termination. Sessions that occur outside business hours, sessions that access systems not typically accessed by the authenticating user, and sessions from geographically anomalous source locations all warrant review.
All DNS queries from DMZ systems, to identify attempts by DMZ-resident systems to resolve external hostnames that are not part of their expected operation. DNS-based command-and-control, a technique widely used by adversaries to maintain persistence while evading firewall controls, generates DNS queries that would be anomalous relative to the expected DNS activity of a correctly configured DMZ system.
Protocol content for industrial protocol flows, using the application-layer inspection capability of the DMZ firewall or a dedicated OT protocol inspection system. Modbus transactions to unexpected register addresses, OPC-UA write operations that were not expected, DNP3 unsolicited responses from field devices to unexpected destinations, all of these are protocol-layer anomalies that network-layer monitoring alone will not detect.
Conclusion: The DMZ as the architecture’s immune system
The OT DMZ is not a glamorous architecture component. It does not appear on executive dashboards. It does not generate the business case numbers that SCADA modernisation projects or AI deployments generate. It is infrastructure, background, invisible when it works, catastrophic when it fails.
But in the architecture of an energy operator’s OT security posture, the DMZ occupies a role analogous to an immune system: it is the mechanism through which the boundary between the protected environment and the hostile environment is maintained, and it does this work continuously, against every attempt, legitimate and malicious, to cross that boundary. An immune system that is too weak lets pathogens through. One that is too aggressive attacks the host. The OT DMZ that is designed correctly is precisely calibrated: it passes everything that legitimate operation requires and stops everything that legitimate operation does not require.
Getting that calibration right demands the specificity I have tried to provide here. Generic guidance, “implement a DMZ with two firewalls and a jump host”, is not wrong, but it is not sufficient. The data flows must be mapped and categorised. The firewall rules must be specific, documented, and maintained. The jump host must be hardened and monitored with full session recording. The infrastructure services must be designed to avoid the covert channels that a poorly designed architecture inadvertently creates. The monitoring must be calibrated to the expected behaviour of a correctly operating DMZ, so that deviations are detectable.
That is a significant investment of design effort and operational discipline. For the infrastructure that sits between an enterprise IT environment and the control systems of an energy operator, it is the minimum investment that the risk profile justifies.
Key references and further reading
- ISA/IEC 62443-3-3 — System Security Requirements and Security Levels. The zone and conduit requirements that the OT DMZ architecture must satisfy, including the conduit security requirements for connections between zones at different Security Levels.
- NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security. Section 5.7 covers DMZ architecture in OT contexts with specific reference to the historian boundary and remote access patterns described here.
- Waterfall Security Solutions — Unidirectional Security Gateway Technical Documentation — The technical reference for data diode architecture and protocol connector design described in Part 3.
- Andrew Ginter — Secure Operations Technology — The most technically rigorous book on OT security architecture available, with extensive treatment of the network boundary design patterns described in this post.
- NERC CIP-005-6 — Electronic Security Perimeters. The regulatory baseline for electronic security perimeter design in bulk electric system environments, directly relevant to the firewall architecture in Part 4.
- SANS ICS Security Curriculum — Specifically ICS515 (ICS Active Defense and Incident Response) and ICS612 (ICS Cybersecurity In-Depth), which provide practitioner-level coverage of OT network architecture and monitoring.
- Dragos — OT Network Architecture Reference — Vendor documentation but technically substantive, covering the network segmentation patterns and monitoring architecture described in Parts 4 and 7.
- MITRE ATT&CK for ICS — Lateral Movement — attack.mitre.org/matrices/ics/ — The adversary lateral movement techniques that the OT DMZ architecture described here is specifically designed to detect and prevent.
This post is part of an ongoing series on security architecture for critical infrastructure and energy systems. The next post shifts focus to incident response — specifically, why the playbooks and assumptions that work in enterprise IT environments are actively dangerous when applied to OT environments, and what a safe and effective OT incident response capability actually looks like.
About the author: Infrastructure Architect with 14 years of experience spanning enterprise architecture, operational technology environments, and regulated digital infrastructure. Currently leading infrastructure architecture for a major energy operator. Holds CISSP certification. Previously Technical Director at a digital health startup. Views expressed are personal.