Industrial MQTT Broker: What to Demand (QoS, Retained, LWT, Sparkplug, Buffering)

The MQTT broker is the central piece of a connected plant's messaging: everything that produces data publishes to it and everything that consumes data subscribes to it. But not every deployment is fit for an industrial environment. An industrial MQTT broker must guarantee delivery with well-chosen QoS levels, keep the last known value with retained messages, detect client drops with LWT, speak Sparkplug B when a data contract is needed, rely on edge buffering to survive outages and close security with TLS, authentication and per-topic authorisation. This guide walks through each requirement and ends with a checklist.

The broker's role in the plant

MQTT is a publish-subscribe protocol: clients do not talk to each other, they talk to the broker. A gateway publishes a line's signals into a topic tree; the historian, the MES and the dashboards subscribe to the branches they care about. That decoupling is what makes the broker the backbone of an industrial data platform: adding a new consumer does not touch the producers, and vice versa.

Precisely because everything flows through it, the broker concentrates the requirements that a point-to-point architecture spreads around: delivery guarantees, client state, data contract, continuity through outages and security. Choosing and configuring the broker without thinking about these five fronts is the fastest way to build a demo that does not survive its first month in production. The choice between MQTT and other connectivity options is covered in OPC UA vs MQTT; here we take MQTT as decided and focus on demanding the right things from the broker.

QoS: what each level guarantees and which to use

MQTT defines three quality of service (QoS) levels that govern the delivery of each message between client and broker:

Level	Guarantee	Cost	Typical plant use
QoS 0	At most once; may be lost	Minimal	High-frequency telemetry where the next value supersedes the previous one
QoS 1	At least once; may be duplicated	Per-message acknowledgement	The default for process signals and events, with idempotent consumers
QoS 2	Exactly once	Double acknowledgement handshake	Messages where a duplicate has a real cost, such as orders or transactions

Two nuances separate theory from practice. First: the guarantee applies between client and broker on each leg, not end to end by itself; the effective level is also set by the consumer's subscription. Second: QoS 2 is not "the best": its per-message cost makes it a poor choice for bulk telemetry. The healthy combination in a plant is usually QoS 1 as the norm, with consumers prepared to discard duplicates, and QoS 0 reserved for loss-tolerant high-frequency streams.

Retained messages: the last known value

By default, a subscriber only receives what is published after it subscribes. If a dashboard connects at 10:00 and the temperature was published at 09:59, the dashboard sees nothing until the next publication. Retained messages solve this: the broker stores the last retained message of each topic and delivers it immediately to every new subscriber.

In a plant this matters more than it seems: machine states, current setpoints and slow-changing values should be published retained so that any consumer starting up, or reconnecting after an outage, gets a complete picture without waiting for the next cycle. The associated discipline is clearing stale retained messages (by publishing an empty retained message) when a device is decommissioned, or the topic tree accumulates ghosts of machines that no longer exist.

Last Will and Testament: knowing when a device drops

In a publish-subscribe system, silence is ambiguous: if a gateway stops publishing, is there simply no news, or has it dropped? The Last Will and Testament (LWT) mechanism resolves the ambiguity: on connecting, each client registers a will message with the broker; if the connection is lost without an orderly disconnect, the broker publishes it on the client's behalf.

The practical pattern is to publish a retained status message ("online") on startup and register the opposite status ("offline"), also retained, as the will. Any consumer then knows, at all times and without polling, which producers are alive, and an alert rule can flag a gateway drop within seconds. An industrial broker must support LWT without restrictions and the team must use it on every client: it is the difference between discovering an outage through a gap in the history or through a timely alert.

Sparkplug B: from free-form topics to a contract

MQTT imposes neither topic structure nor payload format: that freedom is its strength and its risk. With ten machines and three different integrators, freedom degenerates into a broker full of incompatible conventions. Sparkplug B is the specification that closes that gap for industrial environments: it defines the namespace structure, a binary payload format with typed metrics and, on top of LWT, a session state model with birth and death messages for every node and device.

The practical consequence is that any compatible consumer knows, without bilateral agreements, which metrics exist, what type they are and whether their source is online or the data is stale. Not every project needs Sparkplug from day one, but the chosen broker must support it without friction, because it is the natural path as the number of producers and consumers grows. The full namespace pattern is developed in the guide to unified namespace and MQTT Sparkplug B.

Buffering: what the broker cannot solve on its own

A frequent misunderstanding is worth undoing here: QoS guarantees protect messages in transit, not messages that were never sent. If the network between the gateway and the broker goes down for two hours, the broker can do nothing for the data generated in that interval: the responsibility lies with the publisher.

That is why a serious industrial deployment demands persistent store-and-forward at the edge: the gateway writes every value to local disk before publishing and resends the backlog, in order and with its source timestamp, when the connection returns. The broker's persistent sessions help in the other direction, queueing messages for temporarily disconnected subscribers, but they do not replace the publisher's buffer. Sizing that buffer (days of autonomy, not minutes) is covered in the guide to industrial edge with buffering and QoS.

Security: TLS, authentication and per-topic authorisation

The broker is the point through which all plant data flows, and that makes it the asset to protect. The non-negotiable minimums:

TLS on every connection. Transport encryption always, including inside the plant. Unencrypted MQTT traffic is readable and tamperable by anyone with access to the network.
Authentication of every client. No anonymous clients. Per-client credentials or, better, client certificates, so that every gateway and every application has its own revocable identity.
Per-topic authorisation. An authenticated client is not an almighty client: each identity should be able to publish and subscribe only to the branches that belong to it. A line 3 gateway has no business publishing on line 1 topics, and a read-only dashboard should not be able to publish at all.
Outbound connections from the plant. The secure pattern is for the edge to initiate the connection towards the broker, with no inbound ports opened in the OT network. The plant's exposure surface stays at zero.

These requirements are part of the same approach we develop in the guide to zero trust in industrial OT: per-device identity, least privilege and no implicit trust for being inside the network.

Checklist: what to demand from an industrial MQTT broker

Requirement	What to check
QoS 0, 1 and 2	Full support for all three levels and documented behaviour under load
Retained messages	Full support, including clearing stale retained messages
LWT	Per-client will, combinable with retained for online status
Persistent sessions	Message queueing for disconnected subscribers, with configurable limits
Sparkplug B	Verified compatibility with the specification's state messages and payloads
Security	TLS, per-client authentication and per-topic publish and subscribe ACLs
High availability	Redundancy or clustering option if the broker is a single point of failure for data
Observability	Metrics of the broker itself: connected clients, queues, messages per second
Edge complement	Persistent store-and-forward in the publishers; the broker does not do it for them

Frequently asked questions about industrial MQTT brokers

Which QoS level should I use for plant data?

As a general rule, QoS 1 with idempotent consumers: it guarantees the message arrives, accepting occasional duplicates the consumer discards. QoS 0 is for high-frequency telemetry where losing a value does not matter because the next one supersedes it, and QoS 2 for the few messages where a duplicate has a real cost.

Does the broker keep my data if the plant loses its network link?

Not the data generated during the outage: the broker can only manage messages that reach it. Continuity comes from persistent store-and-forward in the edge gateway, which writes every value to local disk and resends the backlog with its original timestamp when the connection returns. The broker complements this with persistent sessions for disconnected subscribers.

Do I need Sparkplug B from the start?

It is not mandatory to begin with, but it pays to choose a compatible broker and gateways from day one. With few clients, a well-governed namespace with agreed payloads is enough; as producers and consumers grow, Sparkplug provides the data contract and the state model that avoid bilateral agreements.

Can I use a generic MQTT broker in an industrial environment?

The protocol is the same, so technically yes; the difference lies in the requirements the environment imposes: LWT and retained messages used with discipline, per-topic ACLs, TLS on every connection, Sparkplug compatibility if the project grows and, above all, persistent buffering in the publishers. A well-configured generic broker with a well-designed edge passes; a default deployment does not.

If you are designing your plant's messaging, at Captia Connect we deploy this complete layer: multi-protocol acquisition with MQTT and OPC UA, persistent local buffering, normalisation at the source and secure connectivity towards the broker, as part of MQTT integration and of the architecture we describe in industrial data platform.