Let’s explain what the Industrial DMZ (Level 3.5 in the Purdue Model) actually is, why it exists, and what design principles separate a real IDMZ from a pair of firewalls someone labelled \”DMZ\” on the diagram.

Let’s talk about something crucial in the world of Industrial Control Systems (ICS) and Operational Technology (OT): the Industrial DMZ, also known as Level 3.5 or IDMZ.

On a lighter note, a friend of mine once asked whether the iDMZ was a new Apple product. He was relating the lowercase ‘i’ to the iPhone and iPad. (He is not much of an Apple fan.) The answer is no. It is a security buffer, and in 2026 it is one of the single most important pieces of architecture in a mature OT network.

Where it sits

The Purdue Model organises industrial networks into levels:

• Level 0:sensors and actuators
• Level 1:controllers (PLCs, RTUs)
• Level 2:HMIs and SCADA
• Level 3:site operations (historians, MES)
• Level 3.5:the Industrial DMZ
• Level 4:business operations (ERP)
• Level 5:enterprise IT

Level 3.5 sits between the trusted industrial zone (Levels 0 to 3) and the less-trusted enterprise zone (Levels 4 to 5). Its job is to broker communication between them so the two zones never talk directly.

The core design principle: terminate and initiate

This is the part most “DMZs” get wrong. A real IDMZ implements terminate and initiate. No traffic passes through the IDMZ end-to-end.

• A session originating in the enterprise zone terminatesat a server inside the IDMZ.
• That server initiatesa separate, new session into the industrial zone.

Two sessions, not one. The IDMZ server is the broker. This breaks any direct TCP path between IT and OT, so an attacker on the IT side cannot pivot through a single open port. They have to compromise the broker itself, which is a different problem.

If your “IDMZ” has rules that forward traffic from IT straight to OT, it is not an IDMZ. It is a firewall with a marketing label.

What lives in the IDMZ

Typical IDMZ citizens:

• Patch management servers.Pull patches from the internet (on the IT side), push them to OT assets (on the OT side), with the IDMZ server as broker.
• Jump servers / bastion hosts.Vendor and remote engineer access terminates here and is re-initiated into the OT network, with session recording and MFA.
• Reverse proxies.Expose historian or read-only data to IT without giving IT any direct OT route.
• Antivirus / endpoint management servers.Same pattern. Pull signatures from IT, distribute to OT.
• Data brokers / historians.Collect data from OT, expose read-only to IT.

Everything in the IDMZ is a broker. Nothing in the IDMZ should be the primary system of record. If the IDMZ burns down, the OT side keeps running.

Six design principles (from practitioners, not marketing)

1. No network traffic traverses the IDMZ.Every session from either zone must terminate inside the IDMZ.
2. ICS automation protocols stay in the industrial zone.Modbus, Profinet, EtherNet/IP, OPC. These never cross into or through the IDMZ.
3. All data in the IDMZ is transient.Nothing is permanently stored there. If an attacker compromises an IDMZ server, they should find caches, not canonical data.
4. Primary services do not live in the IDMZ.If OT depends on a service to run, that service lives in the OT zone. The IDMZ holds brokers to that service, not the service itself.
5. Broker services are segmented.Each broker sits on its own dedicated subnet (VLAN), so compromise of one does not give access to the others.
6. The IDMZ should be detachable without halting operations.If a compromise is suspected, you should be able to physically disconnect the IDMZ from the enterprise and keep production running.

Relationship to IEC 62443

IEC 62443 uses the language of zones and conduits. In that language:

• The enterprise zone is one zone.
• The industrial zone is another.
• The IDMZ is a third, critical zonewith its own security requirements.
• The firewalls between them are conduits,each with its own security policy.

Each conduit gets a target Security Level (SL-1 through SL-4) from a risk assessment. The IT-to-IDMZ conduit and the IDMZ-to-OT conduit typically have different, and asymmetric, policies.

A note on terminology

You will see people argue that “IEC 62443 does not actually use the term Level 3.5 or IDMZ.” That is technically correct. The standard speaks in zones and conduits, not Purdue levels. But the industry has settled on “IDMZ” and “Level 3.5” as shared shorthand for the zone that brokers IT and OT, and it is useful vocabulary. Use it, and be ready to translate to 62443 language when you are in a formal conversation.

When you do not need an IDMZ

Only when your OT network is truly isolated. No data leaves, no remote access, no patches, no vendor connections. For virtually every real plant in 2026, an IDMZ is not optional. It is baseline architecture.

RelyBlue designs and validates IDMZ architectures aligned to IEC 62443 zone-and-conduit requirements. Contact us for a network architecture review.