What to Look for in an Industrial MQTT Broker

An industrial MQTT broker sits at the centre of your plant data: every gateway publishes into it and every SCADA, MES, historian and dashboard reads from it. In this guide you will learn which capabilities separate a broker that survives the factory floor from one that merely passes protocol tests, and you will run a short Python script that checks the most important behaviours against any broker you are evaluating.

Why Industrial Use Changes the Requirements

Any compliant broker can route a message from a publisher to a subscriber. In a consumer IoT app, that is often enough. In a plant, the broker carries more than messages. It carries state: which machines are online, the current value of every tag, and whether a reading is fresh or stale. Operators make decisions from that state, and in some architectures SCADA systems drive alarms from it.

Industrial traffic also looks different. Thousands of tags change at uneven rates, a whole line can reconnect at once after a network blip, and payloads may be Sparkplug B protobuf rather than readable JSON. Clients live for years on gateways that nobody wants to touch. A broker that is fine for a hobby project can struggle under these conditions. If you are new to the role of the broker itself, start with what an MQTT broker is.

Core Capabilities of an Industrial MQTT Broker

Sparkplug awareness

Sparkplug B defines topic structure, birth and death certificates and a protobuf payload for industrial MQTT. Strictly speaking the broker does not need to understand Sparkplug: it is a client-side specification, and any MQTT 3.1.1 broker that supports retained messages, QoS and wills can carry it. In practice, though, a broker that can decode Sparkplug payloads saves hours. During commissioning you want to see Temperature = 72.4 rather than a block of binary. Read our guide to the Sparkplug B payload to understand what is inside.

An even more useful step is republishing. Sparkplug topics such as spBv1.0/factory1/DDATA/line1/cnc1 are compact but not friendly to IT consumers. A broker that can republish those metrics into ISA-95 topics such as connectmq/factory1/production/line1/cnc1/telemetry lets Sparkplug-native SCADA and JSON-oriented business apps use the same data. The relationship between the two models is covered in Sparkplug B and the Unified Namespace.

Retained state and sessions

A Unified Namespace only works if a dashboard that starts at 9:00 can see the state of every machine at 9:00, not after each machine next changes. That is what retained messages provide. Persistent sessions with a sensible session expiry protect against the other common failure: a gateway reconnecting after a short network drop and missing everything published to its subscriptions in between. In Sparkplug systems, the primary host application relies on these mechanisms together with death certificates to track edge node state.

Security that matches OT reality

Gateways should authenticate with their own credentials, connect over TLS, and be blocked if someone hammers the login with wrong passwords. Client IDs bound to credentials prevent one device from impersonating another or kicking it off by reusing its ID. The broker should also limit how much a single client can publish, so a misconfigured gateway publishing a tag every millisecond cannot degrade service for the rest of the plant.

Visibility for the people commissioning the system

The most underrated broker capability is a good window into it. When a controls engineer connects a new gateway, the first question is always "is the data arriving, and is it in the right place?" A live topic explorer, a view of connected clients and a connection-state topic answer that in seconds. Threshold alerts turn the broker from a pipe into a basic monitoring tool for values such as temperature limits or gateway health.

Uptime and the operations model

Ask who patches the broker, who renews certificates, who watches disk and memory, and who is called at 3 a.m. Self-hosting gives full control but makes the plant team responsible for an internet-facing server. A fully managed MQTT service shifts that work to the provider. Whatever you choose, plan how clients behave during a broker restart: reconnect with backoff, resume sessions, and re-publish births or retained state where needed.

Test Any Industrial MQTT Broker Yourself

Feature lists are easy to write. This MQTT 5 script checks four behaviours that matter in plants: retained delivery, session resumption, last will, and reason codes. Run it against the public test broker first, then against any broker you are evaluating.

import time
import uuid
import paho.mqtt.client as mqtt
from paho.mqtt.properties import Properties
from paho.mqtt.packettypes import PacketTypes

HOST, PORT = "broker.connectmq.com", 1883
BASE = f"connectmq/demo/{uuid.uuid4().hex[:8]}/plant1/line1"

def make_client(cid):
    return mqtt.Client(mqtt.CallbackAPIVersion.VERSION2,
                       client_id=cid, protocol=mqtt.MQTTv5)

def session_props(seconds):
    p = Properties(PacketTypes.CONNECT)
    p.SessionExpiryInterval = seconds
    return p

received = []

def on_message(client, userdata, msg):
    received.append((msg.topic, msg.payload.decode(), msg.retain))

