An MQTT DMZ is the network zone where plant data leaves the operational technology (OT) network on its way to cloud and enterprise systems, without letting anything from the outside reach back in. In this guide you will learn why MQTT fits a DMZ so well, the three placement patterns that work in practice, the exact firewall rules to request, and a working bridge configuration that forwards OT data to a cloud broker over TLS.
Why MQTT Suits an Industrial DMZ
Most industrial security architectures follow some variant of the Purdue model or IEC 62443 zones and conduits. Level 0 to 2 hold sensors, PLCs and HMIs, Level 3 holds site operations such as SCADA and historians, and between Level 3 and the enterprise network (Level 4 and up) sits an industrial DMZ, often called Level 3.5. The rule of the DMZ is simple: no traffic passes straight through it. Every flow terminates in the DMZ and a new flow starts from there.
Classic integration protocols struggle with that rule. Polling protocols such as OPC DA, Modbus TCP or a historian query interface expect the consumer to open a connection to the producer. That means an inbound connection into the OT network, which is exactly what the security team wants to avoid.
MQTT inverts the direction. Every participant is a client that connects out to a broker. A gateway on the OT side opens an outbound TCP connection, authenticates, and publishes. Consumers in IT or the cloud also connect out to the broker and subscribe. Nobody ever needs to open a listening port on the plant floor. Once you understand what an MQTT broker does as the meeting point of these outbound connections, the DMZ design becomes much easier to reason about.
Three MQTT DMZ Placement Patterns
There is no single correct design. The right pattern depends on how strict your zone policy is and how many sites you have.
| Pattern | Where the broker lives | Flow from OT | Best for |
|---|---|---|---|
| A. Direct outbound | Cloud only | OT gateway connects out through the firewall to the cloud broker | Small sites, pilots, sites without a formal DMZ |
| B. DMZ bridge broker | Local broker in the DMZ, bridged to the cloud | OT gateway connects to the DMZ broker; DMZ broker connects out to the cloud | Sites with a strict "no flow crosses the DMZ" rule |
| C. DMZ gateway | Gateway software in the DMZ, cloud broker | OT gateway or OPC UA server is read by a DMZ gateway, which publishes to the cloud | Plants that cannot install anything at Level 2 or 3 |
Pattern A: outbound-only to a cloud broker
The gateway sits at Level 3 and opens a TLS connection on port 8883 directly to a cloud MQTT broker. The firewall allows one outbound destination and one port. Return traffic flows only on that established session. This pattern is fast to deploy and perfectly acceptable for many plants, but it technically lets a session cross the DMZ, which some policies forbid.
Pattern B: a bridge broker in the DMZ
A small broker such as Mosquitto runs on a hardened host in the DMZ. OT gateways connect to it from below, and the DMZ broker opens its own outbound bridge connection to the cloud. Two separate sessions, two separate credential sets, and the DMZ host is the only machine that ever talks to the internet. If the cloud link drops, the bridge queues QoS 1 messages locally, which pairs naturally with store-and-forward MQTT on the gateways.
Pattern C: a protocol gateway in the DMZ
Sometimes nothing new can be installed inside the OT zone. In that case a gateway in the DMZ reads an existing interface, for example an OPC UA server exposed to the DMZ through a narrow rule, and publishes MQTT upward. It is the least elegant pattern because the DMZ now initiates a connection into OT, but it still keeps the cloud completely isolated from the plant. Our IIoT edge gateway guide covers how to choose that gateway.
Firewall Rules for an MQTT DMZ
Whatever pattern you choose, write the rules down before the change request. Firewall teams approve precise rules faster than vague ones.
| Rule | Source | Destination | Port | Direction |
|---|---|---|---|---|
| 1 | OT gateway (Level 3) | DMZ broker | TCP 8883 (or 1883 inside a trusted segment) | OT to DMZ |
| 2 | DMZ broker | Cloud broker hostname | TCP 8883 | DMZ to internet |
| 3 | IT consumers | Cloud broker hostname | TCP 8883 or 8084 (WSS) | Enterprise to internet |
| 4 | Anything | OT zone | Any | Deny |
| 5 | Internet | DMZ broker | Any | Deny |
A few practical notes:
- Use the broker hostname, not an IP address, on the outbound rule, or use an FQDN object if your firewall supports it. Cloud IPs can change.
- Allow DNS resolution for the DMZ host, either to an internal resolver or a specific upstream.
- Keep port 1883 plaintext off the internet entirely. Use 8883 with TLS for anything leaving the site.
- If a TLS-inspecting proxy sits in the path, exclude the broker hostname. Inspection breaks certificate validation and long-lived MQTT sessions.
- Long idle timeouts matter. Some firewalls drop idle TCP sessions after a few minutes, so set the MQTT keepalive below the firewall's idle timeout, for example 60 seconds.
Example: a Mosquitto Bridge from the DMZ to a Cloud Broker
The following configuration implements Pattern B. The DMZ broker listens only on its OT-facing interface and bridges selected topics out to a ConnectMQ broker over TLS. Replace the credentials with the username, password and client ID generated in the portal.
# /etc/mosquitto/conf.d/dmz.conf
# Listen only on the interface facing the OT zone
listener 8883 10.20.0.5
cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/dmz-broker.crt
keyfile /etc/mosquitto/certs/dmz-broker.key
allow_anonymous false
password_file /etc/mosquitto/passwd
# Outbound bridge to the cloud broker
connection connectmq-cloud
address broker.connectmq.com:8883
bridge_protocol_version mqttv311
bridge_capath /etc/ssl/certs
bridge_insecure false
remote_clientid YOUR_CLIENT_ID
remote_username YOUR_USERNAME
remote_password YOUR_PASSWORD
cleansession false
try_private false
keepalive_interval 60
restart_timeout 10 120
# Forward only plant telemetry, upward only
topic factory1/# out 1 "" connectmq/
The topic line is where the DMZ policy is enforced in software: out means messages only flow from the DMZ broker to the cloud, never back down. A local topic factory1/line1/cnc1/telemetry arrives in the cloud as connectmq/factory1/line1/cnc1/telemetry. Use try_private false because the remote side is not another Mosquitto instance, and keep bridge_insecure false so the Let's Encrypt certificate of the cloud endpoint is validated against the system CA store.
Test the path from the DMZ host before involving any PLC data:
# On the DMZ host: publish a local test message
mosquitto_pub -h 10.20.0.5 -p 8883 --cafile /etc/mosquitto/certs/ca.crt \
-u gateway01 -P 'local-secret' -i dmz-test-01 \
-t factory1/test/hello -m '{"status":"ok"}' -q 1
# From any machine with access to the cloud broker: confirm it arrived
mosquitto_sub -h broker.connectmq.com -p 8883 --capath /etc/ssl/certs \
-u YOUR_USERNAME -P YOUR_PASSWORD -i YOUR_CLIENT_ID-reader \
-t 'connectmq/factory1/#' -v
Note that ConnectMQ binds client IDs to issued credentials, so the second client needs its own credential set from the portal rather than a made-up ID. For experiments before you have credentials, you can point the bridge at the public MQTT test broker on port 1883 with a unique prefix such as connectmq/demo/<random-id>/, but never send real plant data to a public area.
Should Commands Ever Flow Down?
Telemetry going up is the easy part. The harder question is whether anything should come back down: setpoint changes, recipe downloads, acknowledgements. A good default for a first deployment is no. Keep the bridge out only and let operators change setpoints through the existing HMI or SCADA.
If you do need downlink, design it explicitly:
- Bridge a single, narrow command topic
in, for exampleconnectmq/factory1/line1/cmd/+, never a wildcard over the whole tree. - Let a gateway at Level 3 validate every command against an allow list of tags and value ranges before writing to the PLC.
- Require a response topic and correlation data (an MQTT 5 feature) so every command produces a logged acknowledgement.
- Keep the PLC in charge of safety interlocks. A cloud command should request a change, not bypass logic.
Common MQTT DMZ Mistakes
Running the DMZ broker with anonymous access. The DMZ is still a shared zone. Require usernames and passwords, and ideally client certificates, on the OT-facing listener.
Bridging # in both directions. It is the fastest way to turn a carefully designed DMZ into a flat network at the application layer. Bridge only the subtrees you need, and only in the direction you need.
Forgetting the session. With cleansession false the cloud side keeps the bridge's subscriptions and queued QoS 1 messages across short drops. With a clean session, everything published during a reconnect window can be lost.
Ignoring broker-side limits. A burst of historical data after an outage can exceed per-client quotas. Rate-limit the replay on the gateway and read the reason codes the broker returns.
Where a Managed Broker Fits
In both Pattern A and Pattern B, the cloud endpoint is a component you would otherwise have to build, expose, patch and monitor yourself. Using a managed MQTT broker moves that internet-facing surface out of your data centre. ConnectMQ provides TLS on 8883, multi-tenant isolation, flood protection and IP blocking after repeated failed logins, so the only thing your DMZ needs is one outbound rule. For organisations that want the broker inside their own cloud account, it also offers a BYOC option managed on your behalf.
For the bigger picture of how the DMZ fits with gateways, Sparkplug B and a Unified Namespace, see our complete guide to Industrial IoT with MQTT. If your sites connect over mobile networks rather than a plant firewall, read about MQTT over cellular as well.
Get Started with ConnectMQ
Create a free Serverless broker at app.connectmq.com, no credit card required. You get a generated username, password and client ID in minutes, which is all you need to point a DMZ bridge at the cloud and watch your plant topics arrive in the live topic explorer. When you outgrow the free tier, the paid Serverless, Dedicated and BYOC plans let you scale without redesigning the DMZ.
Frequently Asked Questions
Does MQTT require inbound firewall ports into the OT network?
No. Every MQTT participant is a client that connects out to a broker, so the OT network only needs an outbound rule to the DMZ broker or cloud broker. Nothing on the internet initiates a connection into the plant.
Should I use port 1883 or 8883 for an MQTT DMZ?
Use 8883 with TLS for every connection that leaves the site or crosses a zone boundary. Plaintext 1883 is acceptable only inside a single trusted segment, and even there TLS is recommended.
Do I need a broker inside the DMZ?
Not always. A direct outbound connection from a Level 3 gateway to a cloud broker is often acceptable. A DMZ bridge broker is the better choice when your policy forbids any session from crossing the DMZ or when you want local buffering.
Can cloud applications send commands back to PLCs through the DMZ?
They can, but only through a narrow, explicitly bridged command topic and a gateway that validates each command before writing to the PLC. Many plants start with upward-only telemetry and add downlink later.
