Industrial DMZ: How to Design the Boundary Zone Between IT and OT Networks

Why a Direct IT-OT Connection Is an Architectural Risk

The push to connect the IT network with the OT network is understandable: process data has value outside the factory too. ERP systems need to know how many units each line has produced. The engineering team wants remote access for diagnostics. Management wants a dashboard with real-time production KPIs.

The problem is how this connection is implemented. The simplest approach, technically, is to tear down the separation: put the OT network on the same segment as the IT network, or at most add a permissive firewall rule. The result is a flat network where a compromised IT endpoint has direct access to PLCs, HMIs and SCADA systems. Ransomware that propagates laterally across the IT network finds no architectural obstacles before reaching the control systems.

The industrial DMZ (Industrial DMZ, I-DMZ) is the architectural answer to this problem. It is an intermediate network zone, physically and logically separated from both the IT network and the OT network, where the services that need to talk to both worlds live. It is not a more powerful firewall: it is a change of paradigm. No IT host communicates directly with an OT host, and vice versa. All traffic passes through intermediate systems located in the DMZ, which mediate the communication and apply controls.

What Goes in the Industrial DMZ

Identifying which components belong in the DMZ is the first design step. The criterion is simple: if a system needs to receive data from OT and make it available to IT, or if it needs to let IT act on OT in a controlled way, that system belongs in the DMZ.

Historian replica (or data broker). The process historian collects real-time data from OT and makes it available to IT systems for analysis, reporting and ERP integration. The correct approach is not to let the ERP query the OT historian directly, but to replicate the data to a second historian located in the DMZ, which becomes the access point for IT. The flow is one-way: OT writes to the process historian, the process historian replicates to the DMZ, IT systems read from the replica. No IT system ever has a connection into the OT network.

Jump server (or bastion host). Remote access to OT assets, by both internal staff and vendors, must pass through a controlled access point. The jump server lives in the DMZ, is hardened, has multi-factor authentication and records all sessions. An external technician who needs to perform maintenance on a PLC connects to the corporate VPN, from there to the jump server in the DMZ, from there to the OT device. At every step there is authentication, logging and the ability to terminate the session in case of anomalous behavior.

Controlled file transfer. Firmware updates, configuration files, patches for Windows systems embedded in OT: all of this has to cross the IT-OT boundary. The correct mechanism is a file transfer system in the DMZ with mandatory antimalware scanning and an approval workflow. Files arrive from IT into the DMZ, are scanned, are approved, and are then downloaded by OT. Never a direct transfer from USB or from IT shares.

Patch management server. Windows or Linux systems in OT need security patches, but cannot access Windows Update or IT repositories directly. A patch management server in the DMZ collects the updates from IT and distributes them to OT in a controlled way, with the option of staging and rollback.

Proxy for OT protocols toward the cloud. If some OT data must reach cloud services (telemetry to the PLC vendor, integrations with analytics platforms), the proxy resides in the DMZ and not in the OT network. This limits the surface exposed to the outside.

Design Pattern: The Dual-Homed Firewall and Minimal Rules

The physical implementation of the industrial DMZ typically calls for two firewalls in series: a firewall between IT and the DMZ, and a second firewall between the DMZ and OT. Traffic must cross both to go from one side to the other.

The dual-homed pattern with two separate firewalls (ideally from different vendors, to avoid a vulnerability in the firewall affecting both layers) is preferable to the approach with a single three-interface firewall. The reason is simple: if the single firewall is compromised, all three segments are exposed. With two firewalls in series, an attacker has to compromise two.

The firewall rules for the industrial DMZ must follow the principle of least privilege applied to network traffic:

• From OT to the DMZ: only the protocols needed for historian replication and for communications toward the patch server. No OT connection to the internet.
• From the DMZ to OT: only the response traffic to connections initiated by OT, the patch server traffic, and the sessions authorized by the jump server.
• From IT to the DMZ: access to the historian replica, to the jump server (after authentication), and to the file transfer system.
• From the DMZ to IT: no connection initiated by the DMZ toward IT. Responses only.

The temptation to add exceptions grows over time: a system wants direct access, a vendor asks for a temporary open port that then becomes permanent, a legacy integration does not work with the proxies. Every exception must be documented, justified, approved and reviewed periodically.

Criticality-Based Segmentation Within OT

The DMZ is not the only separation needed. Within the OT network, criticality-based segmentation further reduces risk: if an OT device is compromised, internal segmentation limits propagation toward the most critical systems.

A common approach for manufacturing OT is to divide the OT network into zones based on process criticality:

• Critical zone: PLCs, DCS, safety systems (SIS). Strictly limited access, no direct connection from less critical zones.
• Supervision zone: HMIs, SCADA servers, primary historian. Communicates with the critical zone and with the DMZ.
• Peripheral zone: field devices with network connectivity, industrial printers, vision systems. Isolated from the upper zones where possible.

Internal segmentation does not require enterprise firewalls for every zone: VLANs with correctly configured ACLs are often sufficient for most medium-sized manufacturing environments.

Start With a Minimal DMZ and Grow It

The complete industrial DMZ, with historian replica, jump server, patch management and all the components described, can look like a large-scale project. For many manufacturing SMEs, the practical starting point is a minimal DMZ that solves the most urgent problems.

The minimal version starts from two elements: a firewall that separates OT from the IT network (even with a single firewall, as a first step) and a jump server for controlled remote access. This already eliminates direct access to OT and centralizes the management of vendor remote access, which is among the most frequent attack vectors in OT.

The second step is to add the historian replica, which removes the need for IT systems to access OT directly for process data. The third step is to structure file transfer with malware scanning. Only after these fundamental elements does it make sense to tackle internal OT segmentation and structured patch management.

Every addition must be planned with the operations team, not just with the IT team: changing the OT network architecture requires maintenance windows, regression testing on the process, and coordination with the control system vendors. The industrial DMZ is not a project you implement in one afternoon, but every step concretely reduces the architectural risk you start from.

The MON5 Angle

Let us be clear right away: the industrial DMZ is delivered by the firewalls and appliances that enforce the deny-all rules with whitelists described above. MON5 is not that firewall, it does not enforce and it does not block traffic inline. Its role is a different one, and it is complementary: to provide the visibility to design the boundary and then verify that it stays intact.

DMZ rules are in fact written starting from real traffic, not from assumptions. MON5's DISCOVER phase exists precisely for this: passive observation of the flows between IT and OT and reconstruction of the network topology, without stopping production, to document what actually transits at the boundary. ANALYZE then structures those flows into zones and conduits according to IEC 62443.

Once in operation, the PROTECT phase with passive out-of-band NDR verifies over time that the conduits are respected and flags the communications that violate the architecture: temporary ports left permanent, flows that were never authorized, deviations from the baseline. Before designing your DMZ, capture the real flows with an OT assessment.