The OT DMZ: building the layer between your plant floor and IT

If you do exactly one thing to secure a plant this year, build the DMZ between the enterprise network and the plant floor. Not a firewall — a DMZ. Most Indian plants we walk into already have a firewall at that boundary and believe the job is done. It isn't, and the difference is the whole point.

A firewall with a rule that lets the enterprise historian reach the plant historian, and the plant SCADA server reach the enterprise patch server, is not a DMZ. It is a flat network with a speed bump. When ransomware lands on a finance laptop — which is where it almost always lands — that speed bump is exactly as effective as the "any/any allow — temporary" rule someone added in 2021 and never removed. The plant goes down with the office.

The industrial DMZ (iDMZ) exists to make sure that no packet ever travels directly from the enterprise network to the control network, or back. Everything stops in the middle, at a broker, and starts again as a fresh conversation. That single architectural rule is what turned "OT segmentation" from a slide into a control that survives a real intrusion. This is how to build it.

Why a firewall between IT and OT is not a DMZ

The Purdue model — which our OT architecture guide walks level by level — puts a boundary at Level 3.5, between the manufacturing operations zone (Level 3) and the enterprise zone (Levels 4 and 5). That boundary is the iDMZ. The mistake almost everyone makes is treating 3.5 as a line to filter across rather than a zone to terminate in.

Here is the distinction that matters, in one table:

Zones and conduits: the IEC 62443 way to think about it

IEC 62443 — the international standard for industrial automation security — gives us the vocabulary that keeps a DMZ design honest. You divide the plant into zones (groups of assets with the same security requirement) and you connect zones only through conduits (defined, controlled communication paths). The iDMZ is itself a zone. Every service inside it is reached through a conduit, and no conduit passes straight through.

Practically, this means each direction of data movement is a pair of conduits meeting at a broker in the DMZ:

The historian replica in the DMZ pulls from the plant historian on one schedule and serves the enterprise on another. The MES on the enterprise side never learns the plant historian's address, because it never needs it. That is the entire trick, and it is why an iDMZ done properly contains a breach instead of forwarding it.

What actually goes inside the iDMZ

An iDMZ is not a subnet full of production systems. It holds a small, deliberate set of broker services — each one the terminating point of a conduit that would otherwise have been a dangerous pass-through. The common ones:

Notice what is not in that list: no PLCs, no SCADA servers, no engineering workstations, no domain controllers. Production systems live at Level 3 and below. If a "DMZ" contains an actual HMI or a shared Active Directory domain controller, it is not a DMZ — it is a second control room with a firewall in front of it.

The rules that keep a DMZ from collapsing

Every failed iDMZ we have reviewed broke one of these five rules. They are not negotiable, because each one, quietly relaxed, restores the flat pass-through you were trying to eliminate.

1. No dual-homed hosts. A single machine with one NIC in the enterprise and one in the plant is not a broker — it is a bridge, and it defeats the entire DMZ the moment it is compromised. Every DMZ service sits on the DMZ segment only; the firewall moves data between zones, not a host's second network card.

2. No protocol passes through. Modbus, EtherNet/IP, S7comm, DNP3 and their kin have essentially no authentication — they were designed for a trusted wire. They must never traverse Level 3.5. If enterprise systems need plant data, they get brokered data (SQL, OPC UA to a DMZ server, a file), never raw industrial protocol.

3. Deny by default, both directions. The base ruleset is deny-all. Every allowed flow is an explicit conduit between one DMZ broker and one named host, on one port, reviewed and dated. "Any" has no place in a source, destination or service field at this boundary.

4. No shared identity across the boundary. The plant does not join the enterprise Active Directory domain. A compromise of enterprise AD — the single most common path in a real OT incident — must not hand an attacker plant credentials. The OT environment runs its own directory, or local accounts with a separate lifecycle.

5. The DMZ initiates nothing outbound to the internet. No broker in the DMZ browses the web, checks for updates, or phones a vendor cloud on its own. Updates are pushed to it from the enterprise side under control. A DMZ host with internet egress is a staging server for whoever compromises it.

Data diode or firewall?

For the highest-assurance boundaries — a transmission utility's control centre, a pipeline SCADA, a defence-adjacent plant — a data diode enforces one-way flow in hardware. Data physically cannot travel back toward the plant, because there is no return path in the optics. For pushing historian data up to an enterprise or a regulator while guaranteeing nothing comes down, a diode is the strongest control that exists.

