What is an IDMZ?

An IDMZ (Industrial Demilitarized Zone) is a shielded network zone between the office network (IT) and the production network (OT) in which all traffic between the two sides terminates, so that there is never a direct connection from IT to OT or the other way round. The IDMZ contains only intermediaries, such as a mirrored historian, a jump server and a patch server. They accept data or sessions from one side and set up a new connection of their own to the other side. In the Purdue Model this zone is called level 3.5, a level that was missing from the original model and was added later through security practice. Within a Defense in Depth architecture it is the most important boundary between business operations and the physical process.


🧠 How does an IDMZ work?

An IDMZ sits between two firewalls, or behind a single firewall with at least three interfaces: one boundary towards IT and one towards OT. The operating principle is brokering instead of passing through. An IT user or the ERP system that needs production data from the MES reads a copy in the IDMZ. An engineer who wants to look at a PLC remotely logs on to a jump server in the IDMZ and from there starts a second, controlled session into OT.

Cisco and Rockwell Automation captured this way of working in their Converged Plantwide Ethernet (CPwE) architecture. Its design principles are widely used as a reference, also outside Rockwell environments:

  • No traffic passes straight through - all traffic from either side terminates in the IDMZ; there is no direct path between the enterprise and industrial zones
  • Industrial protocols stay home - EtherNet/IP, Modbus TCP and other control traffic never enter the IDMZ
  • No common protocols - no protocol or port is allowed through both IDMZ firewalls; what the IT firewall lets into the IDMZ differs from what the OT firewall lets into OT, so a worm or other malware cannot get through both firewalls with a single vulnerability
  • Data is transient - the IDMZ stores no primary data; the source stays in its own zone
  • Can be unplugged - if the IDMZ is compromised, you can disconnect it and production keeps running on its own

An IDMZ is not a firewall rule but a zone with its own servers, its own administration and its own logging.

Diagram of an IDMZ between two firewalls where IT and OT connections terminate

Figure: all connections terminate in the IDMZ; no traffic passes directly between IT and OT.


📦 Which services belong in an IDMZ?

The IDMZ contains only services needed to let IT and OT work together in a controlled way:

Service How it works in the IDMZ Who initiates
Mirrored historian The level 3 historian replicates to a copy in the IDMZ, for example via PI-to-PI OT pushes to the IDMZ; IT reads the copy
Remote Desktop Gateway / jump server RDP sessions from IT terminate here; a new session goes on to OT, with MFA IT to IDMZ, IDMZ to OT
Patch server Updates are staged from IT; a downstream server in OT fetches them OT pulls from the IDMZ
Antivirus distribution Signatures are collected centrally and passed on to OT workstations OT pulls from the IDMZ
File transfer Files are scanned and passed on via SFTP or a transfer station Both sides stage and collect
Reverse proxy / data broker Exposes web applications and OPC UA or MQTT data without direct access Consumers connect to the proxy or broker
Log forwarder Collects Syslog and events from OT and forwards them to the SIEM or SOC OT to IDMZ, IDMZ to IT

What does not belong there: OT domain controllers, PLCs, engineering workstations and public web servers. Anything the plant needs to keep running stays in the OT zone. The internet-facing DMZ at the edge of the company is a separate zone; never merge it with the IDMZ.


🔄 What is the difference between an IDMZ and an ordinary DMZ?

The principle is the same, but the protection goal differs. A classic DMZ mainly protects confidential business data from the internet. An IDMZ protects the availability and integrity of the physical process from everything that happens on the office network, including ransomware.

Characteristic Classic DMZ IDMZ
Location Between the internet and the office network Between the office network (level 4) and OT (level 3)
Main goal Confidentiality of data Availability and safety of the process
Typical systems Web server, mail relay, VPN endpoint Historian copy, jump server, patch server
Users Customers, partners, the public Own IT staff, engineers, suppliers
Impact of an outage Service unreachable Reporting and remote maintenance stop, production carries on
Guidance General network security CPwE, NIST SP 800-82, IEC 62443

🔐 What do IEC 62443 and NIST say about the IDMZ?

IEC 62443 does not mention the IDMZ by name, but it does enforce it. Under the zones and conduits model the IDMZ becomes a zone of its own, with one conduit to IT and one to OT. IEC 62443-3-2 describes how you define those zones based on risk and assign each a target security level. IEC 62443-3-3 sets the technical requirements: SR 5.1 calls for network segmentation and SR 5.2 for zone boundary protection. The requirement enhancements of SR 5.2 map directly onto IDMZ practice: deny by default, allow by exception, island mode (the zone can isolate itself) and fail close (the boundary closes when it fails).

