What belongs in an industrial DMZ (IDMZ)

An industrial DMZ (IDMZ) is the network between the business network and the operations network where the two meet. In Purdue model terms it sits at Level 3.5, between Level 4 (business) and Level 3 (operations). The idea is simple: nothing passes straight through. Every session from the business side ends on a service in the IDMZ, and a separate session runs from that service into OT. Business users and remote users reach a service in the IDMZ, and that service, not the user’s own connection, talks to OT.

Why an IDMZ

NIST SP 800-82r3 suggests a DMZ as “an enforcement boundary between network segments” (section 5.2.3.1, Fig. 16). In its defense-in-depth example for a DCS-based system (section 5.4.1, Fig. 18), it says “any communications between the enterprise level and the operations management level are required to go through services within the DMZ,” and that those services must be monitored and protected so attackers cannot pivot through them to OT unseen.

IEC 62443 reaches the same place from a different direction: zone boundary protection (SR 5.2) and controlled access via untrusted networks (SR 1.13). An IDMZ is the usual way to meet both. The IEC 62443 guide covers those requirements.

What belongs in the IDMZ

• Jump hosts for engineering and vendor access, with multi-factor authentication and session recording.
• Historian replicas or mirrored data so business users read OT data without connecting to OT.
• Patch and antivirus distribution that OT pulls from on its own schedule.
• File transfer staging where files land, get scanned, and are picked up from the OT side.
• Application brokers and reverse proxies that publish an HMI or report view without exposing the control network.

What does not belong in the IDMZ

• Domain controllers shared by IT and OT.
• Anything OT depends on to keep running. If the IDMZ is cut off, the site should keep operating.
• Plant-floor protocols such as Modbus or EtherNet/IP.
• The system of record. A historian replica belongs here; the primary historian stays in Level 3.
• Direct allow rules that pass traffic through from Level 4 to Level 3 or below. A rule that forwards Level 4 to Level 2 is not an IDMZ, even if the firewall interface is named DMZ.

OT remote access through the IDMZ

Remote access is where IDMZs most often get bypassed. The pattern that holds up:

1. Remote users (staff, integrators, vendors) connect to a VPN or remote-access gateway that lands in Level 4 or the IDMZ, never in OT.
2. They sign in to a jump host in the IDMZ with multi-factor authentication. Sessions are recorded.
3. The jump host connects to a named Level 3 host on named applications, such as RDP or SSH.
4. Work on Level 2 and Level 1 happens from that Level 3 host, inside OT. The IDMZ never reaches L2 or L1 directly.

NIST SP 800-82r3 section 6.2.10 adds that remote access should be justified, limited to the business need, and removed when no longer required, and that multi-factor authentication should be considered.

Paths that show the IDMZ is being bypassed

• Direct from outside. Internet, VPN or partner sessions that land in OT.
• Direct from the office. Office PCs reaching HMIs, PLCs or OT servers without stopping in the IDMZ.
• VPN pools inside OT. A VPN that hands out addresses in an OT zone or the IDMZ itself.
• Remote-support tunnels. Agents or vendor cloud gateways in OT that call out and let someone back in, which no inbound rule controls.
• Standing access. Rules that would let someone in but saw no use. They are a way in waiting to be found.
• Leaky brokers. IDMZ hosts that also open sessions straight to Level 2 or Level 1.

How SegAudit reports remote access and the IDMZ

SegAudit’s remote access review lists every way into the site from outside it, grouped as direct from outside, direct from the office, VPN landing in OT or the IDMZ, remote-support tunnels, standing access that went unused, and access brokered in the IDMZ. Each path shows who used it, from where, to where, the allowing rule, the sessions and dates, and what to do about it. Named accounts that reach OT without an IDMZ broker are listed, and sessions that carried no user are counted.

In the Northline sample (a made-up three-site company that ships with SegAudit), the review shows a critical path “vpn-remote L5 → ot-control L1 · modbus on 502”, with the action: “Cut it: no industrial protocol from outside the control network. Engineering access goes through an engineering jump host with MFA in the IDMZ.” Brokered paths are kept, with a reminder to confirm MFA and session recording on the jump host, which a firewall cannot see.

The same paths feed the IEC 62443-3-3 SR 1.13 control in the compliance crosswalk and the findings list, where they appear as findings such as “Internet (L5) reaching L1 OT · 13 sessions”.

Common questions

Is an IDMZ the same as an IT DMZ? The idea is the same, a buffer network between two trust levels, but the IDMZ separates business from operations, not the internet from the business network.

Do small sites need an IDMZ? Neither the Purdue model nor NIST SP 800-82r3 requires one. A small site might use a single jump host and a historian replica behind a firewall instead. What matters is that business and remote traffic stop at a service rather than passing straight through to OT.

Can the firewall prove MFA is on? No. The firewall shows that sessions stop at the jump host. MFA and session recording are configured on the jump host and need their own evidence.