What Is MQTT? The Lightweight IoT Protocol Explained

Building a sovereign IoT platform on MQTT? WZ-IT designs, runs and integrates open-source IoT stacks on your own infrastructure - from broker to dashboard. Go to the IoT platform - Book a consultation

MQTT (Message Queuing Telemetry Transport) is a lightweight publish/subscribe protocol for the Internet of Things. Devices do not message each other directly; they publish to named channels (topics) on a central broker. Other clients subscribe to those topics and receive new messages automatically. This decoupling, a minimal protocol overhead and tiered delivery guarantees make MQTT the de facto standard for device communication - efficient enough for thousands of sensors over narrowband or unstable networks. MQTT runs over TCP/IP, by default on port 1883 (plaintext) and 8883 (TLS), and is specified as an OASIS standard in versions 3.1.1 and 5.0.

Table of contents

• How MQTT works: broker and publish/subscribe
• Topics and wildcards
• QoS 0, 1 and 2: delivery guarantees
• Retained messages and Last Will
• MQTT 3.1.1 vs. MQTT 5.0
• Security: TLS, authentication and ACLs
• Brokers compared: Mosquitto and EMQX
• MQTT vs. HTTP vs. CoAP: when to use what
• MQTT with ThingsBoard and Node-RED
• Running MQTT sovereignly with WZ-IT
• Further guides

How MQTT works: broker and publish/subscribe

At the centre of every MQTT architecture sits the broker (server). Clients connect to it and take on two roles, often at the same time: a publisher sends a message to a topic, a subscriber subscribes to one or more topics. The broker receives every published message and forwards it to all matching subscribers. Sender and receiver do not know each other and need not be online simultaneously - this is decoupling in space, time and synchronization.

Instead of many point-to-point links you get a star: each client holds exactly one persistent TCP connection to the broker. That connection is kept open (keep-alive) so the broker can push data at any time, without the client having to poll. A single CONNECT handshake is enough, after which packets are very small - the fixed header of a PUBLISH packet is just two bytes. This frugality is exactly why MQTT typically forms the transport layer between devices and platform in the IoT architecture.

Topics and wildcards

Topics are hierarchical, slash-separated strings, for example building/floor1/room2/temperature. They are not created in advance - a topic exists the moment someone publishes to it. Subscriptions support two wildcards:

• + matches exactly one level: building/+/room2/temperature hits every floor.
• # matches multiple trailing levels: building/floor1/# hits everything below floor 1.

Wildcards are only allowed when subscribing, never when publishing. A well-designed topic hierarchy is decisive for clean permissions and filtering - it is effectively the addressing scheme for all your IoT data flows.

QoS 0, 1 and 2: delivery guarantees

MQTT offers three Quality of Service levels, chosen per message, trading reliability against overhead:

Higher QoS means more packets and more state to keep. For plain measurement streams, where a single lost value does not matter, QoS 0 or 1 is usually enough. QoS 2 is reserved for cases where duplicate processing would do harm.

Retained messages and Last Will

Two mechanisms make MQTT robust for real devices:

• Retained message: if a message is published with the retain flag set, the broker stores it as the last known value of that topic. Every new subscriber receives it immediately on subscribing - ideal for status information such as "pump on/off", which a freshly connected client would otherwise only learn at the next update.
• Last Will and Testament (LWT): when connecting, a client registers a message that the broker publishes automatically if the connection drops unexpectedly. Other participants then reliably learn that a device is offline, without having to poll.

MQTT 3.1.1 vs. MQTT 5.0

MQTT 3.1.1 has been an OASIS standard since 2014 and remains extremely common. MQTT 5.0 was approved as an OASIS standard on 7 March 2019 (oasis-open.org) and brings extensions that matter especially for larger production systems:

• Reason codes: meaningful feedback instead of simple success/failure codes.
• User properties: arbitrary key-value metadata per message, for example for routing or tracing.
• Topic aliases: long topic names are replaced by short numeric aliases to save bandwidth.
• Session expiry and message expiry: explicit lifetimes for sessions and messages.
• Shared subscriptions: several consumers share one subscription for load balancing.
• Flow control and request/response: controlled message flow and a clean request/response pattern.

