What Is MQTT and Why Do IoT Devices Use It?

What MQTT Is

MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol designed for constrained devices and unreliable networks. It was created in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper for monitoring oil pipelines over satellite links where bandwidth was expensive and connections were intermittent.

The protocol is deliberately minimal. The smallest MQTT packet is 2 bytes. The fixed header is just 2-5 bytes. This makes MQTT viable on devices with limited memory and processing power - microcontrollers, sensors, battery-powered monitors - where HTTP's overhead would be prohibitive.

MQTT runs over TCP, typically on port 1883 (unencrypted) or 8883 (TLS-encrypted). It has become the de facto standard for IoT device communication, used by AWS IoT, Azure IoT Hub, Google Cloud IoT, and thousands of industrial and consumer IoT deployments.

The Publish-Subscribe Model

MQTT uses a publish-subscribe pattern instead of the request-response model used by HTTP. In pub-sub, senders (publishers) do not send messages directly to receivers (subscribers). Instead, they publish messages to a topic, and anyone subscribed to that topic receives the message.

This decouples producers from consumers. A temperature sensor publishes readings to the topic "building/floor3/temperature" without knowing or caring who is listening. A dashboard, an alerting system, and a data logger can all subscribe to the same topic independently. The sensor does not need to maintain connections to each consumer.

This is fundamentally different from HTTP, where the client must know the server's address and connect directly. In MQTT, publishers and subscribers only need to know the broker's address and the topic names.

Brokers and Topics

The MQTT broker is the central server that receives all published messages and distributes them to subscribers. Popular open-source brokers include Mosquitto, HiveMQ, and EMQX. Cloud providers offer managed brokers as part of their IoT platforms.

Topics are hierarchical strings separated by forward slashes, similar to file paths:

• home/livingroom/temperature
• factory/line2/motor/rpm
• building/floor3/hvac/status

Subscribers can use wildcards to receive messages from multiple topics:

• + matches exactly one level: home/+/temperature matches home/livingroom/temperature and home/bedroom/temperature
• # matches all remaining levels: home/# matches everything under home/

The wildcard # subscribed at the root level (#) receives every message published to the broker. On a misconfigured broker, this gives an attacker complete visibility into all IoT device communications.

graph TD
    subgraph "MQTT Publish-Subscribe"
        PUB1["Sensor A"] -->|"Publish:
temp/floor3"| BROKER["MQTT Broker"]
        PUB2["Sensor B"] -->|"Publish:
temp/floor4"| BROKER
        BROKER -->|"Forward"| SUB1["Dashboard"]
        BROKER -->|"Forward"| SUB2["Alert System"]
        BROKER -->|"Forward"| SUB3["Data Logger"]
    end

QoS Levels

MQTT defines three Quality of Service levels that control delivery guarantees:

QoS 0 - At most once: fire and forget. The message is sent once with no acknowledgment. It may be lost if the connection drops. Lowest overhead, used when occasional message loss is acceptable (periodic sensor readings where the next reading arrives soon anyway).

QoS 1 - At least once: the message is delivered at least once, with acknowledgment. The sender retransmits until it receives a PUBACK from the broker. The message may be delivered more than once (duplicates). The subscriber must handle duplicates.

QoS 2 - Exactly once: the message is delivered exactly once through a four-step handshake (PUBLISH, PUBREC, PUBREL, PUBCOMP). Highest overhead, used when duplicate messages would cause problems (billing events, state changes, commands).

Higher QoS levels consume more bandwidth and require more round trips. Most IoT sensor deployments use QoS 0 or QoS 1. QoS 2 is reserved for critical messages.

MQTT Security Problems

MQTT's security issues stem from how it is commonly deployed, not from the protocol itself:

Unencrypted by default: MQTT on port 1883 transmits everything in plaintext - topic names, message payloads, usernames, and passwords. Anyone on the network can read every message. TLS on port 8883 solves this, but many deployments skip encryption because of the overhead on constrained devices.

No authentication required: the MQTT specification allows anonymous connections. Many brokers ship with authentication disabled by default. An attacker who can reach the broker can connect, subscribe to all topics, and publish arbitrary messages - potentially sending commands to actuators, spoofing sensor readings, or disrupting automation systems.

Internet-exposed brokers: Shodan (the search engine for internet-connected devices) consistently finds thousands of MQTT brokers exposed to the internet without authentication. These brokers leak everything their IoT devices publish - environmental data, GPS coordinates, health metrics, industrial control data.

Topic injection: without access control lists (ACLs) on topics, any authenticated client can publish to any topic. A compromised sensor could publish commands to actuator topics, or an attacker could inject false readings into monitoring topics.

MQTT and BLE in IoT

Many IoT devices use BLE for local communication and MQTT for cloud communication. A BLE temperature sensor might broadcast readings via BLE advertisements, which a gateway device receives and forwards to an MQTT broker over WiFi. This two-hop architecture is common in smart building and industrial IoT deployments.

The BLEShark Nano can observe both halves of this chain. Its BLE scanner picks up the local BLE advertisements from IoT devices, revealing what devices are present, what data they are broadcasting, and what services they expose. The WiFi side captures traffic between the gateway and the MQTT broker, which (if unencrypted on port 1883) reveals the topic structure and message content flowing to the cloud.

Understanding MQTT helps security researchers assess the full IoT attack surface - from the BLE radio link to the cloud broker and everything in between.

Get the BLEShark Nano