MQTT is the de facto transport for industrial IoT telemetry: lightweight publish/subscribe over TCP, ideal for the many-to-many data flows of plant-to-cloud and machine-to-machine communication. The broker — the message hub every client connects to — is the system's single point of truth and its single point of failure: broker deployment decisions (placement, security, capacity, persistence) decide whether the IoT data path is reliable and trustworthy. This article covers deploying MQTT brokers in industrial settings, with Sparkplug B considerations.
Broker Roles and Options
- Edge brokers — on the plant network (or inside a machine): collect from sensors/gateways locally, buffer during outages, forward to the cloud broker; the plant's data leaves only through the edge.
- Cloud brokers — the central hub: managed broker services (AWS IoT Core, Azure IoT Hub, EMQX/Mosquitto in the plant's cloud) aggregating many sites.
- Open-source brokers — Mosquitto (lightweight, standard) and EMQX/HiveMQ (clustered, enterprise features) run anywhere — the plant, a VM, or Kubernetes.
- Industrial gateways with built-in brokers — many IIoT gateways embed a broker for local pub/sub, which then forwards to the central broker.
The architecture decision mirrors the data architecture (see the IIoT platform and cloud integration articles): the broker placement is where data is buffered, secured, and controlled.
Deployment Design
- Broker placement per zone — the edge broker lives in the plant DMZ/edge zone (outbound only); the central broker lives where the consumers are. Never expose a broker directly to the internet without the full security stack.
- High availability — for critical flows: clustered brokers (EMQX/HiveMQ) or active/standby with client-side reconnect; the broker's availability must match the application's, and the plan includes what happens when the broker is down (edge buffering — see below).
- Capacity planning — connections, message rate, and payload size drive the broker's resources; sizing on averages fails at peaks (batch startups, firmware update floods). The broker's backpressure behavior (slow consumers) must be understood and configured.
- Persistence — QoS 1/2 with retained messages and session persistence require the broker to store state; enable persistence deliberately (disk-backed) where at-least-once delivery matters, and set the retention/expiry policies (message TTL, retained-message hygiene).
- Buffering at the edge — the edge gateway's store-and-forward queue is the resilience mechanism: disk-backed queues with size limits and replay-on-reconnect; without it, a cloud outage becomes data loss.
Security Hardening
- TLS everywhere — MQTT over TLS (port 8883), certificates validated on both sides; never plain MQTT on a network path that crosses any boundary. Certificate management follows the same discipline as OPC UA certificates (see that article).
- Authentication — per-client credentials (username/password or, better, client certificates); every device has its own identity — shared credentials are an incident waiting.
- Authorization on topics — the broker's ACLs define who may publish/subscribe to which topic tree; the ACL model mirrors the data ownership (device publishes to its own namespace only; applications subscribe per role).
- Topic discipline — a governed topic structure (Sparkplug B's namespace, or a plant-standard hierarchy); ungoverned topics become ungovernable data. Topic names are case-sensitive, structured, and versioned.
- Rate and payload limits — broker-side limits (max message size, max connections per client, publish rate) prevent one misconfigured device from flooding the system; the broker's logging and monitoring are enabled and fed to the plant's monitoring.
Sparkplug B Considerations
Sparkplug B (see the MQTT/Sparkplug article) adds structure: birth/death certificates (state awareness), templates, and a defined topic layout. Deployment notes: the broker must be configured for the Sparkplug topic namespace (ACLs), the session expiry must be handled carefully (Sparkplug assumes session awareness), and the state management (which devices are online) depends on the broker's retained messages — retention policies are not optional with Sparkplug, they are the protocol.
Operations
- Monitoring: connections, message rates, queue depths, and TLS errors — the broker is a monitored asset with alarms (see the OT monitoring article for the pattern).
- Backup: broker configuration, ACLs, and certificates are backed up and restorable; message data follows the data retention policy.
- Change control: topic structure changes and ACL changes are change-managed events; version the topic schema with the applications that consume it.
- Testing: reconnect storms, slow consumers, and broker restarts are tested with the real clients before production reliance.
Summary
MQTT broker deployment is an architecture and security decision: place brokers per zone (edge buffering, cloud aggregation), plan capacity and persistence honestly, secure with TLS and per-client identity plus topic ACLs, govern the topic structure, and operate with monitoring and change control. The broker is the message spine of the IoT data path — deploy it like the critical infrastructure it is.