MQTT 5.0 is backward compatible - a 5.0 broker still accepts 3.1.1 clients. For new platforms we recommend MQTT 5.0 wherever device firmware and libraries support it.

Security: TLS, authentication and ACLs

MQTT has no encryption of its own, but it can be secured end to end - three layers always belong together:

1. Transport encryption: TLS on port 8883 instead of cleartext on 1883. This protects credentials and payloads against eavesdropping and tampering.
2. Authentication: username and password in the CONNECT packet or, stronger, client certificates (mTLS). Larger brokers additionally support JWT/OAuth.
3. Authorization: access control lists (ACLs) define per identity which topics a client may publish to or subscribe to - preventing a compromised device from reading or forging foreign data streams.

If you expose MQTT publicly, never put 1883 open on the internet; use TLS plus authentication only.

Brokers compared: Mosquitto and EMQX

The broker choice determines operations, scaling and licensing freedom. Two contenders dominate self-hosted setups:

Eclipse Mosquitto is the pragmatic default for most projects and edge gateways; version 2.1.2 was released on 9 February 2026. EMQX targets very large, distributed loads - but its open-source line has shipped under the Business Source License (BSL 1.1) since version 5.9, no longer Apache 2.0; this also applies to the current 6.x line (as of October 2026: 6.3.1). According to the licence text, a single node may be used in production free of charge as long as EMQX is not offered to third parties as a hosted service or embedded in a product; educational institutions and non-profit organizations may use EMQX in production without that restriction as long as the use is not for commercial profit. All other clusters require a commercial licence. The last Apache release, 5.8, reached end of life on 28 February 2026 according to the vendor. If you need true OSI open source with clustering, evaluate VerneMQ, for example; for single nodes, HiveMQ Community Edition or NanoMQ are also options, while HiveMQ offers clustering only in its commercial editions. We pick the broker deliberately by sovereignty, load and operational effort - no cloud lock-in, no per-device licence costs.

MQTT vs. HTTP vs. CoAP: when to use what

MQTT shines when many devices stay permanently connected and stream data continuously or receive commands in real time. HTTP fits occasional, request-based calls and simple REST integration. CoAP is the UDP-based choice for extremely constrained devices, such as battery-powered sensors without a stable connection.

MQTT with ThingsBoard and Node-RED

In practice MQTT is the glue between sensors and platform. ThingsBoard ships its own MQTT transport and behaves like a broker to devices: they connect on 1883 or 8883, usually authenticate with an access token as the MQTT username, and publish telemetry to v1/devices/me/telemetry. ThingsBoard accepts MQTT v3.1, v3.1.1 and v5.0 (thingsboard.io). Our implementation is described in the ThingsBoard expertise.

For pre-processing, protocol translation and routing we use Node-RED: with the MQTT-in and MQTT-out nodes, Node-RED subscribes to topics, transforms or filters payloads and forwards them - for example into a time-series database whose analysis you see in the Grafana IoT dashboard. The result is a continuous, open data path from sensor to visualization.

Running MQTT sovereignly with WZ-IT

MQTT is open, lean and vendor-neutral - the ideal basis for a sovereign IoT platform without cloud lock-in and without a per-device licence explosion. At WZ-IT we plan the broker (usually Mosquitto, scalable clusters when needed), harden it with TLS, mTLS and ACLs, and integrate it with ThingsBoard, Node-RED and Grafana on your own infrastructure in the EU - Proxmox, Hetzner or on-premises. You keep data, keys and operations in your own hands.

Set up an MQTT broker and IoT stack self-hosted? Go to IoT platform development - Book a consultation

Further guides

• What is ThingsBoard? - the IoT platform with its own MQTT transport
• IoT architecture: the layers explained - where MQTT sits in the bigger picture
• Grafana IoT dashboard with InfluxDB - make telemetry visible
• Node-RED expertise - process and route MQTT data