MQTT Explained: The Protocol of IoT

If you have ever wondered how a battery-powered sensor on a rooftop, a smart thermostat, a connected industrial pump and a fleet-tracking device on a truck all manage to talk to the same cloud platform reliably over patchy mobile networks, the answer is very often a single protocol: MQTT. It is not glamorous, it does not appear on marketing slides, and most people who benefit from it every day have never heard of it. Yet MQTT underpins an enormous share of the machine-to-machine traffic that makes the Internet of Things actually function. Understanding it well is one of the highest-leverage things an integration engineer can do, because so many IoT problems turn out to be MQTT problems in disguise. This is the honest, practical explanation I wish more device vendors handed their customers.

The message up front: MQTT is a small, efficient publish-subscribe protocol built for devices that have little power, little bandwidth and unreliable connectivity. It does not connect devices directly to each other. It connects them all to a central broker that routes messages by topic. Once you understand the broker and the topic model, almost everything else about MQTT follows naturally. If you want to see where this fits in the wider picture, start with the enterprise system integration pillar.

1. What MQTT is

MQTT stands for Message Queuing Telemetry Transport, though the name is a historical artefact and not a precise description of what the protocol does today. It is a lightweight messaging protocol that runs on top of TCP/IP and follows a publish-subscribe pattern rather than the request-response pattern most people know from the web. It was created in 1999 by Andy Stanford-Clark of IBM and Arlen Nipper, originally to move sensor data over expensive and unreliable satellite links on oil and gas pipelines. That origin story tells you almost everything about its design priorities: keep the messages tiny, keep the protocol overhead minimal, and assume the network will drop out.

Today MQTT is an open standard governed by OASIS, and it is used far beyond its original industrial niche. It moves telemetry for connected cars, home automation platforms, wearable health devices, logistics trackers, building management systems and large industrial IoT deployments. The current version is MQTT 5.0, ratified by OASIS in 2019, which added features such as message expiry, user properties, reason codes and shared subscriptions on top of the widely deployed MQTT 3.1.1. The core model, however, has been remarkably stable across every version, which is part of why it has lasted.

The single most important thing to grasp is that MQTT is not a direct device-to-device protocol. A sensor never opens a connection to an application and hands it data. Instead every participant connects to a central server called a broker, and all communication flows through that broker. Publishers send messages to the broker, subscribers receive messages from the broker, and neither ever needs to know the other exists. This decoupling is the whole point, and it is what the next few sections unpack.

2. Why MQTT suits IoT

Plenty of protocols can move data across a network. What makes MQTT the default choice for the Internet of Things is that it was designed around the specific, harsh constraints that real devices operate under, rather than the comfortable assumptions of a data-centre or a web browser. Three characteristics matter most.

It is lightweight. The fixed header of an MQTT control packet is just two bytes. A minimal publish message adds only a small amount on top of the actual payload. Compare that to the verbose headers of an HTTP request, where cookies, user-agent strings and other metadata can dwarf the data you actually care about. On a microcontroller with a few kilobytes of RAM, or on a metered cellular link where every byte costs money, that difference is decisive. The MQTT client library itself is small enough to run on an eight-bit microcontroller, which is why it shows up on the cheapest connected hardware.

It uses publish-subscribe, not request-response. A device does not have to poll a server asking "is there anything new for me?" over and over, wasting power and bandwidth on empty answers. It simply publishes when it has something to say and subscribes to be told when something it cares about happens. This event-driven model fits the reality of telemetry, where a device may be silent for hours and then need to report a reading immediately. It also decouples producers from consumers completely, so you can add new subscribers to a data stream without touching the devices that produce it. This same pub-sub thinking underpins a lot of modern architecture, and it is worth reading the general publish-subscribe explainer to see how the pattern applies beyond IoT.

It tolerates low bandwidth and unreliable networks. MQTT was born on satellite links that dropped constantly, and it inherited a set of features specifically for that world: quality-of-service levels that guarantee delivery even when the connection flaps, session persistence so a device can reconnect and resume without losing messages, and a keep-alive mechanism that detects a dead connection without flooding the link with traffic. When a cellular device drives through a tunnel and loses signal, MQTT is built to recover gracefully rather than fail. Few protocols handle intermittent connectivity as calmly.

