MQTT OT Security: Protecting Industrial Plants When Sending Data to the Cloud

MQTT OT security is the practice of getting data out of an industrial plant without creating a new way into it. This guide covers the network patterns that work, such as outbound-only connections, DMZ gateways and segmentation, plus credential hygiene and monitoring for plant data sent to a cloud broker. By the end you will have a reference design and a checklist you can discuss with both your OT and IT teams.

Why OT Networks Need a Different Approach

Operational technology (OT) networks run equipment that moves, heats, mixes and cuts. They differ from office IT in ways that shape every security decision:

• Availability comes first. A security control that stops production is often treated as a bigger risk than the threat it addresses.
• Long lifecycles. PLCs and HMIs stay in service for many years, often running firmware that cannot be patched quickly.
• Legacy protocols. Modbus, older Profinet and many serial protocols have no authentication at all.
• Physical consequences. A forged command can damage equipment or hurt people, not just leak data.

MQTT is well suited to this environment because it reverses the usual direction of traffic. Instead of a cloud application reaching into the plant to poll machines, a gateway inside the plant pushes data out. Done right, that means no inbound firewall rule into the OT network.

The Core Principle: Outbound-Only Connections

Every MQTT client opens a TCP connection to the broker, never the other way around. A plant gateway that publishes to a cloud broker therefore needs exactly one firewall rule: outbound TCP to the broker hostname on port 8883.

Outbound-only does not mean risk-free. The gateway still has a TCP session with the outside world, and if it subscribes to command topics, data can flow back in. The design question becomes: what does the gateway accept, and how does it validate it?

Reference Architecture

A layered design that fits most plants, loosely following the Purdue model levels:

1. Level 0–1: Field devices and PLCs. No internet route. Speak industrial protocols only.
2. Level 2: Supervisory network. HMIs and SCADA. Still no internet route.
3. Level 3/3.5: Industrial DMZ. The edge gateway lives here. It reads from Level 2 (for example via OPC UA or Modbus TCP) through a firewall that allows only those specific flows.
4. Level 4–5: Enterprise and cloud. The gateway publishes to the cloud MQTT broker over TLS. Dashboards, analytics and historians subscribe from here.

Single Gateway or DMZ Broker?

Two common variants work well:

• Gateway publishes directly to the cloud broker. Simplest option: one outbound connection, store-and-forward on the gateway for outages.
• Local DMZ broker bridges to the cloud. Machines or gateways publish to a broker in the DMZ, and a single bridge or relay client forwards selected topics outward. This adds a local buffer and a single point to inspect and filter traffic, at the cost of one more system to patch and monitor.

Either way, the plant floor never talks to the internet directly. For background on how a broker routes data, see what an MQTT broker does.

Segmentation Rules That Matter

Write firewall rules so that each one has a reason you can explain:

# OT firewall (between Level 2 and DMZ)
ALLOW  gateway-01  -> plc-line1:4840/tcp   (OPC UA read)
ALLOW  gateway-01  -> plc-line2:502/tcp    (Modbus TCP read)
DENY   any         -> any                   (default)

# Perimeter firewall (DMZ to internet)
ALLOW  gateway-01  -> YOUR_BROKER_HOST:8883/tcp   (MQTT over TLS)
ALLOW  gateway-01  -> ntp-server:123/udp          (time sync for TLS)
DENY   any         -> any                          (default)
DENY   internet    -> DMZ                          (no inbound)

Keep these points in mind:

• Prefer hostnames with egress filtering at a proxy or next-generation firewall when broker IP addresses can change.
• Allow port 8883 only. Plain MQTT on 1883 should never leave the plant.
• Accurate time matters: TLS certificate validation fails on gateways with a wrong clock.
• Log denied connections from the OT side; unexpected outbound attempts are an early warning sign.

Credential Hygiene for Gateways

Plant gateways often run unattended for years, so credentials must be handled carefully from day one.

