MQTT

What is MQTT?

MQTT is a lightweight publish/subscribe messaging protocol designed for devices with constrained bandwidth, power and processing. Clients do not talk to each other; they connect to a broker, publish messages to topics and subscribe to topics. Topics are hierarchical strings such as plant/line3/robot7/temperature, and subscriptions can use wildcards: + for one level, # for everything below. Three quality-of-service levels (0, 1, 2) control delivery guarantees. Retained messages keep the last value of a topic for new subscribers, and a Last Will message is published by the broker when a client disconnects unexpectedly.

The protocol runs over TCP, conventionally on port 1883 for plain connections and 8883 for TLS, and over WebSockets for browsers. It is the dominant protocol in IoT fleets, smart home products, vehicle backends and Industry 4.0 data pipelines, including OPC UA PubSub over MQTT and Sparkplug B.

Where is it defined?

MQTT is standardised by OASIS. Version 3.1.1 (2014) is also published as ISO/IEC 20922:2016; version 5.0 (2019) adds reason codes, message properties, message expiry, shared subscriptions, server-side limits and enhanced authentication through the AUTH packet. The security chapter of both specifications is explicitly non-normative: it recommends TLS, authentication of clients and servers, authorisation of access to topics and protection of the broker, but mandates none of it. Security therefore comes from the broker configuration and the client implementation, not from the protocol.

For device manufacturers the Cyber Resilience Act applies: Annex I requires protection of data in transit and at rest, access control and protection against unauthorised access, which for an MQTT-connected product means TLS, per-device authentication and authorisation on the broker.

What it means in practice

We have tested MQTT brokers, the devices that connect to them and the cloud backends behind them in a range of IoT penetration tests. The findings repeat:

• Anonymous access. The broker accepts connections without credentials, usually a leftover from development.
• No TLS, or TLS without validation. Plain 1883 to the internet, or a device firmware that accepts any server certificate, which makes interception of credentials and commands trivial.
• One credential for the fleet. A username and password or a client certificate baked into the firmware of every unit. Firmware extraction from one device yields access to all.
• No topic authorisation. Every authenticated client may subscribe to # and publish anywhere. Data of all customers and commands to all devices become readable and writable, the MQTT equivalent of an IDOR.
• Identity not bound to topics. The device publishes under devices/<serial>/..., and the broker never checks that the authenticated client is that serial number.
• Retained messages and wills leaking state. Credentials, Wi-Fi passwords or location data in retained payloads that any subscriber receives on connect.
• Exposed management. Broker dashboards, WebSocket listeners and metrics endpoints reachable from the internet with default credentials.

The fixes are standard: TLS everywhere with certificate validation and ideally pinning on the device, per-device credentials or client certificates with a revocation path, access control lists that bind each identity to its own topic prefix, rate limits and payload size limits, and a broker that is not reachable beyond what the architecture needs. Zyberum tests MQTT deployments end to end: broker, devices (including firmware analysis), mobile apps and cloud APIs.

Common misunderstandings

TLS is not authorisation; an encrypted connection to a broker without ACLs still shows everything to everyone. A managed broker in the cloud is not secure by itself; the ACLs and identities are still yours to configure. And MQTT is not an industrial-only or consumer-only protocol; the same mistakes appear in both.