Nearly every OT security control assumes one thing is true: that the network between your business systems and your controllers is segmented, with a DMZ in the middle and firewalls that mean what their rule bases say. When that assumption fails - a flat network, an any-any rule, a dual-homed engineering workstation - everything built on top of it fails with it. This guide covers practical industrial DMZ and firewall design: the Purdue model and IEC 62443 zones and conduits, what belongs in the DMZ, how to write rules that survive an audit, when a data diode earns its cost, the mistakes that quietly undo segmentation, and how cloud SCADA fits the model without punching holes in it.
From the Merobix industrial security hub - every security, compliance & certification guide in one place.
The industrial DMZ exists to answer one question safely: how do the business network and the control network exchange data without ever touching each other directly? The business side legitimately needs production data - historians feed accounting, dashboards feed management, ERP systems schedule production. The control side occasionally needs things from outside - patches, antivirus signatures, remote support. Without a DMZ, these needs get met with direct connections, and every direct connection is a path a compromise can travel.
The consequence pattern is well documented. Ransomware lands on the IT network through phishing or an exposed service; it spreads laterally to anything reachable; and if the SCADA server, historian, or engineering workstation is reachable from IT, operations goes down with the office. In several publicized pipeline and manufacturing incidents - Colonial Pipeline, documented in CISA's DarkSide ransomware advisory (AA21-131A), being the best known - operators shut down the process not because controllers were hit, but because they could not be confident the compromise hadn't crossed - the absence of trustworthy segmentation cost days of production either way. A well-built DMZ is what lets you answer "the OT side is isolated, and here is the rule base that proves it."
The Purdue reference model - the reference architecture used throughout the NIST SP 800-82 Rev. 3 guide to OT security - organizes an industrial network into levels: field instruments and I/O at Levels 0–1, local control and HMIs at Level 2, site operations systems - SCADA servers, historians - at Level 3, and business IT at Levels 4–5. Between 3 and 4 sits the Level 3.5 DMZ, the buffer this article is about. The model is a map, not a mandate - modern architectures (cloud, IIoT, edge analytics) don't fit it perfectly - but its core rule remains the most useful sentence in OT security: traffic between the enterprise and the control system terminates in the DMZ; nothing passes straight through.
The ISA/IEC 62443 series of standards generalizes this into zones and conduits. A zone groups assets with common security requirements and consequence levels - your safety instrumented system should be its own zone, separate from basic process control, separate again from the DMZ. A conduit is the defined communication channel between zones, with documented endpoints, protocols, and controls. The discipline this vocabulary buys you:
A production-grade DMZ uses two firewall layers - one between IT and the DMZ, one between the DMZ and OT - ideally from different administration domains, so a single misconfiguration doesn't open both doors. (Smaller sites sometimes use one firewall with three interfaces; it's weaker but vastly better than nothing.) Between those layers live the broker services:
Just as important is what does not belong in the DMZ: domain controllers shared with IT, engineering workstations, anything with a second network card bridging zones, and any service nobody can name an owner for.
A firewall is only as good as its rule base, and OT rule bases rot in a characteristic way: they start clean, then accumulate vendor-visit rules, commissioning rules, and troubleshooting rules that never expire. The design principles that resist the rot:
| Boundary Option | Direction Enforcement | Typical Cost | Best Fit |
|---|---|---|---|
| Router ACLs / VLANs only | Logical, easily bypassed by misconfiguration | Already owned | Interim step only - better than flat, not a destination |
| Single three-legged firewall | Logical, single point of failure and misconfiguration | Low to moderate | Small sites on the way to a dual-layer design |
| Dual-firewall DMZ | Logical, two independent layers | Moderate | The standard for most plants and utilities |
| Industrial protocol-aware firewall | Logical, plus deep inspection of Modbus/DNP3 function codes | Moderate to high | Boundaries where write commands must be policed in-protocol |
| Data diode | Physical one-way transfer | High per link (varies widely by vendor and throughput) | Highest-consequence conduits: safety systems, SL3–SL4 zones, regulated one-way feeds |
A data diode enforces direction physically - typically a transmit-only optical link - so no configuration error, compromise, or insider can ever make data flow backward into the protected zone. That guarantee is categorical in a way no firewall rule can be, and for a small set of conduits it is worth paying for: safety system data leaving an SIS zone, monitoring feeds from nuclear or defense facilities, and regulated environments targeting IEC 62443 SL3–SL4 where unidirectional gateways are explicitly recognized.
Be equally clear about the costs. Hardware runs from thousands to tens of thousands of dollars per link depending on vendor and throughput - and honest budgeting doubles that for the engineering to make protocols work one-way (TCP does not survive a diode without proxy appliances on both sides). You lose any remote management path into the protected zone by design, so every configuration change is a site visit. The pragmatic pattern: diode the few conduits whose consequence justifies it, and use well-run firewalled conduits everywhere else.
A common misconception holds that cloud monitoring and the Purdue model are incompatible - that connecting OT data to a cloud platform means opening inbound paths through every boundary. Architecture decides. A cloud platform that requires inbound connections to an OT-resident server does break the model. A platform built on outbound-only connectivity fits it cleanly: the gateway sits in the OT zone, polls PLCs and RTUs locally, and initiates encrypted TLS sessions outward through the DMZ's egress path. Every firewall keeps its deny-all-inbound posture; the conduit is documented, direction-enforced by design, and restricted to a named destination.
Merobix is built on exactly this pattern. The gateway makes outbound-only connections - no inbound ports, no VPN - and supports drivers for the major industrial protocols (Modbus, DNP3, OPC UA, EtherNet/IP, Siemens S7, and MQTT) (Modbus RTU/TCP, OPC-UA, MQTT, DNP3, BACnet/IP, EtherNet/IP, HTTP), with store-and-forward buffering so a WAN outage doesn't lose data. Each device registers with unique credentials and signs its telemetry with a device-held Ed25519 identity, giving the receiving platform cryptographic evidence of origin and replay protection. Where control is enabled, writes pass through explicit writable-tag configuration and setpoint bounds checking rather than open protocol access. And for facilities whose policy forbids any external conduit, the same platform deploys fully on-premise inside the OT zone - air-gapped if required. The full architecture is on our security page, and our cloud vs on-premise comparison works through the deployment decision; you can walk the data path end to end in a live demo.
Key takeaway: Segmentation succeeds or fails on discipline, not diagrams. Two firewall layers with a brokered DMZ, deny-by-default rules that name specific hosts and ports, outbound-initiated flows, logged boundaries, and a quarterly rule review will put you ahead of most of the industry - and an outbound-only monitoring architecture means your remote visibility never becomes the hole in it. The most dangerous rule in any OT firewall is the temporary one nobody remembers adding.
Few operators build this greenfield. A realistic migration from a flat or lightly segmented network, in the order that buys the most risk reduction per change window:
An industrial DMZ (often called the Level 3.5 DMZ in the Purdue model) is a buffer network between the OT network that runs the process and the IT network that runs the business. Every service that both sides need - historian mirrors, patch staging, remote access brokers, file transfer - lives in the DMZ, so that no connection ever passes directly from IT (or the internet) to a controller. Without it, a single compromised office laptop is one network hop from your PLCs, which is exactly how many industrial ransomware incidents spread into operations.
IEC 62443 generalizes the Purdue model into zones and conduits. A zone is a group of assets that share common security requirements - for example, the safety system, the basic control network, and the enterprise network are separate zones. A conduit is the defined, controlled communication path between zones, typically enforced by a firewall or a data diode. The design discipline is to document every conduit, minimize what each conduit allows, and assign each zone a target security level so the strength of the boundary matches what the zone protects.
Deny by default, then allow the minimum: every rule should name specific sources, specific destinations, specific ports and protocols, and carry a comment stating its business purpose and owner. Prefer outbound-initiated flows (OT pushes data out; nothing outside initiates inward), terminate every flow in the DMZ rather than passing it through, log denied and permitted traffic on OT boundaries, and review the rule base on a schedule so temporary rules actually expire. A rule containing the word ANY in source, destination, or service is a finding, not a rule.
A data diode physically enforces one-way data flow - typically with optics that can only transmit in one direction - so even a fully compromised receiving network cannot send anything back into the protected zone. They are the strongest boundary available for high-consequence conduits: safety systems, nuclear and defense applications, and regulated environments targeting IEC 62443 SL3 to SL4. The trade-offs are cost (commonly thousands to tens of thousands of dollars per link, varying by vendor and throughput), one-way-only protocols, and loss of any remote configuration path. Most operators apply diodes only to their few highest-consequence conduits and use firewalled conduits elsewhere.
Well-designed cloud SCADA fits the model as an outbound-only conduit: a gateway inside the OT zone polls devices locally and initiates encrypted TLS connections outward through the firewall layers, so no inbound rules are added at any boundary. This preserves the deny-all-inbound posture that the DMZ exists to protect. Merobix works this way - its gateway makes outbound-only connections, authenticates with unique per-device credentials, and signs telemetry at the device - and for facilities whose policy prohibits any external path, the platform can also be deployed fully on-premise inside the OT zone, including air-gapped.
Outbound-only gateway, zero inbound rules at any boundary, signed telemetry, and an on-premise option for air-gapped zones - see how Merobix fits the architecture you're building.