MQTT

What is MQTT?

MQTT is a lightweight, open publish/subscribe messaging protocol that lets devices exchange messages through a central broker over networks with limited bandwidth, high latency or unreliable connections. A sensor, PLC or gateway publishes data to a topic, and every application subscribed to that topic receives the message, without sender and receiver needing to know about each other. MQTT has become one of the leading protocols of the Industrial Internet of Things (IIoT) and connects SCADA, MES, edge and cloud in modern OT architectures.

🕰️ Where does MQTT come from?

MQTT was developed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now Eurotech) to monitor oil pipelines through SCADA links over satellite. Those links were expensive, slow and unreliable, and the field equipment often ran on batteries. This explains the design goals that still define MQTT: minimal overhead, low processing requirements and tolerance of dropped connections. As a result, an MQTT client also runs on small embedded systems and field devices, which made it a natural fit for telemetry.

The name originally came from MQ Telemetry Transport, after IBM’s MQSeries product line. The widely used expansion Message Queuing Telemetry Transport is misleading: MQTT does not use message queues but publish/subscribe. Since its standardisation at OASIS, MQTT is simply the name of the protocol and no longer an acronym.

🧠 How does the MQTT publish/subscribe model work?

Instead of a system querying every device periodically (polling, as with Modbus TCP), each device sends a message itself as soon as something changes. This subscribe pattern has three roles:

• Publisher - a client that posts messages to a topic, for example an edge device with temperature readings
• Subscriber - a client that subscribes to one or more topics, such as a historian or dashboard
• Broker - the central server that receives all messages, filters them by topic and forwards them to the right subscribers; well-known brokers are Mosquitto, HiveMQ and EMQX

Every client can both publish and subscribe. The broker decouples the parties in space (they do not know each other’s address) and in time (a subscriber need not be online at the same moment if the session is persistent). MQTT normally runs over TCP/IP, optionally via WebSockets; the fixed header is as small as 2 bytes and a message can be up to about 256 MB. For networks without TCP there is a variant called MQTT-SN.

Topics and wildcards

Topics are hierarchical text paths separated by /, for example plant/hall2/line3/oven1/temperature. Subscribers can use two wildcards:

• + - a single level: plant/+/line3/# captures line 3 in every hall
• # - all levels below, only at the end: plant/hall2/#

Topics starting with $, such as $SYS/ for broker statistics, are not matched by wildcards at the first level.

🔧 Which QoS levels and features does MQTT offer?

MQTT lets you choose per message how much delivery assurance you need. Higher QoS means more message traffic and more delay.

Besides QoS, four features matter for industrial use:

• Retained messages - the broker stores the last message on a topic and sends it immediately to every new subscriber, so a dashboard shows the current value straight away
• Last Will and Testament - when connecting, a client registers a will message that the broker publishes if the client disconnects unexpectedly
• Keep alive - client and broker use PINGREQ/PINGRESP to check whether the connection is still alive
• Persistent sessions - the broker remembers subscriptions and stores QoS 1/2 messages for a temporarily offline client (in MQTT 5 via Clean Start and Session Expiry Interval)

🆕 What is new in MQTT 5.0?

MQTT 5.0 adds features that mainly help large and industrial installations, while the basic model stays the same:

• Reason codes - every acknowledgement reports why something succeeded or failed
• Shared subscriptions - several clients share the messages of one topic for load balancing
• Message and session expiry - messages and sessions expire after a set time
• Topic aliases - long topic names are replaced by a short number to save bandwidth
• User properties - custom metadata as key-value pairs in the header
• Request/response and enhanced authentication - including challenge-response authentication

Much industrial software still supports only 3.1.1; brokers such as Mosquitto, HiveMQ and EMQX can serve both versions at the same time.

🏭 How is MQTT used in OT and IIoT?

Sparkplug B and the Unified Namespace

MQTT does not prescribe what topics and payloads look like, so every project invents its own structure. MQTT Sparkplug B, maintained by the Eclipse Foundation and international standard ISO/IEC 20237 since 2023, standardises this: a fixed topic structure (spBv1.0/group/message_type/edge_node/device), payloads in Google Protocol Buffers, birth and death messages (NBIRTH, NDEATH, DBIRTH, DDEATH) and report by exception. The NDEATH message is registered as the Last Will, so SCADA sees immediately when an edge node goes offline.