Taken together, these three traits explain why, when engineers sit down to connect thousands of small, remote, power-constrained devices to a central platform, MQTT is so often the answer. It was designed for exactly that problem, and the design has aged extremely well.

3. The broker and topics

Everything in MQTT revolves around the broker. The broker is a server that sits at the centre of the system and does one core job: it receives every published message and forwards it to every client that has subscribed to the relevant topic. Clients, whether they are sensors publishing data or applications consuming it, never talk to each other directly. They only ever talk to the broker. Popular broker implementations include Eclipse Mosquitto, HiveMQ, EMQX and the MQTT interfaces built into cloud platforms, but the role they play is always the same.

Messages are organised by topic. A topic is a simple hierarchical string, using forward slashes to create levels, much like a file path. A temperature sensor in a specific room might publish to a topic such as building/floor2/room214/temperature. An application that wants that reading subscribes to the same topic. The broker matches published topics against subscription topics and routes accordingly. Subscribers can also use wildcards: a single-level wildcard + matches one level, so building/floor2/+/temperature catches every room on floor two, while a multi-level wildcard # matches everything below a point, so building/# catches every message from the whole building. This topic model is what gives MQTT its flexibility. Devices publish to specific topics, and consumers subscribe as broadly or as narrowly as they need.

The diagram below shows the flow. Sensors on the left publish readings to their topics. The broker in the middle holds all the subscriptions and does the routing. Applications on the right subscribe to the topics they care about and receive only those messages. Note that no arrow ever goes directly from a sensor to an application. Everything passes through the broker.

This decoupling has a profound practical consequence. A device that publishes a reading does not need to know how many applications consume it, where they are, what language they are written in, or whether they are even online at that moment. You can add a new analytics service, a new dashboard or a new alerting rule simply by subscribing it to the right topic, and none of the thousands of devices in the field need to change or even be aware. That is the architectural gift MQTT gives you, and it is why so much of IoT is built on top of it.

4. Quality of service levels

Networks fail, and MQTT was designed with that as a first assumption rather than an edge case. To manage the trade-off between delivery certainty and network cost, the protocol defines three quality-of-service (QoS) levels for message delivery. Each level offers a different guarantee and charges a different price in round trips and complexity. Choosing the right QoS for each message type is one of the core design decisions in any MQTT deployment.

The practical guidance is to use the lowest QoS that your use case can tolerate, because higher levels cost bandwidth, latency and broker resources. For a temperature sensor reporting every few seconds, losing the occasional reading is harmless, so QoS 0 is the sensible default. For a command that must reach a device, such as "unlock this door" or "shut down this pump", you want at least QoS 1 so it is guaranteed to arrive, and you design the receiver to handle a possible duplicate safely. QoS 2 is reserved for the rare cases where a duplicate would cause real harm, such as a billing event or a financial transaction, and where the extra handshake overhead is genuinely worth paying. Most IoT traffic lives happily at QoS 0 or QoS 1.

A common misconception: QoS is not a property of a topic, it is negotiated per message and per hop. The QoS a subscriber receives can be lower than the QoS the publisher used, because the effective level is the minimum of the publisher's QoS and the subscriber's requested QoS. Do not assume that publishing at QoS 2 means every subscriber gets exactly-once delivery. It only holds if the subscriber also requested QoS 2, and the guarantee applies to each broker hop, not automatically end to end across bridged brokers.

5. Retained messages, last will and keep-alive

Beyond the core publish-subscribe mechanics, MQTT includes a handful of features that solve very specific and very common IoT problems. They are worth knowing because they turn up constantly in real deployments and they explain a lot of otherwise confusing behaviour.

Retained messages. Normally the broker forwards a message to whoever is subscribed at that moment and then forgets it. But a device may only publish its state occasionally, and a new subscriber that connects later would have to wait until the next publish to learn anything. The retained flag solves this. When a message is published with the retained flag set, the broker keeps the last such message for that topic and immediately delivers it to any client that subscribes afterwards. This is how a dashboard can show a device's last known state the instant it connects, rather than showing nothing until the device happens to publish again. Retained messages are ideal for state that changes rarely, such as a configuration value or an on/off status.

