# MQTT Broker Deployment and Hardening > 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… - Canonical URL: https://wiki.aspotomasyon.com/article/mqtt-broker-deployment - Publisher: ASP OTOMASYON A.Ş. (ASP OTOMASYON Wiki) - Category: Modern Connectivity - Published: 2026-08-11 · Updated: 2026-09-13 - Reading time: 4 min · Language: English 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. ![A generic industrial messaging path. A network or broker acknowledgment is not necessarily confirmation that a downstream business action succeeded.](https://wiki.aspotomasyon.com/assets/diagrams/modern-connectivity-context.svg) *A generic industrial messaging path. A network or broker acknowledgment is not necessarily confirmation that a downstream business action succeeded.* ## 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 1. **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. 2. **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). 3. **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. 4. **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). 5. **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. ## Apply this to your project - Specify payload structure, units, identity, time semantics, access permissions, and protocol versions. - Test backlog growth, connection loss, duplicate delivery, and restart behavior at the consuming application. - Document how operators see failures and how the system distinguishes replayed data from current process state. [Follow an ASP project guide](https://wiki.aspotomasyon.com/guides) to connect the fundamentals with implementation and acceptance. ![Engineering review sequence: Contract → Connect → Interrupt → Reconcile. Keep the recorded evidence with the accepted configuration.](https://wiki.aspotomasyon.com/assets/diagrams/modern-connectivity-review.svg) *Engineering review sequence: Contract → Connect → Interrupt → Reconcile. Keep the recorded evidence with the accepted configuration.* ## Primary references and further reading Use the original specifications and product documentation for implementation details. The examples in this guide are illustrative engineering scenarios, not published project results. - [OASIS — MQTT 5.0 specification](https://docs.oasis-open.org/mqtt/mqtt/v5.0/mqtt-v5.0.html) - [Modbus Organization — Protocol specifications](https://www.modbus.org/modbus-specifications) - [Eclipse Foundation — Sparkplug 3.0 specification](https://sparkplug.eclipse.org/specification/version/3.0/) --- Cite the canonical article: https://wiki.aspotomasyon.com/article/mqtt-broker-deployment (MQTT Broker Deployment and Hardening, ASP OTOMASYON, updated 2026-09-13).