In an event-driven architecture, new clients can join easily without changing existing connections. A Unified Namespace (UNS), a concept popularised around 2020 by Walker Reynolds, uses an MQTT broker as the central, current source of data for the whole organisation. Its topics usually follow the ISA-95 hierarchy (enterprise/site/area/line/cell), so that MES, ERP and analytics share the same structure.

🔄 What is the difference between MQTT, OPC UA and AMQP?

In practice they complement each other. OPC UA PubSub can even use MQTT as a transport, and many architectures read machines via OPC UA and then publish the data onwards via MQTT. For high-volume streams into IT, brokers are often bridged to Apache Kafka; for very constrained devices CoAP is an alternative.

🔐 How do you secure MQTT in OT environments?

MQTT itself has little built-in security: authentication is optional and traffic on port 1883 is unencrypted. Search engines such as Shodan index hundreds of thousands of brokers exposed to the internet, often without a password, allowing anyone to eavesdrop or even publish commands. Secure MQTT with these steps:

1. Always encrypt - use TLS on port 8883 and disable port 1883 outside test environments; encryption also protects the credentials in the CONNECT message.
2. Authenticate every client - with username and password, or preferably with X.509 client certificates (mutual TLS) and proper certificate management; disable anonymous access.
3. Authorise per topic - define in ACLs which client may publish or subscribe to which topics, following least privilege. A sensor may only write to its own topic and must never read #.
4. Place the broker carefully - put the broker in its own zone or in the IDMZ according to the Purdue Model and the zones and conduits model, shielded by a firewall and VLANs. Let OT clients connect outbound so that no inbound ports are needed.
5. Separate reading and writing - commands to controllers (such as Sparkplug NCMD/DCMD) need extra control; the control loop itself stays local in the PLC.
6. Monitor and patch - log connections and failed logins, feed them into security monitoring and keep broker software up to date.

These measures fit within Defense in Depth and align with IEC 62443. For organisations covered by NIS2, open or unencrypted brokers are among the risks you must demonstrably manage, and the Cyber Resilience Act requires manufacturers to ship products with digital elements, such as devices and software with MQTT functionality, with a secure-by-default configuration.

❓ Frequently asked questions

What does MQTT stand for?

MQTT originally came from MQ Telemetry Transport, after IBM’s MQSeries product line. The expansion Message Queuing Telemetry Transport is widely used, but MQTT does not work with queues. Since its standardisation at OASIS, MQTT is the name of the protocol and no longer an official acronym.

Which port does MQTT use?

MQTT uses TCP port 1883 by default for unencrypted traffic and port 8883 for MQTT over TLS; both are registered with IANA. In production and OT environments, MQTT should run exclusively over port 8883 with TLS.

Is MQTT a real-time protocol?

MQTT delivers messages with low latency, often within milliseconds on a local network, but it is not deterministic. It is therefore suitable for monitoring, data acquisition and integration, not for real-time control loops or safety functions. Those remain in the PLC or the fieldbus system.

What is an MQTT broker?

An MQTT broker is the central server that receives all messages from publishers and forwards them to the clients subscribed to the relevant topic. Well-known MQTT brokers are Eclipse Mosquitto, HiveMQ and EMQX. Because all traffic passes through the broker, you need to make it redundant and secure it well.

What is the difference between MQTT and Sparkplug B?

MQTT is the transport protocol and leaves the content of topics and messages open. Sparkplug B is a specification on top of MQTT that defines a fixed topic structure, a binary payload format and state messages for edge nodes. This makes MQTT devices from different vendors interchangeable without custom integration.

Should I choose MQTT 3.1.1 or MQTT 5.0?

MQTT 5.0 is the latest version and offers better error reporting, shared subscriptions and expiry intervals, which helps in large installations. MQTT 3.1.1 is still more widely supported by industrial devices and is sufficient for most applications. Many brokers support both versions, so you can use them side by side.

📌 In summary

MQTT is the lightweight publish/subscribe protocol that connects sensors, PLCs, edge, SCADA and cloud through a central broker. With QoS levels, retained messages and Last Will, complemented by Sparkplug B and a Unified Namespace, MQTT forms the backbone of modern IIoT architectures. Secure use in OT does require TLS, client authentication, topic ACLs and a well-shielded broker.