Last will and testament. Devices on unreliable networks drop offline without warning, and other parts of the system need to know when that happens. When a client connects, it can register a "last will" message with the broker: a topic and payload to be published automatically if the client disconnects ungracefully, for example because it lost power or network. If the broker detects the connection has died without a clean disconnect, it publishes the will on the device's behalf. This is how an alerting system learns that a sensor has gone dark, without every consumer having to run its own timeout logic. It is a small feature that does a lot of heavy lifting in monitoring architectures.

Keep-alive. TCP connections can appear alive at the socket level while actually being dead, a state that would leave the broker holding stale connections and unaware that a device has vanished. MQTT's keep-alive mechanism handles this. The client agrees a keep-alive interval with the broker at connection time, and if it has no other traffic to send within that window it sends a tiny PINGREQ packet, to which the broker replies with a PINGRESP. If the broker hears nothing at all for one and a half times the keep-alive interval, it considers the client dead, closes the connection and triggers the last will. This gives fast, low-overhead detection of dead connections without saturating a constrained link with heartbeat traffic.

These three features, retained messages for instant state, last will for disconnection awareness, and keep-alive for liveness detection, are what make MQTT feel robust in the field rather than merely functional in a lab. They are also the features people most often forget to configure, which is why so many IoT dashboards show stale data or fail to notice a dead device. Getting them right is a large part of getting an MQTT deployment right.

6. MQTT security

MQTT is a messaging protocol, not a security protocol, and this is a point where inexperienced teams get into trouble. By itself MQTT sends data in clear text and performs no authentication, which was acceptable on a private satellite link in 1999 but is unacceptable on the public internet in any modern deployment. Security has to be added deliberately, in layers, and the good news is that the standard mechanisms are well understood.

Transport encryption with TLS. The first and most important layer is to run MQTT over TLS, usually on port 8883 rather than the plain port 1883. TLS encrypts the entire connection between client and broker, so message contents, credentials and topic names cannot be read or tampered with in transit. On constrained devices TLS does add computational and memory overhead, and on the very smallest hardware that can be a real constraint, but for anything crossing an untrusted network it is not optional. Where devices genuinely cannot run TLS, the honest answer is to keep them on a private, physically isolated network rather than to pretend the risk away.

Authentication. The broker needs to know who is connecting. The simplest mechanism is a username and password supplied in the MQTT CONNECT packet, which must always be paired with TLS so those credentials are not exposed. A stronger and increasingly common approach is mutual TLS, where each device presents a client certificate that the broker verifies, giving each device a unique cryptographic identity that can be revoked individually. Client certificates scale better than shared passwords across large fleets and remove the problem of a leaked password compromising every device at once.

Authorization. Authentication proves who a client is; authorization decides what it may do. A well-run broker enforces access control lists that restrict which topics each client can publish to and subscribe from. A temperature sensor should be permitted to publish only to its own topic and nothing else, and certainly should not be able to subscribe to command topics or other devices' data. Getting authorization wrong is how a single compromised device becomes a foothold into the whole system, so the principle of least privilege applies to every client. MQTT 5.0 also adds enhanced authentication exchanges that support challenge-response schemes for more sophisticated identity flows.

A caution from the field: the internet is full of MQTT brokers exposed on port 1883 with no TLS, no authentication and wide-open access control, quietly leaking sensor data and, worse, accepting commands from anyone who connects. Public scans regularly find thousands of them. If you deploy MQTT, treat security as part of the initial build and not a later hardening pass. An open broker is not a minor oversight; it is a direct control channel into physical equipment handed to strangers.

7. MQTT versus HTTP for devices

Engineers coming from the web often ask why devices should not just use HTTP, since it is universal and well understood. It is a fair question, and HTTP is genuinely fine for some device scenarios, but the comparison exposes exactly why MQTT exists.

HTTP is a request-response protocol. A client opens a connection, sends a request, receives a response and typically closes the connection. That model is a poor fit for a device that needs to receive data pushed to it. For a server to notify a device of an event over HTTP, the device has to poll repeatedly, asking again and again whether anything has happened, which wastes power and bandwidth on mostly empty responses, or you have to layer on workarounds such as long-polling or websockets. MQTT's persistent connection and publish-subscribe model deliver server-initiated messages naturally, the moment they occur, with no polling.

