MQTT (Message Queuing Telemetry Transport)

What Is MQTT?

MQTT was originally developed by IBM in the late 1990s to monitor oil pipelines via satellite, where bandwidth was scarce and connections were unreliable. The protocol was later standardized by OASIS and became the backbone of modern Industrial Internet of Things (IIoT) deployments. Unlike traditional web protocols that require a device to repeatedly ask a server for updates, MQTT allows devices to send data the moment it is generated and have that data instantly distributed to every system that needs it.

For maintenance and operations teams, MQTT is most relevant as the communication layer that connects physical sensors on equipment to monitoring dashboards, CMMS platforms, and analytics systems. Understanding how MQTT works helps maintenance managers evaluate sensor network architectures, diagnose data gaps, and make informed decisions about remote equipment monitoring infrastructure.

How MQTT Works: The Publish-Subscribe Model

MQTT is built around three roles: publishers, subscribers, and a broker.

A publisher is any device that generates data, such as a vibration sensor on a motor or a temperature sensor on a compressor. The publisher sends its data to the broker along with a topic label, for example plant/line-3/motor-7/temperature.

The broker is a server that receives all incoming messages and routes them based on topic subscriptions. It decouples publishers from subscribers entirely: a sensor does not need to know which systems are consuming its data.

A subscriber is any application that has registered interest in a topic. When a new message arrives on that topic, the broker immediately pushes the message to every active subscriber. A condition monitoring platform, a maintenance dashboard, and a historian can all receive the same sensor reading simultaneously without the sensor needing to know any of them exist.

This architecture makes MQTT extremely scalable. Adding a new consuming system requires no changes to sensors or the broker, only a new subscription. Removing a system equally requires no changes to devices in the field.

MQTT Topics and Topic Hierarchies

Topics in MQTT are strings that use a forward-slash separator to create a hierarchy, similar to a file path. A well-structured topic hierarchy mirrors the physical layout of a facility.

A consistent topic naming convention is one of the most important decisions in any MQTT deployment. It determines how easily new systems can subscribe to relevant subsets of data and how maintainable the network is over time. Many industrial teams align their MQTT topic hierarchy with their asset hierarchy so data is traceable back to specific equipment records.

MQTT Quality of Service (QoS) Levels Explained

Not all sensor data carries the same consequence if a message is lost. MQTT addresses this with three Quality of Service levels.

For predictive maintenance applications, QoS 1 is the most common choice. It ensures that threshold breach alerts and anomaly detection events reach the monitoring platform even if the network drops briefly, without the latency penalty of QoS 2.

MQTT Retained Messages and Last Will

Two MQTT features are especially useful for industrial monitoring: retained messages and Last Will and Testament (LWT).

A retained message is a message flagged to be stored by the broker. When a new subscriber connects and requests a topic, the broker immediately delivers the most recent retained message, so the subscriber always has a known starting value rather than waiting for the next publish cycle. This is useful for status topics that update infrequently, such as a machine's operational state.

The Last Will and Testament feature allows a device to pre-register a message with the broker at connection time. If the device disconnects unexpectedly without sending a proper disconnect notification, the broker automatically publishes the LWT message on the device's behalf. For maintenance teams, this enables immediate alerting when a sensor or gateway loses power or network connectivity, rather than relying on timeout-based detection.

MQTT vs HTTP vs OPC-UA: A Comparison for Industrial Teams

Many modern industrial architectures use both MQTT and OPC-UA. A PLC or SCADA system may communicate internally using OPC-UA, while an edge gateway converts and forwards that data upstream via MQTT for transmission to cloud analytics or a Unified Namespace.

MQTT in Condition Monitoring and Sensor Networks

Condition-based monitoring requires a steady stream of data from assets distributed across a facility. Sensors measuring vibration, temperature, current, and pressure generate readings continuously, sometimes at hundreds of samples per second per sensor. HTTP polling would overload the network and introduce latency; MQTT handles these workloads natively.

A typical deployment works as follows: sensors or edge gateways connected to equipment publish readings to an on-premises or cloud MQTT broker. A condition monitoring platform subscribes to relevant topics and processes the incoming data stream in real time, triggering alerts when readings cross thresholds or when machine learning models detect patterns associated with equipment failure.