The trade-off is that one-way is genuinely one-way: no acknowledgements, no interactive sessions, no patch-pull, no remote access. So the realistic pattern for most Indian manufacturing and utility sites is a firewalled iDMZ for the bidirectional services (patching, remote access, file transfer) and a diode for the pure egress (historian and telemetry to the enterprise or a sector CSIRT). Use the firewall where you need conversation; use the diode where you can guarantee you never will.

Remote vendor access — the flow that breaks most plants

Ask any plant how their PLC vendor or their OEM connects for support, and the honest answer is often a TeamViewer or AnyDesk instance on an engineering workstation, or a laptop the vendor plugs in and dials out from. That is the single most exploited path into OT environments, and it usually bypasses whatever DMZ exists entirely.

The DMZ is exactly where this belongs. Vendor and remote-engineer access terminates on the DMZ jump host: multi-factor at the door, session recording, time-boxed accounts that are disabled by default and enabled for a specific window, and — critically — the jump host is the only asset permitted to open a session into Level 3. The vendor never touches a plant device directly; they operate through a host you own, watch, and can revoke in one click. If you build nothing else in the DMZ first, build this.

A sane ruleset, in shape

Rulesets rot. The way to keep an iDMZ policy honest is to write it as a small number of explicit conduits and refuse to add anything that doesn't fit the pattern one broker ↔ one host ↔ one service. In shape, it looks like this:

# Enterprise  ──▶  DMZ   (northbound consumers reach brokers only)
allow  ent-mes        ──▶  dmz-historian-replica   tcp/1433   # SQL read
allow  ent-wsus       ──▶  dmz-patch-relay         tcp/8530   # push approved patches

# DMZ  ──▶  Control     (brokers reach exactly one plant host each)
allow  dmz-historian-replica ──▶ plc-historian     tcp/OPC-UA # pull data up
allow  dmz-patch-relay       ──▶ l3-hosts          tcp/8530   # serve patches down
allow  dmz-jump-host         ──▶ l3-engineering     tcp/3389  # brokered admin

# everything else
deny   any            ──▶  any                      any       log
# NOTE: no rule where source is Enterprise and destination is Control.
#       If you ever need one, you have found a broker to build.

The mistakes we find on assessment

When we assess an existing "OT DMZ" in the field, the same handful of findings come up again and again:

• The flat DMZ — a subnet that filters but passes plant protocol straight through. A firewall, not a DMZ.
• The dual-homed historian — one server with a leg in each network "to make replication easy." It is the bridge that makes the DMZ decorative.
• The shared domain — plant and office on one Active Directory, so one phished enterprise admin owns the plant.
• The forgotten allow-any — a temporary rule from a commissioning project, still live years later, usually the widest hole in the estate.
• The vendor backdoor — an unmanaged remote-support tool on an engineering workstation, dialling out past every control.
• The USB bypass — because file transfer through the DMZ is inconvenient, the real data path is a memory stick, and so is the real malware path.

None of these are exotic. They are what a boundary decays into when it is built once and never governed. The fix is design plus discipline: a real broker for every flow, and a review that removes rules instead of only adding them.

The India context, briefly

For Indian operators, the iDMZ is increasingly not just good practice but expected. The National Critical Information Infrastructure Protection Centre (NCIIPC) publishes guidelines for protected systems in power, transport, banking and other sectors that assume IT/OT segmentation, and sector regulators — the CEA for power, for instance — have moved in the same direction. CERT-In's incident-reporting timelines apply when an OT incident becomes reportable, which is far more likely on a flat network than a segmented one. A documented, governed iDMZ is both a real control and the evidence an auditor is looking for.

How Ogma deploys the OT DMZ

Ogma Consulting is an authorized Fortinet partner, and the iDMZ is a design we deploy end to end. FortiGate — including ruggedized models rated for the plant floor, covered in our OT architecture guide — is the firewall at Level 3.5, with the OT security fabric providing application-aware control of industrial protocols and virtual patching for systems that cannot be taken offline. We map your existing flows, design the zones and conduits, stand up the broker services, migrate the dangerous pass-throughs one at a time, and hand you a ruleset you can actually govern.

Because we run vulnerability assessment and breach-and-attack simulation as services, we can also show the DMZ working: test whether a simulated enterprise compromise reaches the plant, before and after. If you are segmenting an OT environment, or you suspect the firewall you have is really a pass-through, reach out for a technical consultation — the first useful step is usually mapping what actually crosses your Level 3.5 today.

Frequently asked questions