In revision 2 (2015), NIST SP 800-82 compared five ways of separating IT and OT, from a dual-homed computer to a pair of firewalls with a DMZ between them. Its conclusion: the most secure and manageable designs have at least three zones with one or more DMZs, and the paired-firewall design is the strongest variant. Revision 3 (September 2023) states that all communication between the corporate network and OT should pass through services in the DMZ. In the Netherlands, the Cybersecurity Act (Cyberbeveiligingswet), in force since 15 August 2026, requires essential and important entities to take appropriate network security measures. For a manufacturing plant or a water board, a documented IDMZ is one of the most verifiable pieces of evidence of that, including towards NIS2 supervisors.


🛠️ How do you set up an IDMZ step by step?

  1. Inventory every flow between IT and OT - source, destination, protocol, direction and owner. In practice you will find dozens, some of which turn out to be unnecessary.
  2. Give each flow an intermediary - historian copy, broker, patch server or jump server. A flow without an intermediary is dropped or redesigned.
  3. Choose the firewalls - preferably two, ideally from different vendors, built as a next-generation firewall or industrial firewall and redundant for high availability.
  4. Separate identity - OT gets its own Active Directory domain or local accounts; no domain trust that runs from IT all the way into OT.
  5. Virtualise deliberately - IDMZ servers often run on a small dedicated cluster. Do not share a hypervisor with IT or OT, otherwise the management network bypasses the zone.
  6. Harden and monitor - minimal software, prompt patching, access control with MFA and logging of every session for forensic investigation.
  7. Manage the rules - every rule has an owner and a reason; review them periodically through firewall rule management.
  8. Test disconnection - rehearse the scenario in which you unplug the IDMZ and check that production keeps running.

Typical values help with the design. An RDP session through a Remote Desktop Gateway is tunnelled over HTTPS on TCP port 443, so the IT firewall only has to open one port to the gateway. Historian replication and log forwarding can usually be initiated from OT, so the OT firewall needs no inbound connections from the IDMZ.


⚠️ Where does it go wrong in practice?

  • Dual-homed servers - a historian with one network card in IT and one in OT bypasses the entire IDMZ
  • Supplier modems in the cabinet - a supplier’s own VPN router goes around the jump server; always route remote access through the IDMZ
  • “Temporary” rules - a rule that allows RDP directly from IT to OT often stays in place for years
  • Shared domain - NotPetya (2017) spread with stolen credentials and the EternalBlue vulnerability across shared Windows environments and so also hit production sites
  • No monitoring - the IDMZ is built and then never looked at again, even though this is exactly where anomaly detection can reveal lateral movement

The Colonial Pipeline incident of May 2021 shows why this matters: ransomware hit only IT, but because it was unclear whether OT could be reached, the pipeline was shut down as a precaution. A demonstrably separated IDMZ makes such a decision better informed.


❓ Frequently asked questions

What does IDMZ stand for?

IDMZ stands for Industrial Demilitarized Zone. It is a buffer zone between the IT network and the OT network in which all traffic between the two terminates. The term became widely known through the CPwE architecture of Cisco and Rockwell Automation.

Is an IDMZ mandatory?

No law names the IDMZ literally, but IEC 62443-3-3 requires segmentation and zone boundary protection, and the Dutch Cybersecurity Act requires appropriate network security. An IDMZ is the common way to meet those requirements between IT and OT. Auditors and supervisors therefore often ask about it.

Can an IDMZ be built with one firewall?

An IDMZ can be built with a single firewall with three interfaces, which is cheaper and simpler. Two firewalls, preferably from different vendors, provide two independent boundaries and let IT and OT each manage their own boundary. For critical installations the two-firewall design is therefore the usual recommendation.

Is a data diode an alternative to an IDMZ?

A data diode makes traffic physically one-way and is stronger than an IDMZ for flows that only go from OT to IT, such as process data. Patches, antivirus updates and remote maintenance need two-way traffic, and for those an IDMZ with firewalls remains necessary. Many installations combine both.

Does an IDMZ fit with Zero Trust?

An IDMZ and Zero Trust complement each other. Zero Trust verifies every user and device, but most PLCs and field devices cannot authenticate strongly or keep logs themselves. An IDMZ therefore remains the boundary that protects such devices, while Zero Trust principles tighten access through the jump server.

Should cloud connections go through the IDMZ?

A connection between OT and the cloud should run through the IDMZ or an equivalent controlled zone, not directly from a PLC or SCADA server. An edge gateway or data broker in the IDMZ collects the data and forwards it outbound. That way no inbound connection from the internet to OT is needed.


📌 In summary

An IDMZ is the buffer zone at Purdue level 3.5 in which all traffic between IT and OT terminates, so that production systems are never directly reachable from the office network. With mirrored data, a jump server, separate identity, strict rules and continuous monitoring, the IDMZ protects the physical process, supports IEC 62443 and the Cybersecurity Act, and is the cornerstone of security at the boundary between IT and OT.