# 1. Gateway publishes retained state and registers a last will
gw = make_client("gw-" + uuid.uuid4().hex[:6])
gw.will_set(f"{BASE}/gw1/status", "OFFLINE", qos=1, retain=True)
gw.connect(HOST, PORT, keepalive=5)
gw.loop_start()
gw.publish(f"{BASE}/gw1/status", "ONLINE", qos=1, retain=True)
gw.publish(f"{BASE}/cnc1/state", "RUNNING", qos=1, retain=True).wait_for_publish()

# 2. Late subscriber with a persistent session gets retained state immediately
sub_id = "scada-" + uuid.uuid4().hex[:6]
sub = make_client(sub_id)
sub.on_message = on_message
sub.connect(HOST, PORT, clean_start=False, properties=session_props(300))
sub.loop_start()
sub.subscribe(f"{BASE}/#", qos=1)
time.sleep(2)
print("Retained on subscribe:", received)

# 3. Subscriber drops, gateway publishes, subscriber resumes its session
sub.disconnect(); sub.loop_stop()
gw.publish(f"{BASE}/cnc1/state", "IDLE", qos=1).wait_for_publish()
received.clear()
sub = make_client(sub_id)
sub.on_message = on_message
sub.connect(HOST, PORT, clean_start=False, properties=session_props(300))
sub.loop_start()
time.sleep(2)
print("Delivered after resume:", received)

# 4. Simulate a gateway crash: stop the network loop without DISCONNECT
received.clear()
gw.loop_stop()
gw.socket().close()
time.sleep(10)  # wait past 1.5 x keepalive
print("Last will:", received)
sub.disconnect()

Expected output: the retained ONLINE and RUNNING values on subscribe, the IDLE change delivered after the session resumes even though it was published while the subscriber was away, and OFFLINE arriving once the broker notices the gateway has gone. Remember the public broker is readable by everyone and has deliberate limits (64 KB messages, 10 messages per second per client, session expiry up to 30 minutes), so run load tests only against your own broker.

Evaluation Checklist

1. Run the script above against the candidate broker with TLS on port 8883.
2. Publish real Sparkplug B traffic from a simulator and check whether you can read it in the broker tooling.
3. Reconnect 50 clients at once and watch for rejected connections or slow CONNACKs.
4. Publish too fast on purpose and check which reason code you get back, for example 0x97 (quota exceeded) in MQTT 5.
5. Try five wrong passwords in a row and confirm the broker reacts.
6. Ask who operates the broker and how certificate renewal works.

For a broader, non-industrial comparison, see how to choose an IoT MQTT broker.

How ConnectMQ Approaches Industrial Use

ConnectMQ is a managed broker built with these requirements in mind. It supports MQTT 3.1.1 and 5.0 over TCP, TLS, WebSocket and secure WebSocket, retained messages, session expiry and the full MQTT 5 reason codes. It detects ISA-95 and Unified Namespace topics, decodes Sparkplug B (protobuf and JSON) and republishes Sparkplug metrics into ISA-95 topics. Each broker exposes connection state at $SYS/broker/connection/{clientId}/state, and the portal adds a live topic explorer, a devices view by ISA-95 level and threshold alert rules. Multi-tenant isolation, per-plan quotas, flood protection and IP blocking after repeated failed logins protect each tenant. Plans range from free Serverless to Dedicated clusters, BYOC in your own cloud account and Self Managed Enterprise. For the hosting trade-offs in general, read our cloud MQTT broker guide; for the bigger industrial picture, see Industrial IoT with MQTT.

Get Started with ConnectMQ

Create a free Serverless broker at app.connectmq.com, no credit card required. Point the test script and a Sparkplug simulator at it, and see your plant data decoded and organised by ISA-95 level in the ConnectMQ portal within minutes.

Frequently Asked Questions

Does an industrial MQTT broker need to support Sparkplug B?

Sparkplug B works on any compliant broker with retained messages, QoS and last will. A broker that also decodes Sparkplug payloads makes commissioning and troubleshooting much easier.

Is MQTT 5 required for industrial use?

No, Sparkplug B and many gateways use MQTT 3.1.1. MQTT 5 adds useful features such as session expiry, reason codes and shared subscriptions, so a broker should support both versions.

Should I self-host or use a managed industrial MQTT broker?

Self-hosting gives full control but makes your team responsible for patching, certificates and monitoring. A managed broker removes that work, and options like BYOC keep the broker in your own cloud account.

How do I know if a gateway has gone offline?

Configure a retained last will message such as OFFLINE on a status topic. The broker publishes it automatically when the gateway disconnects without a clean DISCONNECT.