An industrial DMZ is a dedicated third zone between IT and OT networks with its own security policy, servers, and responsibility assignment, and approved exchanges may use intermediary services.
The design supports historian replication, remote access, OPC tunneling, and other shared functions without placing OT assets on the enterprise network or creating a direct bidirectional route between the domains.
Industrial DMZ placement and security scope
An industrial DMZ occupies the boundary between the OT industrial control network and the IT enterprise network. The OT side contains PLCs, DCS systems, SCADA, HMIs, and safety systems, while the IT side contains ERP systems, business analytics, cloud platforms, and conventional enterprise infrastructure [S1].
The iDMZ is treated as a third zone rather than as part of either side. It has its own servers, security policy, and responsibility assignment, and is commonly positioned at Level 3.5 of the Purdue Model, between Level 4 site business systems and Level 3 manufacturing operations [S1].
This boundary is not equivalent to a single firewall with rules connecting an enterprise server to an OT historian. Such a bidirectional rule creates a managed bridge, leaving a permitted route that can be used for lateral movement after one endpoint is compromised [S2].
Dual-firewall architecture and independent boundaries
A dual-firewall iDMZ places one firewall between IT and the DMZ and a second firewall between the DMZ and OT.
This arrangement is more resistant than a one-firewall implementation, although the firewalls must still be managed as separate enforcement layers with explicit rules for each approved flow.
A useful comparison is: a single firewall provides one enforcement point, a dual-firewall iDMZ provides two, a unidirectional gateway permits one-way transfer, and a data diode enforces one-way data movement with a stronger physical or logical direction constraint [S2]. Cost, required data direction, operational impact, and tolerance for interactive access determine which pattern fits the application.
Services that belong inside the iDMZ
The iDMZ should contain only systems with a defined function at the IT/OT boundary. Historian replication can be configured without creating return paths between the IT and OT zones.
OPC-UA security can be configured across zone boundaries, and tightly scoped shared services may be placed in an industrial DMZ.
The iDMZ is not a general server room. The industrial DMZ has its own security policy and responsibility assignment.
Selection criteria for DMZ architectures
The first selection criterion is data direction. The cited architecture identifies firewall-controlled access, an IDMZ proxy, a unidirectional gateway, and a data diode as data-exchange patterns, including brokered access and historian replication.
The second criterion is loss-of-containment impact. A two-firewall configuration with the DMZ between the networks is considered more secure because it adds a buffer.
The third criterion is the nature of the OT endpoint. The cited architecture identifies OT assets as PLCs, DCS systems, SCADA, HMIs, and safety systems, and mentions OPC-UA security across zone boundaries.
Users, exclusions, and operational constraints
An industrial DMZ is for plants that must exchange production, maintenance, quality, or analytical data with enterprise systems while preserving a controlled boundary. It is particularly relevant where an IT application needs historian data, a remote engineer needs temporary OT access, or a manufacturing process requires an OPC data path [S1][S2].
It is not required for a completely disconnected OT environment, and it is not a substitute for controls inside the OT zone. A DMZ cannot compensate for weak PLC authentication, exposed engineering services, unmanaged remote access, or missing process-safety segmentation [S1][S3].
The design must also account for operational constraints. PLCs, RTUs, and DCS controllers can remain in service for 15 to 25 years, and some endpoints may not support the same patch cadence or endpoint security tooling as IT systems [S2]. A network scan, broadcast storm, or unexpected traffic burst can interfere with deterministic controller communications, so firewall inspection, update schedules, and failover behavior require production-aware testing [S2].
Safety Instrumented Systems require particular caution because they monitor process conditions and initiate emergency shutdowns. The iDMZ should not introduce unnecessary dependencies into safety-related traffic, and access to engineering or maintenance functions should be separated from the operational control path [S2].
Zone, conduit, standards, and verification
The IEC 62443 Zone and Conduit model provides the structured basis for an industrial DMZ: assets with similar security requirements are grouped into zones, and defined communication paths are treated as conduits. The iDMZ is a practical implementation of that model at the enterprise-to-operations boundary [S3].
NIST SP 800-82 Rev. 3, ISA/IEC 62443, and CISA guidance support the use of a separated industrial zone between IT and OT, while the Purdue Model supplies the familiar Level 3.5 placement for that boundary [S1]. Standards provide the security framework, but they do not replace a site-specific traffic inventory or rule review.
Verification should include a rule test for every permitted flow, confirmation that no enterprise host has a direct route to an OT segment, review of reverse-path behavior, and validation that a jump server cannot initiate unrestricted outbound sessions. Historian replication should be tested to prove that the enterprise-side copy does not create a return path into OT [S2].
Logging is equally important. IT-facing and OT-facing firewall events, jump-server sessions, historian transfers, proxy activity, and administrative changes need correlated timestamps and retained records so that an operator can reconstruct an exchange across the boundary. The iDMZ is effective only when the permitted path is deliberate and every unintended path is closed.
Common design failures and deployment checks
A poorly isolated iDMZ can become an entry point rather than a barrier. Its servers should sit in a clearly defined zone with secure communication channels, separate policies, controlled administration, and no casual lateral trust between the enterprise and OT sides [S4].
The most frequent error is allowing a direct bidirectional rule between IT and OT and then describing the firewall as segmentation [S2].
An industrial DMZ hosts the shared or industrial-facing services required by the plant.
A final check is operational ownership. The iDMZ needs named responsibility for firewall rules, server maintenance, authentication, logging, and incident response [S1]. Designers should also document the expected behavior of each conduit, including whether it supports requests, responses, scheduled transfers, or one-way replication, then test that behavior under maintenance and failure conditions.
Controlled conduits and defined exchange patterns can eliminate direct paths between the IT and OT networks.