1. One identity per gateway. If one gateway is compromised, revoke it without touching the others.
2. Separate identities for separate roles. A telemetry publisher and a command receiver should not share credentials.
3. Store secrets outside source code, in a protected configuration file or the operating system's secret store, readable only by the gateway service account.
4. Rotate on a schedule and on events, such as staff changes or suspected compromise. The guide to rotating MQTT credentials shows a low-downtime approach.
5. Never reuse plant credentials on test brokers. Use the public MQTT test broker only with throwaway client IDs and fake data.

On ConnectMQ, each broker gets generated credentials, and client IDs are bound to those credentials, so a leaked client ID on its own cannot be used to connect. Repeated failed logins lead to IP blocking, which limits password guessing against your gateways' accounts.

Handling Commands Safely

If the business case requires remote setpoints or recipe changes, treat the command path as a separate, higher-risk conduit:

• Use dedicated command topics and a separate subscriber identity.
• Validate every command on the gateway against an allow list: which tag, which range, which units.
• Require a response or acknowledgement topic, so operators see what actually happened. MQTT 5 response topics help here.
• Keep a local override and make sure equipment fails safe if the broker is unreachable.
• Never forward raw payloads to a PLC.

Many plants decide that the cloud path stays read-only and that writes happen only through local HMIs. That is a legitimate and common choice.

Monitoring and Availability

Security in OT includes availability. Plan for these situations:

• Broker or internet outage: the gateway buffers locally and resends with backoff when the connection returns. Message expiry stops stale data from being replayed hours later.
• Gateway failure: subscribe to $SYS/broker/connection/{clientId}/state on ConnectMQ or use a last will message so dashboards show the gateway as offline.
• Unusual traffic: a gateway that suddenly publishes ten times its normal rate, or connects from a new IP address, deserves investigation.
• Quota limits: MQTT 5 reason code 0x97 tells you a plan quota was exceeded, so you can distinguish that from network problems.

The ConnectMQ portal's dashboard, devices view by ISA-95 level and threshold alert rules help operations teams see this without building custom tools.

OT Security Checklist for MQTT

1. No inbound firewall rules into the OT network for MQTT.
2. The gateway sits in a DMZ and reads from PLCs through narrowly scoped rules.
3. Only TLS on port 8883 leaves the site, with server certificate validation and accurate time.
4. One unique, revocable identity per gateway and per role.
5. Command paths are separate, validated and fail-safe, or not present at all.
6. Gateways buffer during outages and reconnect with backoff.
7. Gateway connection state and message rates are monitored.
8. Responsibilities between plant, IT and broker provider are documented.

For the standards side of the same topic, read IEC 62443 and MQTT. The industrial IoT with MQTT guide covers data modelling, and MQTT security best practices covers general client hardening.

Connect Your Plant to ConnectMQ Securely

You can test this design on a single gateway in an afternoon. Create a private broker on the free Serverless plan at app.connectmq.com (no credit card required), open one outbound rule for port 8883, and publish your first ISA-95 topic over TLS. When you need isolation for production, a managed MQTT broker on a Dedicated or BYOC deployment keeps the same client configuration.

Frequently Asked Questions

Does MQTT require opening inbound ports into the plant?

No. MQTT clients connect outward to the broker, so a plant gateway only needs an outbound rule to port 8883. Commands, if any, travel back over that same connection.

Should PLCs connect to a cloud broker directly?

Generally not. Keeping PLCs on an isolated network and placing an edge gateway in a DMZ limits exposure and lets you control exactly what leaves the plant.

Is a VPN needed for MQTT from the plant to the cloud?

Usually not. MQTT over TLS with server certificate validation and strong client credentials provides an encrypted, authenticated channel without a VPN.

What happens to data when the internet connection drops?

A well-designed gateway buffers data locally and resends it after reconnecting with backoff. Message expiry can discard values that are no longer useful.