The IoT protocols page covers how IoT devices physically join a network — Zigbee, Z-Wave, Thread, and so on. Once a device has network connectivity (by whatever means), it still needs an application-layer protocol to actually structure and exchange its messages — reporting a sensor reading, receiving a command, or announcing a change of state. This page covers the protocols most commonly used for exactly that job.
Unlike HTTP (see the HTTP & HTTPS page), which was designed around a client requesting a document from a server, IoT communication protocols are generally designed around very different assumptions: devices with limited processing power and battery life, network connections that may be unreliable or intermittent, and often a need for one device’s data to reach many interested recipients at once, rather than a single request/response pair.
MQTT (Message Queuing Telemetry Transport)
MQTT is by far the most widely used protocol in this category, particularly in home automation — if you’re running Home Assistant (see the Self-Hosting series), there’s a good chance MQTT is already quietly running in the background connecting several of your devices together.
Publish/subscribe
MQTT is built around a publish/subscribe (pub/sub) model, a fundamentally different pattern from HTTP’s request/response approach:
- A central broker sits in the middle of the network, and every device connects to it (rather than devices connecting directly to one another).
- A device that has data to share publishes it to a named topic — for example, a temperature sensor might publish its reading to
home/livingroom/temperature. - Any other device interested in that data subscribes to that same topic, and the broker automatically forwards any message published to it out to every current subscriber.
This decouples publishers from subscribers entirely — the temperature sensor has no idea (and doesn’t need to know) which devices, if any, are actually listening to its readings; it just publishes to its topic and lets the broker handle distribution. This makes it very easy to add a new device that’s interested in existing data (a new dashboard, a new automation) without changing anything about the device already publishing it.
Topics and wildcards
Topics are structured hierarchically, using / as a separator, similar in appearance to a file path. Subscribers can use wildcards to subscribe to multiple related topics at once — for example, subscribing to home/livingroom/# would receive every message published anywhere under that branch (temperature, humidity, light level, and anything else), while home/+/temperature would receive the temperature reading from every room, using + to match exactly one level in the hierarchy.
Quality of Service (QoS)
MQTT defines three Quality of Service levels, letting a publisher choose the right trade-off between reliability and overhead for each specific message:
- QoS 0: “At most once” — the message is sent without any confirmation of delivery. Fastest, but a message could be lost if there’s a connectivity problem.
- QoS 1: “At least once” — the broker confirms receipt, and the publisher will resend if it doesn’t hear back. Guarantees delivery, but a message could occasionally be delivered more than once.
- QoS 2: “Exactly once” — a more involved handshake guarantees the message arrives exactly one time, no more and no less. The most reliable option, but with the most overhead.
MQTT typically operates over TCP, on port 1883 (unencrypted) or port 8883 (secured with TLS, sometimes referred to as MQTTS).
CoAP (Constrained Application Protocol)
CoAP was designed specifically for the most resource-constrained devices — tiny microcontrollers with very little memory or processing power, often running on battery power for years at a time. Where MQTT deliberately keeps a persistent TCP connection open to its broker, CoAP takes the opposite approach.
A deliberately lightweight, UDP-based design
CoAP runs over UDP rather than TCP (similar reasoning to the choice covered on the QUIC page — avoiding the overhead of maintaining an open, reliable connection), and deliberately mirrors HTTP’s request/response model and verbs (GET, POST, PUT, DELETE) closely enough that it’s sometimes described as “HTTP for constrained devices.” CoAP typically uses port 5683.
Because CoAP doesn’t require a persistent open connection, it’s particularly well suited to devices that spend most of their time in a low-power sleep state, briefly waking to send or check for a small amount of data before going back to sleep — maintaining an always-open MQTT-style connection would be comparatively wasteful of that device’s limited battery life.
Observe
CoAP includes an extension called Observe, which allows a client to subscribe to changes on a specific resource somewhat similarly in spirit to MQTT’s publish/subscribe model, despite CoAP’s fundamentally request/response-oriented design — a client “observes” a resource, and the CoAP server pushes updates to it whenever that resource’s value changes, without the client needing to repeatedly poll and ask.
AMQP (Advanced Message Queuing Protocol)
AMQP is a considerably more feature-rich messaging protocol than MQTT, originally designed for enterprise and financial messaging systems rather than constrained IoT devices specifically, though it does see genuine IoT use, particularly in larger industrial and enterprise IoT deployments where its extra capability is actually needed.
Where MQTT offers a fairly simple publish/subscribe model, AMQP supports more complex message routing patterns via exchanges — a message can be published to an exchange, which then applies routing rules to decide which of potentially several different queues it should be delivered to, based on the message’s specific routing key, rather than every subscriber to a topic simply receiving everything published to it. AMQP also has stronger, more built-in guarantees around message durability and transactional delivery than MQTT typically offers.
This extra capability comes at the cost of considerably more complexity and overhead than MQTT, which is why AMQP tends to appear more in larger, more capable industrial IoT deployments and enterprise messaging systems, rather than in simple home automation setups, where MQTT’s comparative simplicity is usually a better fit.
DDS (Data Distribution Service)
DDS takes a notably different architectural approach from the other protocols on this page: it has no central broker at all. Where MQTT, CoAP, and AMQP all rely on some kind of central intermediary (a broker, or a server) to coordinate communication, DDS uses a fully decentralised, peer-to-peer publish/subscribe model, where devices discover each other directly and exchange data without any single point the traffic must pass through.
This lack of a central broker removes a potential single point of failure and bottleneck, which is a significant part of why DDS is commonly used in demanding, safety-critical, or high-throughput environments — it’s widely used in fields like autonomous vehicles, robotics, and military/aerospace systems, where a broker going down shouldn’t be able to bring an entire system’s communication to a halt. This capability comes with meaningfully more complexity to configure and reason about than a simple broker-based system, which is a large part of why DDS is comparatively rare in typical consumer IoT/home automation contexts, where MQTT’s simplicity remains the more practical choice.
LwM2M (Lightweight Machine to Machine)
LwM2M is a device management protocol, addressing a different problem from the data-transport protocols covered above. Rather than focusing on how sensor readings or commands are exchanged during a device’s normal operation, LwM2M focuses specifically on how a device is remotely provisioned, configured, monitored, and — critically — how its firmware is updated over its lifetime.
LwM2M is commonly used in cellular-connected IoT devices (using technologies like NB-IoT and LTE-M, designed for exactly this kind of low-power, wide-area device connectivity), where a device might be physically deployed somewhere remote and inaccessible, and remote firmware update capability is essential rather than optional. LwM2M is typically built on top of CoAP, rather than being an entirely separate transport mechanism of its own.
Comparing the protocols
| MQTT | CoAP | AMQP | DDS | LwM2M | |
|---|---|---|---|---|---|
| Model | Broker-based pub/sub | Request/response (+ Observe) | Broker-based, routed pub/sub | Brokerless, peer-to-peer pub/sub | Device management |
| Transport | TCP | UDP | TCP | Typically UDP | Built on CoAP |
| Typical use case | Home automation, general IoT | Constrained/battery devices | Enterprise/industrial messaging | Safety-critical, real-time systems | Remote device provisioning & firmware updates |
| Complexity | Low | Very low | High | High | Moderate |
IoT communication protocols and security
Many of the security considerations already covered on the IoT protocols page apply here too, but a few risks are specific to how these application-layer protocols are actually used.
Unauthenticated or open MQTT brokers are a widespread, real problem. An MQTT broker can be configured to allow anonymous connections with no authentication at all — convenient for quickly getting a home automation setup working, but if that broker is ever inadvertently exposed to the wider Internet (a genuinely common misconfiguration), anyone can connect, read every message being published across every topic, and publish their own messages, including forged sensor data or unauthorised commands to control devices. Search engines that index Internet-facing devices routinely find large numbers of exposed, unauthenticated MQTT brokers.
CoAP’s use of UDP makes it a candidate for amplification attacks, in the same general pattern already covered on the ICMP and NTP pages — a spoofed, small CoAP request sent to an exposed device can potentially trigger a larger response directed at a victim, since UDP allows the source address to be forged.
Firmware update mechanisms are a high-value target. Since LwM2M (and similar mechanisms in other ecosystems) exist specifically to push new firmware to a device remotely, compromising that update channel is a particularly serious risk — an attacker who could inject malicious firmware through a poorly secured update mechanism gains a very deep, persistent level of control over the device, potentially surviving even a full factory reset if the malicious firmware itself is what gets reinstalled.
TLS/DTLS support exists but isn’t always enabled by default. MQTT can run over TLS (MQTTS), and CoAP has an equivalent secured version called CoAPS, using DTLS (a variant of TLS designed to work over UDP — see the TLS page for the underlying concepts). However, given the resource constraints many of these devices operate under, encryption is sometimes skipped entirely for performance or simplicity reasons during development, and never properly enabled before a product ships.
Given these risks, sensible practical steps include always requiring authentication on an MQTT broker (never leaving it open to anonymous connections), never exposing a broker directly to the public Internet without a specific, well-considered reason and strong access controls, enabling TLS/DTLS wherever a device and broker both support it, and treating firmware update mechanisms as security-critical infrastructure deserving particularly careful protection.