MQTT in Industrial IoT: Architecture, QoS and Security

Publish/subscribe: how MQTT works

MQTT is a lightweight messaging protocol on top of TCP, designed for networks with limited bandwidth, unstable links or high latency. That design is the main reason it has become one of the most widely used protocols in industrial IoT, from streaming sensor data on a production line to sending equipment status from mining edge gateways to a central platform.

In MQTT, senders and receivers never talk to each other directly. Every client connects only to a broker:

• A publisher sends a message to a topic, for example the temperature of a motor.
• A subscriber registers interest in one or more topics.
• The broker receives messages and delivers them to every matching subscriber.

This decoupling has practical consequences. Devices do not need to know who consumes their data. New consumers such as a dashboard, a time-series database or an alarm service can be added without touching the devices. Connections are opened outbound from the device, which simplifies firewall rules. The fixed header overhead is only a few bytes, which matters on cellular or satellite links.

Designing topic hierarchies

Topics are hierarchical strings separated by /. Designing them is an architectural decision made early, because changing the scheme later means touching every device and every consumer. A common pattern follows the physical or organizational structure of the site:

site/area/line/asset/telemetry/temperature

Subscribers can use two wildcards: + matches exactly one level and # matches all remaining levels. For example, site/area/+/+/alarms/# receives all alarms from every line in one area.

Practical recommendations

• Use lowercase, no spaces, no special characters, and do not start topics with a leading /.
• Keep telemetry, state, alarms and commands in separate branches so that permissions and QoS can be set per branch.
• Include a unique device identifier in the topic so access control lists (ACLs) can be written against it.
• Document the payload format. JSON is readable; binary formats such as Protobuf suit constrained links.
• Avoid putting volatile values or timestamps into the topic itself; they belong in the payload.

Delivery guarantees and session state

QoS levels

MQTT defines three Quality of Service levels. An important detail: QoS applies per hop, once between publisher and broker and once between broker and each subscriber. The effective guarantee is the lower of the two.

Level	Guarantee	Mechanism	Typical use
QoS 0	At most once	Fire and forget, no acknowledgment	High-frequency telemetry where losing a sample is acceptable
QoS 1	At least once	PUBLISH and PUBACK; duplicates possible	Events, alarms and commands with idempotent handling
QoS 2	Exactly once	Four-step handshake	Cases where duplicates are costly and extra overhead is acceptable

Retained messages

The broker stores the last retained message per topic and delivers it immediately to new subscribers. This is useful for state values such as online/offline or the latest setpoint. For continuous telemetry streams it is usually unnecessary.

Last Will and Testament

When connecting, a client can register a "last will" message. If the connection drops ungracefully and the keep-alive interval expires, the broker publishes this message on the client's behalf. Combining a last will with a retained status topic is a simple and reliable way to monitor the availability of devices and gateways.

Persistent sessions

With a persistent session, the broker keeps a disconnected client's subscriptions and its undelivered QoS 1 and 2 messages. This helps gateways on unreliable links, but queue size and retention time must be bounded so the broker's memory is protected. Local buffering on the edge gateway is an important complement.

MQTT 5 features and security

What MQTT 5 adds

• Reason codes on acknowledgments for clearer error diagnosis.
• User properties to attach metadata such as schema version or unit without changing the payload.
• Shared subscriptions to load-balance messages across several instances of a processing service.
• Session expiry and message expiry to control how long sessions and messages live.
• Response topic and correlation data for request/response patterns, for example in command handling.
• Topic aliases and receive maximum to reduce traffic and provide flow control.

When choosing devices, gateways and brokers, check that all components support MQTT 5 if you plan to rely on these features; otherwise the system falls back to MQTT 3.1.1 behavior.

TLS and authentication

MQTT itself does not encrypt anything. In industrial environments the following baseline is advisable:

• Use TLS (commonly port 8883) and disable the unencrypted port 1883 on any untrusted network.
• Authenticate devices with client certificates (mutual TLS) or unique per-device credentials, never a shared password.
• Enforce ACLs so each device can only publish to its own topics and only read its own commands.
• Segment OT and IT networks and place the broker in a controlled zone, such as an industrial DMZ, following the zone and conduit approach of IEC 62443.

Sparkplug B and comparison with OPC UA and HTTP

MQTT defines how messages are transported, not what topics or payloads look like. The Sparkplug B specification, maintained at the Eclipse Foundation, fills this gap for industrial use: a fixed topic namespace starting with spBv1.0, Protobuf-encoded payloads, and birth and death messages (NBIRTH, NDEATH, DBIRTH, DDEATH) that tell the host application which devices are online and which metrics they provide. Sparkplug is most valuable when several SCADA systems or platforms must understand each other's data without custom agreements.

Criterion	MQTT	OPC UA	HTTP/REST
Communication pattern	Publish/subscribe via broker	Client/server, plus PubSub	Request/response
Data model	Free-form; structured with Sparkplug	Rich, standardized information model	Free-form, usually JSON
Overhead	Low	Medium to high	Higher per message
Real-time data	Yes, push-based	Yes, via subscriptions and monitored items	Requires polling or webhooks
Typical position	Edge to platform and cloud	Machine and controller level	Integration with IT systems

In practice, a common pattern is an edge gateway that reads PLCs via OPC UA or Modbus and forwards data to the platform via MQTT, while HTTP APIs handle integration with ERP and business systems.

Choosing and operating a broker

There are many options. The right choice depends on scale, clustering requirements, support model and the team's skills:

• Eclipse Mosquitto: lightweight open-source broker, well suited to the edge, labs and small to medium deployments.
• EMQX: distributed broker with clustering, a rule engine and database integrations.
• HiveMQ: broker focused on enterprise environments, with commercial editions and extensions.
• ThingsBoard: built-in MQTT transport for connecting devices directly to the platform using its own topic API (for example v1/devices/me/telemetry). It is not a general-purpose broker for arbitrary exchange between systems.

Whatever the product, plan these points from the start: monitoring of the broker itself (connections, message rates, queue lengths), configuration backups, a certificate renewal process, and load testing with realistic device counts and publish rates before going live.

Conclusion and practical next steps

MQTT is not an architecture on its own; it is the transport backbone inside one. Success depends on a deliberate topic design, the right QoS per data type, security from day one and a clearly documented data format. If you are designing or reviewing the data architecture for a factory, mine or industrial site, the pages on industrial IoT consulting and industrial monitoring describe the approach, and you can discuss your specific situation via the contact page.