HTTP is also heavy for the job. Its headers are large and text-based, connection setup can be costly, and there is no built-in concept of delivery guarantees or offline resilience. Every request carries substantial overhead relative to a small sensor reading. MQTT's two-byte header, persistent connection and quality-of-service machinery mean it moves the same data with a fraction of the bytes and recovers cleanly when the network drops. On a metered cellular plan across a large fleet, that efficiency translates directly into cost.

The honest summary is that HTTP remains a reasonable choice for devices that report infrequently, do not need to receive pushed commands, and live on good networks, particularly where reusing existing web infrastructure is more valuable than protocol efficiency. But for continuous telemetry, for two-way communication, for constrained hardware and for unreliable links, MQTT is the better-matched tool, and that describes most of the Internet of Things. The two are not enemies; many real systems use HTTP for provisioning and configuration and MQTT for the ongoing data stream.

8. Where MQTT fits

MQTT is rarely the whole architecture. It is the transport layer that gets device data reliably to a central point, after which other systems take over to store, process, analyse and act on it. Understanding where the protocol stops and the rest of the integration begins is essential to designing a system that actually works end to end.

In a typical deployment, field devices publish telemetry to a broker over MQTT. From the broker, that data is bridged into the wider enterprise: forwarded into a time-series database or data historian for storage, fed into a stream-processing layer for real-time analytics and alerting, and often relayed onward into business systems such as a CMMS, EAM or ERP so that a sensor reading can become a work order, a maintenance trigger or a billing event. The broker is the meeting point between the operational-technology world of devices and the information-technology world of enterprise applications, and bridging those two worlds cleanly is the heart of IoT integration. That bridge is exactly what the IoT integration explainer covers in depth.

MQTT also coexists with other protocols rather than replacing them. In industrial settings it frequently sits alongside OPC UA, which is richer and more structured for factory-floor equipment and control systems, with gateways translating between the two so that OPC UA data on the plant floor can travel efficiently over MQTT to the cloud. If your world includes industrial automation, the OPC UA explainer is the natural companion to this article. In buildings, MQTT is increasingly the backbone for real-time monitoring, carrying data from occupancy, energy, air-quality and equipment sensors into analytics platforms, a pattern explored in the smart building real-time monitoring article.

The integration insight: MQTT solves the transport problem elegantly, but it does not solve the semantics problem. The broker will happily route a payload without caring whether it is JSON, a raw number or binary, or whether two devices agree on what "temperature" means or in what units. Deciding topic naming conventions, payload formats and data models is where an MQTT project succeeds or fails, and it is a design job, not a protocol feature. Get the topic hierarchy and payload schema right early, because they are painful to change once thousands of devices are publishing to them.

9. References

For authoritative detail beyond this overview, two sources are worth going to directly rather than relying on secondary summaries:

• The OASIS MQTT Version 5.0 specification. This is the formal standard that defines the protocol precisely: packet formats, the full quality-of-service state machines, session handling, and the features added in version 5.0 such as message expiry, user properties, reason codes and shared subscriptions. It is the definitive reference when you need exact behaviour rather than a description of it.
• mqtt.org. The community home of the protocol, maintained alongside the standard, with introductory material, a directory of broker and client implementations, and links to the official specifications. It is the sensible starting point for orientation and for finding conformant tooling.

Final thoughts

MQTT endures for the same reason good infrastructure usually does: it does one job extremely well and gets out of the way. It moves small messages efficiently, over unreliable networks, between devices that may have almost no resources, and it does so through a broker model that decouples producers from consumers so completely that you can evolve either side without disturbing the other. Once the broker and topic model click into place, the rest of the protocol, the quality-of-service levels, the retained messages, the last will, the keep-alive, all reveal themselves as sensible answers to specific problems that real IoT deployments actually face.

What MQTT does not do is decide what your data means, how it is secured, or how it connects to the systems that turn a reading into a decision. Those are integration questions, and they are where most of the genuine engineering effort in an IoT project lives. The protocol is the easy part, well understood and well supported. Designing sensible topics, choosing the right quality of service for each message, securing the broker properly, and bridging the device world into your enterprise systems: that is the work that separates a demonstration from a dependable production system. Treat MQTT as the reliable foundation it is, and spend your real attention on the architecture built on top of it.

Related reading: Enterprise system integration explained, What is publish-subscribe?, IoT integration explained, OPC UA explained, Smart building IoT real-time monitoring.