The choice of communication protocol determines the energy consumption, throughput, and cost of an entire IoT deployment. The CoAP protocol (Constrained Application Protocol) was designed precisely for resource-constrained devices — microcontrollers with a few tens of kilobytes of RAM and battery power — operating on unreliable, low-bandwidth networks. In this guide we explain how the CoAP protocol works, how to secure it, and in which scenarios it works better than MQTT.
In short: CoAP is a lightweight, UDP-based request/response protocol in the REST model (GET, POST, PUT, DELETE methods), created for resource-constrained IoT devices. Use it where minimal energy consumption, low header overhead (4 bytes), and direct communication with a sensor matter; choose MQTT for publish/subscribe telemetry over unreliable links.
What is the CoAP protocol?
CoAP is an application communication standard for the Internet of Things, described in RFC 7252 and developed by the IETF. CoAP mirrors the REST architecture known from the web, but for the needs of machines operating on limited resources (constrained devices). Here, each sensor or actuator is a server exposing resources at URIs, e.g., coap://sensor.local/temperature.
The key difference from classic HTTP lies in the transport. Instead of TCP, CoAP uses UDP, which eliminates the overhead of establishing a connection and allows the entire header to fit in just 4 bytes. By comparison, an HTTP/1.1 header is usually hundreds of bytes — the difference translates directly into battery life and transmission cost on cellular networks.
How does the CoAP protocol work?
CoAP works in a request–response model on top of UDP and uses the same methods as REST: GET, POST, PUT, and DELETE. Because UDP does not guarantee delivery, reliability is provided by the CoAP layer itself through two message types.
- Confirmable (CON) — a message requiring acknowledgment (ACK); if the ACK does not arrive, the sender retransmits with exponential backoff (by default starting at about 2 seconds).
- Non-confirmable (NON) — a message without acknowledgment, ideal for streams of frequent readings, where the loss of a single sample does not matter.
An important extension is the Observe mechanism (RFC 7641): the client registers an observation of a resource, and the server sends updates on its own whenever the value changes. This gives behavior similar to publish/subscribe without maintaining a persistent connection. CoAP also supports block-wise transfer for sending larger payloads in batches of 16–1024 bytes, despite the UDP datagram size limit. This mechanism is sometimes used for OTA firmware updates on devices with minimal memory.
CoAP or MQTT — when to use which protocol?
Choose CoAP for direct, transactional communication with a single device with extremely limited resources; choose MQTT for scalable telemetry from many devices in a publish/subscribe model through a broker. The two protocols often coexist in a single architecture.
In design practice, in an edge computing architecture you encounter hybrid solutions: sensors talk locally over CoAP with a gateway that aggregates data and sends it to the cloud over MQTT. The most important differences:
- Transport: CoAP runs on UDP (request/response), MQTT on TCP (publish/subscribe through a broker).
- Topology: CoAP is peer-to-peer communication with a resource; MQTT requires a central broker.
- Energy efficiency: stateless UDP and a 4-byte header give CoAP an advantage on battery-powered devices and on NB-IoT networks.
- Ecosystem maturity: MQTT has broader cloud support; we described the details of MQTT in a separate guide to the MQTT protocol.
How do you secure the CoAP protocol?
CoAP security is provided primarily through DTLS (Datagram TLS), the equivalent of TLS for UDP transport, described as the coaps:// scheme. DTLS protects the confidentiality and integrity of messages and enables device authentication with certificates or pre-shared keys (PSK).
In deployments with elevated requirements, authentication based on X.509 certificates is used, which implements a zero-trust model for the device fleet. An application-layer alternative is OSCORE (RFC 8613) — it selectively encrypts message fields and remains resilient even when traffic passes through intermediary gateways (proxies). Regardless of the choice, key management and rotation should be part of the device lifecycle from the provisioning stage.
Where does the CoAP protocol work best?
CoAP works best in dense, low-power sensor networks: smart metering, environmental monitoring, building automation, and industrial IIoT with thousands of measurement points. Its low overhead lets communication fit within the narrow bands of LPWAN networks.
In industrial projects CoAP often complements older buses; where PLCs operate, we combine it with the Modbus and CAN industrial protocols at the gateway level. In hospitality and premium automation, the lightweight protocol makes it possible to poll dozens of devices in a room without loading the network. At FSS we design such communication layers end to end — from the microcontroller firmware to the cloud backend.
Frequently asked questions (FAQ)
Can the CoAP protocol work over the internet, not just on a local network?
Yes. CoAP uses UDP and URIs, so it can communicate over the internet, including from NB-IoT and LTE-M networks. For security, DTLS is then used (the coaps:// scheme). A CoAP-HTTP proxy, which translates requests into a classic web API, is also often used.
How does CoAP differ from MQTT in terms of energy consumption?
CoAP is usually more energy-efficient for infrequent, transactional readings: stateless UDP does not maintain a connection and has a 4-byte header. MQTT can be more efficient for a steady stream of telemetry, when the cost of maintaining the TCP session is spread across many messages.
Which microcontrollers support the CoAP protocol?
CoAP has been implemented for most popular IoT platforms, including ESP32 and STM32, as well as RTOSes such as Zephyr, Contiki-NG, and RIOT OS. The available libraries (e.g., libcoap, CoAPthon) fit in a few tens of kilobytes of memory, which makes it possible to run them on devices with very limited resources.
Summary: key takeaways
CoAP is a mature, standardized choice wherever minimal energy consumption, low overhead, and direct communication with a resource-constrained device matter. Combined with DTLS it provides security at a level close to TLS, and the Observe mechanism and block-wise transfer make it a versatile tool from telemetry to firmware updates. The best results come from a thoughtful hybrid architecture that combines CoAP, MQTT, and industrial protocols.
The FSS team has for years designed complete IoT solutions — hardware, firmware, and cloud backend — matching protocols to the real constraints of devices and networks. Want to choose the optimal communication stack for your product? Check out our offering for designing network-connected devices or discuss IoT integrations with our engineers.
{“@context”: “https://schema.org”, “@graph”: [{“@type”: “Article”, “headline”: “CoAP in IoT: How It Works and When to Use It”, “description”: “The CoAP protocol in IoT: how it works, how it differs from MQTT, and when to use it on resource-constrained devices. A practical guide from FSS.”, “author”: {“@type”: “Organization”, “name”: “FSS”}, “publisher”: {“@type”: “Organization”, “name”: “FSS”}, “inLanguage”: “en”, “articleSection”: “IoT”, “mainEntityOfPage”: “https://fss.cc/protokol-coap-w-iot/”}, {“@type”: “FAQPage”, “mainEntity”: [{“@type”: “Question”, “name”: “Can the CoAP protocol work over the internet, not just on a local network?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “Yes. CoAP uses UDP and URIs, so it can communicate over the internet, including from NB-IoT and LTE-M networks. For security, DTLS is then used (the coaps:// scheme). A CoAP-HTTP proxy, which translates requests into a classic web API, is also often used.”}}, {“@type”: “Question”, “name”: “How does CoAP differ from MQTT in terms of energy consumption?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “CoAP is usually more energy-efficient for infrequent, transactional readings: stateless UDP does not maintain a connection and has a 4-byte header. MQTT can be more efficient for a steady stream of telemetry, when the cost of maintaining the TCP session is spread across many messages.”}}, {“@type”: “Question”, “name”: “Which microcontrollers support the CoAP protocol?”, “acceptedAnswer”: {“@type”: “Answer”, “text”: “CoAP has been implemented for most popular IoT platforms, including ESP32 and STM32, as well as RTOSes such as Zephyr, Contiki-NG, and RIOT OS. The available libraries (e.g., libcoap, CoAPthon) fit in a few tens of kilobytes of memory.”}}]}]}