MQTT - IoT protocol and publish/subscribe communication security

MQTT (Message Queuing Telemetry Transport) is a lightweight communication protocol based on the publish/subscribe model, designed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Cirrus Link) for transmitting telemetry from oil pipelines over satellite links with limited bandwidth. Today, MQTT is the dominant protocol in the IoT and IIoT ecosystem - from environmental sensors and smart meters, through SCADA monitoring systems, to cloud platforms like AWS IoT Core, Azure IoT Hub, and Google Cloud IoT.

The MQTT standard is maintained by OASIS, and the current version is 5.0 (2019), although version 3.1.1 (2014) remains the most widely used in embedded devices.

Publish/subscribe architecture

Unlike request/response protocols (HTTP, Modbus TCP), MQTT relies on an intermediary - the broker - that manages message distribution between publishers and subscribers. Clients do not communicate directly - they publish messages to topics, and the broker delivers them to all subscribers of a given topic.

Parameter	MQTT (unencrypted)	MQTT over TLS
Transport	TCP	TCP + TLS 1.2/1.3
Port	1883	8883
Authentication	Optional (username/password)	X.509 certificates + username/password
Encryption	None	AES-256-GCM (TLS)
QoS	0 (at most once), 1 (at least once), 2 (exactly once)	Same
Header overhead	2 bytes minimum	+ TLS overhead

The publish/subscribe model has significant security implications. The broker is the central point - whoever controls the broker controls all communication. Subscribing to the wildcard topic (#) allows eavesdropping on all messages passing through the broker.

Applications in OT and IoT

MQTT has found widespread use in:

• IIoT and telemetry - transmitting sensor data to SCADA platforms and historians (e.g. Sparkplug B - an MQTT specification for industrial use)
• Smart buildings - integrating IoT devices with BMS systems
• Energy - communication with smart meters (AMI) and PV inverters
• Edge computing - aggregating data on IoT gateways before sending to the cloud

In industrial contexts, Sparkplug B is particularly important - a specification that defines MQTT topic structures and payloads for SCADA/IIoT systems, with support for birth/death certificates (reporting device availability) and data types compatible with automation systems.

Security assessment

MQTT itself is a transport protocol - it does not enforce security policies, but merely provides mechanisms that must be consciously enabled and configured.

Common vulnerabilities in MQTT deployments:

• Broker without authentication - the default configuration of many brokers (e.g. Mosquitto) does not require login. Shodan scanners identify thousands of open MQTT brokers on the internet
• No topic-level authorization - even with authentication, a logged-in client can often subscribe to any topic (including #), gaining access to all telemetry
• Plaintext communication on port 1883 - passwords transmitted in plaintext, telemetry data (measurement values, device states) visible to anyone in the network segment
• Retained messages and Last Will - retained messages remain on the broker and are delivered to new subscribers, which can reveal system state to an attacker
• No payload validation - the broker does not verify message contents, enabling injection of false telemetry data

MQTT v5.0 introduces an Enhanced Authentication mechanism (extensible authentication, e.g. SCRAM), but its adoption in embedded devices is still limited.

Segmentation and protection

Securing an MQTT deployment requires action at three levels: broker configuration, network segmentation, and monitoring.

Broker configuration:

1. Enforce TLS 1.2+ on all listeners - disable the listener on port 1883
2. Deploy mTLS - mutual X.509 certificate authentication for IoT devices
3. Topic-level ACLs - each device should have access only to its own topics (e.g. site/floor1/sensor42/+)
4. Restrict wildcard subscriptions - block # and + subscriptions for IoT clients

Network segmentation:

1. Broker in a dedicated DMZ - separated by a firewall from both the IoT/OT network and the IT/cloud network
2. Separate brokers for different criticality levels - a broker for environmental telemetry should not handle PLC controller communications
3. Bridging instead of a single global broker - local brokers at the edge, with controlled forwarding to a central broker

A detailed approach to designing zones and conduits in OT and IoT networks is described in our article on OT network segmentation.

Open source tools

Tool	Language	Description	Link
mosquitto	C	MQTT broker + CLI tools for publishing and subscribing (mosquitto_pub, mosquitto_sub)	GitHub
MQTT Explorer	Desktop GUI	Graphical client for browsing topics, viewing messages, and broker structure	GitHub
paho-mqtt	Python	MQTT client library - publishing, subscribing, QoS and TLS support	GitHub

Sources

• OASIS MQTT Version 5.0 - official protocol specification
• Eclipse Sparkplug B Specification - MQTT for industrial SCADA/IIoT applications
• NIST SP 800-183 - Networks of Things - IoT security guidelines
• ENISA Good Practices for Security of IoT - European IoT security guidelines
• Eclipse Mosquitto Security - security documentation for the most popular open-source broker