There is no single IoT protocol. A connected device uses a stack of them: one to move bits over the air or a wire, one to route packets, one to carry messages reliably, and one that defines what the messages mean. Most confusion about IoT protocols comes from comparing protocols that sit at different layers, such as asking whether to use “MQTT or Wi-Fi”, when a real product needs one of each.
This guide lists the IoT protocols that matter in 2026, organised by layer, with comparison tables for the choices teams actually face: MQTT vs HTTP vs CoAP, Zigbee vs Thread vs Bluetooth, and LoRaWAN vs NB-IoT vs LTE-M. It finishes with a practical way to choose.
IoT Protocols by Layer
Every IoT protocol does one of five jobs. Placing a protocol in the right layer is the fastest way to understand what it can replace and what it cannot.
| Layer | What it does | Common IoT protocols |
|---|---|---|
| Connectivity (physical and link) | Moves bits over radio or wire | Wi-Fi, Ethernet, Bluetooth Low Energy, Zigbee, Z-Wave, Thread, LoRaWAN, Sigfox, NB-IoT, LTE-M, 5G RedCap, Wi-Fi HaLow |
| Network | Addresses and routes packets | IPv4, IPv6, 6LoWPAN (IPv6 over low-power radio) |
| Transport | Delivers data between endpoints | TCP, UDP, QUIC |
| Security | Encrypts and authenticates | TLS 1.3 (over TCP), DTLS (over UDP), OSCORE (for CoAP) |
| Application and messaging | Defines how messages are exchanged and what they mean | MQTT, CoAP, HTTP/REST, AMQP, DDS, WebSocket, LwM2M, Matter, OPC UA |
So a battery-powered temperature sensor might use Thread for connectivity, IPv6 over 6LoWPAN for the network, UDP for transport, DTLS for security and CoAP for messages. A factory gateway might use Ethernet, IPv4, TCP, TLS and MQTT. Both are “IoT protocols”; they simply answer different questions.
Choose connectivity from the physics of the deployment. Choose the messaging protocol from how the data needs to flow. They are separate decisions.
Application-Layer Protocols: MQTT, CoAP, HTTP and More
These protocols decide how devices and servers talk once a network connection exists.
| MQTT | CoAP | HTTP | AMQP | DDS | |
|---|---|---|---|---|---|
| Transport | TCP | UDP | TCP | TCP | UDP or TCP |
| Pattern | Publish/subscribe via broker | Request/response plus observe | Request/response | Queues and routing | Brokerless publish/subscribe |
| Overhead | Very low | Very low | High | Medium | Medium |
| Best for | Telemetry and commands at scale | Constrained, battery devices | Occasional reporting, web integration | Back-end and enterprise integration | Real-time systems and robotics |
This is the comparison most teams need. MQTT keeps one connection open and lets either side send at any time, so a device can receive a command the moment it is issued and report a reading without repeating headers. HTTP opens a request for each exchange, so a device that needs commands must poll, which costs battery and data. For a device sending a small reading every few seconds, MQTT typically moves a fraction of the bytes HTTP does. HTTP still wins where the device reports rarely, where firewalls only allow web traffic, or where the receiving system is a standard web API.
Short-Range Wireless: Wi-Fi, Bluetooth, Zigbee, Z-Wave and Thread
Short-range protocols connect devices inside a home, building or vehicle. The main trade-off is power against bandwidth, with mesh networking deciding how far a network can stretch.
| Protocol | Frequency | Typical data rate | Mesh | Power | Typical use |
|---|---|---|---|---|---|
| Wi-Fi | 2.4, 5 and 6 GHz | Tens of Mbps to Gbps | No (beyond mesh routers) | High | Cameras, appliances, anything mains-powered |
| Bluetooth Low Energy | 2.4 GHz | 1 to 2 Mbps | Optional (Bluetooth Mesh) | Very low | Wearables, phone-connected devices, beacons |
| Zigbee | 2.4 GHz | 250 kbps | Yes | Low | Lighting, sensors, building automation |
| Z-Wave | Sub-GHz (908 MHz US, 868 MHz EU) | Up to 100 kbps | Yes | Low | Home security and automation |
| Thread | 2.4 GHz (IEEE 802.15.4) | 250 kbps | Yes, IPv6-native | Low | Matter smart-home devices |
Zigbee and Thread share the same IEEE 802.15.4 radio; the difference is above it. Thread carries IPv6, so every device is addressable on an IP network through a border router, which is why Matter uses it. Zigbee has its own network layer and needs a hub to translate. Z-Wave runs on sub-GHz frequencies, which travel further and through walls better but differ by region. We cover what Matter does and does not standardise in the Matter protocol explained, and what Bluetooth’s latest version adds in why Bluetooth 6.2 matters for IoT.
Long-Range and Cellular IoT: LoRaWAN, NB-IoT, LTE-M and More
Low-power wide-area networks (LPWAN) trade bandwidth for range and battery life: a sensor can report from kilometres away for years on a single battery, as long as it only sends small amounts of data.
| Protocol | Spectrum | Data rate | Who runs the network | Strength |
|---|---|---|---|---|
| LoRaWAN | Unlicensed sub-GHz | About 0.3 to 50 kbps | You, or a public operator | Private networks, rural range, very low cost per node |
| Sigfox | Unlicensed, ultra-narrowband | About 100 bps, tiny payloads | UnaBiz (Sigfox 0G) and partners | Simplest, lowest-power devices sending a few messages a day |
| NB-IoT | Licensed LTE | Tens of kbps | Mobile operators | Deep indoor coverage, static devices such as meters |
| LTE-M | Licensed LTE | Up to about 1 Mbps | Mobile operators | Mobility, handover, voice, firmware updates |
| 5G RedCap | Licensed 5G | Far higher than LTE-M | Mobile operators | Wearables, cameras and industrial devices needing more bandwidth |
| Wi-Fi HaLow | Unlicensed sub-GHz (802.11ah) | About 150 kbps to tens of Mbps | You | Wi-Fi-style IP networks with around a kilometre of range |
LoRa is the radio modulation; LoRaWAN is the network protocol on top that defines gateways, network servers, device classes and security. Two devices can talk LoRa point to point without LoRaWAN, but anything at scale uses LoRaWAN.
The deciding question is usually who owns the network. LoRaWAN lets you install your own gateways, which suits farms, campuses and sites with no cellular coverage, and has no per-device airtime fee. NB-IoT rides on an operator’s network, so there is nothing to install, coverage reaches deep indoors, and you pay a subscription per device. If the devices move, LTE-M is usually better than either. Remember that many operators have already switched off 2G and 3G; anything designed today should not rely on them.
The architecture behind these choices, including private 5G and time-sensitive networking, is covered in IoT connectivity architecture.
Industrial and Building Protocols
Factories and buildings have their own protocols, many older than the term IoT. Connecting them to modern systems is a large part of industrial IoT work.
- OPC UA — a platform-independent standard for industrial data with a rich information model and built-in security; the common language between machines, SCADA and IT systems
- Modbus — a simple, decades-old master/slave protocol over serial lines (RTU) or Ethernet (TCP), still everywhere in meters, drives and PLCs
- PROFINET and EtherNet/IP — industrial Ethernet protocols for real-time control on the factory floor
- BACnet — the standard for building automation: HVAC, lighting, access control
- MQTT with Sparkplug B — a specification that gives MQTT a defined topic structure and payload format for industrial use, so data from different vendors arrives in a consistent shape
A common modern pattern uses a gateway that reads Modbus or OPC UA on the machine side and publishes MQTT to the cloud. The layers of that design are set out in industrial IoT architecture.
Security Protocols for IoT
Encryption is not optional for anything that controls equipment or carries personal data. Each messaging protocol has a matching security layer.
- TLS 1.3 secures TCP-based protocols such as MQTT, HTTP and AMQP
- DTLS provides the same protection over UDP, for CoAP and similar protocols
- OSCORE (RFC 8613) protects CoAP messages end to end, even when they pass through proxies
- Mutual authentication with device certificates lets the server verify each device, not just the reverse
Protocols only help if each device has a trustworthy identity to authenticate with. How to provision and manage that identity across a fleet is covered in IoT device identity.
How to Choose IoT Protocols
| Product | Connectivity | Messaging |
|---|---|---|
| Smart-home sensor | Thread | Matter |
| Container or vehicle tracker | LTE-M | MQTT or CoAP |
| Soil and weather sensors on a farm | LoRaWAN | LoRaWAN payloads, forwarded as MQTT |
| Factory machine monitoring | Ethernet via a gateway | OPC UA or Modbus in, MQTT out |
Frequently Asked Questions
Conclusion
IoT protocols make sense once you stop comparing across layers. Pick connectivity from the physics: power, range, environment and who runs the network. Pick messaging from the data flow: telemetry, commands, constrained devices or enterprise integration. Secure every link, and give every device an identity it can prove.
Protocol choices made early are expensive to reverse once hardware ships, which is why we settle them during architecture rather than after the first prototype. If you are designing a connected product, our embedded IoT solutions team can help you choose a stack that fits the device, the site and the budget.