MQTT is also central to machine-to-machine (M2M) communication architectures where assets must share status information with each other or with control systems without human intervention. For example, a sensor detecting abnormal vibration can publish an alert that automatically triggers a work order in a connected CMMS.

MQTT and the Unified Namespace

The Unified Namespace (UNS) is an increasingly popular industrial architecture pattern in which all data across a facility, from sensors and PLCs to ERP and MES systems, is published to a single shared MQTT broker. Every system in the enterprise subscribes to the topics it needs, and publishes data it generates, without point-to-point integrations between systems.

MQTT's publish-subscribe model is the natural transport layer for a UNS because it allows any number of producers and consumers to exchange data without coupling. A maintenance team adopting a UNS approach can expect MQTT brokers to be a core piece of their Industry 4.0 infrastructure, alongside DCS and MES systems.

MQTT Security Considerations for Industrial Deployments

MQTT was designed for constrained environments where security was not always feasible, so the protocol does not enforce authentication or encryption by default. In industrial deployments, this creates risk if brokers are left with default settings.

The core security practices for industrial MQTT deployments are:

• Transport encryption: Always use TLS on port 8883 rather than unencrypted TCP on port 1883. This prevents eavesdropping and man-in-the-middle attacks on sensor data.
• Authentication: Require username and password credentials at minimum. For critical systems, use mutual TLS with client certificates to verify device identity.
• Authorization: Configure the broker with topic-level access control lists (ACLs) so each device or application can only publish or subscribe to its authorized topics.
• Network segmentation: Place the MQTT broker in a dedicated network zone and restrict access using firewall rules. Sensors should not be able to reach the internet directly.
• Broker hardening: Disable anonymous connections, limit message size, and set appropriate rate limits to prevent denial-of-service conditions from misconfigured devices.

Operational technology environments warrant extra care because sensor networks often mix older devices that cannot support TLS with modern gateways that can. In these cases, securing the gateway and isolating legacy devices on a separate VLAN is a pragmatic approach.

Common MQTT Brokers Used in Industry

The choice of broker affects scalability, management overhead, and integration options. The most widely used brokers in industrial contexts are:

• Eclipse Mosquitto: Open-source, lightweight, and widely deployed on edge gateways and small on-premises servers. Suitable for facilities with a few hundred devices.
• HiveMQ: Enterprise-grade broker with strong clustering, management console, and extension ecosystem. Common in large industrial IoT deployments.
• EMQX: High-throughput open-source and enterprise broker capable of handling millions of concurrent connections. Popular in cloud-scale IoT platforms.
• AWS IoT Core / Azure IoT Hub: Cloud-managed MQTT endpoints with built-in authentication, device management, and integration to cloud analytics services.

For most manufacturing facilities, an on-premises broker paired with selective cloud forwarding provides the best balance of latency, data sovereignty, and real-time monitoring capability.

MQTT Versions: MQTT 3.1.1 vs MQTT 5

MQTT 3.1.1 is the version most widely deployed in existing industrial systems. MQTT 5, released in 2019, introduced several features relevant to maintenance operations:

• Reason codes: Every acknowledgment now includes a reason code, making it far easier to diagnose connection failures and delivery errors.
• Message expiry: Publishers can set a time-to-live on messages so stale readings are discarded if they have not been consumed within a defined window.
• User properties: Key-value metadata can be attached to any message without changing the payload format, enabling richer data tagging without schema changes.
• Shared subscriptions: Multiple subscribers can share a subscription to the same topic, distributing message processing across multiple consumers without duplicate delivery.

Teams building new asset condition monitoring infrastructure should consider MQTT 5 for its improved diagnostics and operational flexibility, particularly the message expiry and reason codes.

The Bottom Line

MQTT is the communications backbone of modern industrial sensor networks. Its publish-subscribe model, minimal overhead, and flexible delivery guarantees make it the right protocol for transmitting high-frequency machine data from the plant floor to monitoring platforms, maintenance systems, and analytics engines.

For maintenance and operations teams, MQTT is not just a developer concern. Understanding how the broker, topics, and QoS levels work helps teams design reliable data pipelines, troubleshoot gaps in sensor coverage, and evaluate whether their condition monitoring infrastructure can support real-time predictive analytics. As facilities move toward Industry 4.0 architectures, MQTT fluency is becoming a practical competency for reliability engineers and maintenance managers alike.

Frequently Asked Questions