MQTT and CoAP: Security and Privacy Issues in IoT and IIoT Communication Protocols

As billions of devices join industrial networks, the communication protocols that connect them become prime targets for cyberattacks. MQTT and CoAP are two of the most widely deployed messaging protocols in IoT and IIoT environments, yet each carries distinct security and privacy vulnerabilities that operations teams must understand and mitigate. In this IIoT World explainer, we break down the authentication weaknesses, encryption gaps, and privacy risks inherent in both protocols, then outline practical countermeasures that security architects can apply today. Whether you are designing a new connected factory or auditing an existing SCADA network, this guide gives you the technical foundation to make informed protocol decisions.

Machine-to-machine (M2M) communication protocols, which enable machines to “talk” with one another so that commands are communicated and data is transmitted, are indispensable to applications and systems that make use of the internet of things (IoT) and the industrial internet of things (IIoT).

Message Queuing Telemetry Transport (MQTT) is a communication protocol widely used in both IoT and IIoT deployments. MQTT is a publish-subscribe protocol that facilitates one-to-many communication mediated by brokers. Clients can publish messages to a broker and/or subscribe to a broker to receive certain messages. Messages are organized by topics, which essentially are “labels” that act as a system for dispatching messages to subscribers.

Constrained Application Protocol (CoAP), on the other hand, is a client-server protocol that, unlike MQTT, is not yet standardized. With CoAP, a client node can command another node by sending a CoAP packet. The CoAP server will interpret it, extract the payload, and decide what to do depending on its logic. The server does not necessarily have to acknowledge the request.

MQTT
A high-level view of the interaction models of MQTT (left) and CoAP (right)

MQTT is preferred over CoAP for mission-critical communications because it can enforce quality of service and ensure message delivery. CoAP, for its part, is preferred for gathering telemetry data transmitted from transient, low-power nodes like tiny field sensors. Despite fulfilling different needs, both protocols are fundamental in IoT and IIoT deployments, where fast and flexible data exchange is a basic operational requirement.

Unsecure protocols and exposed records

An internet-wide scan on exposed MQTT endpoints conducted by IOActive’s Lucas Lundgren between 2016 and 2017 presented a clear deployment problem among tens of thousands of unsecure MQTT hosts. A smart-home-centric MQTT research was also released by Avast in 2018, highlighting the lack of secure configurations and the likelihood of misconfigurations in home devices that use MQTT. We decided to look into the same problem — and include CoAP in the picture — and to see if there has been more awareness surrounding it.

What we found was striking: Hundreds of thousands of MQTT and CoAP hosts combined are reachable via public-facing IP addresses. Overall, this provides attackers with millions of exposed records. Finding exposed endpoints in virtually every country is feasible due to the inherent openness of the protocols and publicly searchable deployments.

MQTT world map
Geographical distribution of MQTT brokers (top) and CoAP servers (bottom) Note: We recorded 17,226 MQTT brokers in the Asia-Pacific (AP) region. However, limitations in Shodan’s geolocation metadata inhibited us from determining more precise country or territory locations for the counts.

We also outlined design issues and implementation vulnerabilities, which can contribute to the number of unsecure deployments that we found. A design issue that we discovered (designated as CVE-2017-7653 for Mosquitto, the most popular broker), for instance, can allow a malicious client to supply invalid data. By using the message-retain option and modifying the quality of service (QoS), an attacker can lead clients to be flooded with the same (retained) message over and over.

More about MQTT Enables IIoT Security Best Practices within the Purdue Model

Unsecure endpoints, moreover, can expose records and leak information, some of which we found to be related to critical sectors, for any casual attacker to see. Vulnerable endpoints can also run the risk of denial-of-service (DoS) attacks or even be taken advantage of to gain full control.

 

This is an excerpt from an article published originally here. For in-depth analyses and insights, read the research The Fragility of Industrial IoT’s Data Backbone. Security and Privacy Issues in MQTT and CoAP Protocols” , written by Trend Micro Research with EURECOM and Politecnico Di Milano (POLIMI). 


FAQ

1. What are the main security differences between MQTT and CoAP in industrial IoT deployments?

MQTT operates over TCP and relies on TLS for transport-layer encryption, while CoAP runs over UDP and uses DTLS for the same purpose. MQTT’s publish/subscribe model can expose topic namespaces to unauthorized subscribers if access control lists are not configured properly. CoAP’s request/response pattern is lighter weight but is more susceptible to amplification and spoofing attacks because UDP does not include a handshake. In practice, both protocols require additional application-layer security measures, such as payload encryption and token-based authentication, to meet ICS cybersecurity standards like IEC 62443.

2. Why are MQTT and CoAP privacy risks especially critical in IIoT environments?

Industrial environments transmit highly sensitive data, including production volumes, equipment health metrics, and process parameters, that can reveal trade secrets or enable sabotage if intercepted. MQTT brokers, when misconfigured, can leak entire topic trees to any connected client, a vulnerability that researchers have exploited to harvest data from thousands of exposed brokers on the public internet. CoAP’s use of UDP multicast can similarly broadcast device telemetry to unintended recipients on the same network segment. Regulatory frameworks such as NIS2 in Europe now explicitly hold operators accountable for securing these data flows.

3. How can organizations harden MQTT and CoAP for ICS and SCADA networks?

Start by enforcing mutual TLS (mTLS) or DTLS with certificate pinning to authenticate both client and server endpoints. Implement fine-grained topic-level access control on MQTT brokers and resource-level permissions on CoAP servers. Use payload-level encryption, such as COSE for CoAP or custom AES-256 wrapping for MQTT, so that data remains protected even if transport security is bypassed. Network segmentation and protocol-aware firewalls add a further layer by restricting protocol traffic to authorized VLANs. Finally, continuous monitoring with ICS-specific intrusion detection systems helps identify anomalous subscribe or GET patterns that signal reconnaissance activity.

Related from IIoT World: