“Smart homes”, “Smart devices” and even “Smart cities”: these now familiar expressions illustrate how deeply embedded the Internet of Things (IoT) is in our daily lives. At the heart of these technologies, the MQTT protocol plays a subtle yet essential role. This article presents methods for securing MQTT in response to the growing challenges of IoT. 

In 2024, the number of connected IoT devices worldwide was estimated at around 18 billion, more than double the world’s population. From connected alarms to smart elevators, industrial sensors, and medical devices, these technologies now shape our daily lives. 

Recent advances in the field of IoT have transformed the way we interact with connected objects. Designed to be intuitive, they are accessible without specific expertise. The connections between them, often wireless, go almost unnoticed by users. However, behind this apparent simplicity lie sophisticated communication protocols, including MQTT.  

Due to its popularity and growing presence in sensitive operations, MQTT has been the subject of research for several years regarding the risks associated with its use. Here, we will focus on how it works, its potential vulnerabilities, and best practices for ensuring secure communications. 

MQTT and the reasons behind its popularity 

This protocol’s strengths 

Developed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom), MQTT was designed to provide a lightweight, efficient solution with low energy and bandwidth consumption for monitoring isolated oil pipelines in the desert via satellite link. 

It is precisely because of these fundamental properties that MQTT has now established itself as the standard for IoT data transmission. This protocol is also frequently used to upload data from sensors or connected objects to cloud platforms. 

Figure 1 – MQTT key features 

How it operates 

Definitions of key terms 

MQTT Client: A device that exchanges information. 

MQTT Broker: An intermediary entity that allows MQTT clients to communicate and through which all MQTT messages pass. Specifically, the broker receives published messages and distributes them to the relevant recipients (subscribers to the corresponding topic).  

Topic: A string of characters used to filter and organize messages according to a hierarchical structure. When a client posts a message, they associate it with a topic.  

Publish/Subscribe: A model derived from the classic client/server model, in which requests are not initiated by a client requesting resources from a server, but by a server regularly sending updates to clients without active solicitation.

MQTT is a “Machine to Machine” or M2M communication protocol that operates according to a Publish/Subscribe model, allowing for great flexibility in its implementation. 

MQTT clients can take on the role of publisher, subscriber, or both.  

To receive the information they need, subscribers subscribe to topics (1), which are generally organized hierarchically within the broker (e.g., Home/Room/etc.). When a publisher sends a message intended for subscribers to that topic (2), they are notified by the broker (3).

As a result, MQTT clients are not required to share the same network or be active at the same time, and do not need to be synchronized with each other.  

Figure 2 – Illustration of a simplified MQTT architecture 

Moreover, MQTT offers a “Quality of Service” mechanism for its messages, allowing communications to be tailored to the requirements of the application. For example, it can guarantee message delivery in the event of an unstable connection. MQTT clients can select one of three QoS levels for the distribution of their messages: 

• QoS 0 « At most once » – The message will be delivered once or not at all, without acknowledgment. 
• QoS 1 « At least once » – The message will be delivered periodically until the sender receives an acknowledgment.  
• QoS 2 « Once » – The message is guaranteed to be delivered once and only once. 

The chosen QoS level also affects how long the message is stored locally by the sender and recipient.  

This architecture enables decentralized and scalable communications. These features are particularly advantageous in the IoT field, where flexibility is essential to accommodate a wide range of use cases. They also explain why MQTT extends far beyond the IoT and finds applications in many other environments, such as telemetry and industrial monitoring. 

Is MQTT vulnerable? 

Like many other communication protocols, MQTT is not secure by default. Although most implementations now incorporate robust security solutions, certain weaknesses and configuration errors persist, leaving systems vulnerable. 

To illustrate these concepts, we will look at a standard example of how this protocol is used in an industrial environment. 

Figure 3 – Illustration of an example of industrial use of MQTT 

In this scenario, all systems represented contain an MQTT client that allows users to subscribe to topics and communicate with the on-premise broker. MQTT communications are unencrypted and there is no authentication of the broker or clients, leaving it possible for an attacker to access production data exchanged in clear text or to send commands to equipment by impersonating the broker or one of its clients. 

How can you protect yourself? 

To effectively mitigate these risks, the broker and MQTT clients must be carefully deployed and configured. Here we propose various security measures to ensure confidentiality, integrity, authenticity, and availability of end-to-end communications. 

Securing the MQTT broker 

Enabling default encryption for communications 

When port 8883 is the only MQTT port defined, unencrypted communication attempts on the broker are rejected. Furthermore, it is essential that the broker has access to a valid certificate and private key and that the cryptographic suite used is secure (e.g., TLS 1.2 or 1.3).  

Figure 4 – Enabling encryption on a Mosquitto MQTT broker via a configuration file 

Many IoT devices have low computing power and limited resources, so adding mechanisms such as TLS can represent a significant overhead. 

Implementation of customer authentication and control of their access rights 

MQTT allows the authentication of clients connecting to a broker using common methods such as a username and password (with an associated password file) and verification of the client’s certificate, validated by a certification authority (the broker must have the certificate from this authority). Some brokers also allow the use of external authentication solutions. 

To restrict subscriptions or publications on certain topics by clients, an Access Control List or ACL logic can be added.

Figure 5 – Addition of a certificate and password authentication with access control on a Mosquitto MQTT broker 

Strict management of topics is essential to prevent data leaks and limit the risk of compromising the broker. The use of wildcards # and + must be carefully monitored, as an overly permissive configuration would allow an attacker to access all ongoing exchanges. 

Deployment of broker protection measures    

A quick search on the Shodan search engine reveals thousands of MQTT brokers exposed on the Internet, often left in their default configuration, whose users are unaware of their existence or implications. It is therefore essential to protect the broker from both internal and external threats by applying good security practices, such as regularly updating the system or restricting the number of simultaneous requests and connections, to prevent denial-of-service attacks and ensure its availability. 

Securing MQTT clients 

Enabling communication encryption 

To connect to the broker, clients must use port 8883 and have a valid certificate and private key, otherwise the connection will be rejected.

Figure 6 – Encrypted connection on an MQTT Paho client 

The use of self-signed certificates to connect to the broker is strongly discouraged because they can be easily substituted.  

Implementation of broker authentication (mutual authentication) 

In addition to client authentication, MQTT supports broker authentication by verifying the certificate authority that signed its certificate, thus ensuring mutual authentication (mTLS) and secure communications.

Figure 7 – Broker authentication on an MQTT Paho client 

Implementation of customer protection measures 

If an MQTT client is compromised, an attacker could access a significant amount of information depending on the configuration of the targeted broker. This is why clients, and their secrets, must also be protected by applying good security practices on the client’s host machine and on the content of exchanges (e.g., adding anti-replay mechanisms to requests).  

What does the future hold for MQTT? 

Despite its maturity, MQTT remains an evolving protocol and is gradually incorporating innovative features to meet the growing demands of connected environments. In a context where demand for reliable, secure, and low-power communications continues to increase, it is likely that MQTT use cases will continue to multiply in the coming years.