Industrial DMZ & Firewall Design for SCADA

Back to Blog

From the Merobix industrial security hub - every security, compliance & certification guide in one place.

Why SCADA Needs a DMZ

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 Model, Zones, and Conduits

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:

• Every conduit is inventoried. If data crosses a zone boundary and no documented conduit covers it, that's an undocumented hole, not a convenience.
• Each zone gets a target security level (SL1–SL4), so the strength of each boundary is proportional to what it protects - the yardstick our secure SCADA buyer's guide covers in depth.
• Consequence drives design. The zone containing the safety system justifies a stronger boundary - possibly a diode - than the zone serving dashboards.

Anatomy of a Well-Built Industrial DMZ

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:

• Historian mirror or data replica - the OT historian pushes data up to a DMZ replica; business users query the replica, never the OT original.
• Patch and antivirus staging - updates land in the DMZ, get verified, and are pulled from there into OT during change windows.
• Remote access broker / jump host - the only supported path for interactive remote work: MFA at the front door, per-user authorization, session recording.
• File transfer intermediary - a scanned, one-direction-at-a-time drop zone that replaces USB sticks and direct shares.
• Outbound proxy for cloud connectivity - where cloud monitoring is in scope, the egress point where outbound TLS from OT gateways is inspected and restricted to known destinations.

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.

Firewall Rule Design: Deny by Default, Then Prove Every Exception

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:

1. Default deny in both directions. The last rule is deny-all, and it should be doing most of the work.
2. Specific everything. Every allow rule names specific source hosts, destination hosts, and ports/protocols. The word ANY in a source, destination, or service field is a finding.
3. Prefer outbound initiation. Data should leave OT because something inside pushed it, not because something outside pulled it. Inbound-initiated flows into OT should be rare, brokered, and individually justified.
4. Terminate flows in the DMZ. No rule should permit a session from Level 4 to pass through to Level 3 or below - that's a tunnel, not a conduit.
5. Comment every rule with its business purpose, owner, and review date. An uncommented rule is unremovable forever, because nobody dares.
6. Log at the OT boundary - denied traffic tells you who's knocking; permitted traffic gives you the forensic timeline when you need one.
7. Review on a schedule. Quarterly rule review with the deny counters in hand; every temporary rule carries an expiry date enforced by the review, not by memory.

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

Data Diodes: When One-Way Is Worth It

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.

Seven Mistakes That Quietly Undo Segmentation

• The dual-homed workstation. An engineering PC with one NIC in OT and one in IT is a bridge over both firewalls. Every zone crossing goes through the conduit or it doesn't go.
• The any-any vendor rule. Commissioning ends; the rule stays. Scope vendor rules to source, destination, port, and calendar.
• Shared Active Directory across the boundary. If OT machines authenticate against the IT domain, an IT domain compromise is an OT compromise. Separate forests or local accounts below the DMZ.
• DNS, NTP, and print paths nobody mapped. Small utility protocols quietly cross zones and carry compromise with them. Serve them from the DMZ.
• The unpatched firewall itself. The boundary device is a computer too - its firmware, admin interface, and credentials need the same lifecycle discipline as anything else. Admin access should come from a management network, never from the internet.
• No egress filtering. If everything inside OT can reach any internet address outbound, malware that does get in phones home unimpeded. Restrict outbound flows to named destinations - monitoring platforms, update sources - and log the rest.
• Backdoors around the DMZ. A cellular modem on the control network, a port forward on a site router, remote desktop software on an HMI - each one bypasses every layer you built. This failure mode is common enough that we gave it its own article on exposed, internet-facing HMIs.

How Cloud SCADA Fits the Zone Model

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.

A Practical Sequence for Getting There

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:

1. Map what exists. Passive traffic capture at key switches for two weeks; you cannot write rules for flows you haven't seen - and you will find flows nobody expected.
2. Kill the backdoors first. Port forwards, cellular modems on control networks, standing remote desktop tools - removing these costs little and closes the paths attackers actually use.
3. Stand up the OT boundary firewall in monitor-then-enforce mode: log for a month, tighten to observed-legitimate flows, then flip to deny-by-default.
4. Build the DMZ services - historian replica, patch staging, remote access broker - and repoint business consumers at the replicas.
5. Separate authentication domains and unwind dual-homed hosts as the DMZ services make them unnecessary.
6. Institutionalize the review. Quarterly rule review, conduit inventory, and an owner for every exception. This step is the difference between a project and a posture - and it's the one a small team most needs to keep lightweight.

Frequently Asked Questions

Sources & Further Reading

• NIST SP 800-82 Rev. 3, Guide to Operational Technology (OT) Security - NIST
• ISA/IEC 62443 Series of Standards - International Society of Automation
• DarkSide Ransomware: Best Practices for Preventing Business Disruption (AA21-131A) - CISA & FBI