What is CoAP?
CoAP (Constrained Application Protocol) is an IETF-standardised application protocol (RFC 7252, 2014) that lets devices with little processing power, memory and energy exchange data using the web’s REST model, with a fixed header of only 4 bytes over UDP. It was designed for embedded sensors, actuators and gateways in the IoT, the Industrial Internet of Things and OT environments. Where HTTP is too heavy for a battery-powered microcontroller, CoAP offers the same concepts (URIs, GET/PUT/POST/DELETE, status codes) in a compact binary form. Within Industrial Automation and IT OT Convergence, CoAP appears mainly in wireless sensor networks, building management, smart meters and remote device management.
🧠 Where does CoAP come from and what is it for?
CoAP was developed by the IETF CoRE (Constrained RESTful Environments) working group. The core specification, RFC 7252, was published in June 2014 by Zach Shelby, Klaus Hartke and Carsten Bormann. The aim was a protocol with the same architecture as the web, but for networks with low bandwidth, frequent packet loss and devices that sleep most of the time.
RFC 7228 divides such constrained devices into three classes. The classification helps when choosing between CoAP, MQTT or a heavier protocol:
| Class | RAM (order of magnitude) | Flash (order of magnitude) | Typical protocol use |
|---|---|---|---|
| Class 0 | much less than 10 KiB | much less than 100 KiB | Too small to communicate securely with the internet on its own; talks through a gateway or proxy |
| Class 1 | about 10 KiB | about 100 KiB | CoAP over UDP, optionally with DTLS or OSCORE |
| Class 2 | about 50 KiB | about 250 KiB | Full CoAP stack; TCP-based protocols also feasible |
Extensions were standardised around the core later: Observe (RFC 7641, 2015), block-wise transfer (RFC 7959, 2016), CoAP over TCP, TLS and WebSockets (RFC 8323, 2018), the FETCH, PATCH and iPATCH methods (RFC 8132, 2017) and the OSCORE security layer (RFC 8613, 2019).
🔧 How does CoAP work technically?
CoAP follows a client/server model. A device is usually the server: it exposes resources
such as coap://sensor01/temperature. A gateway, SCADA interface or management platform is the client that requests those resources.
By default CoAP listens on UDP port 5683 (coap://) and, with DTLS, on port
5684 (coaps://).
Every message starts with a fixed 4-byte header: version, message type, token length, a code (method or response code) and a 16-bit Message ID. It is followed by a token of 0 to 8 bytes, compactly encoded options (such as Uri-Path and Content-Format) and the payload, which is often CBOR, JSON or SenML.
Because UDP does not guarantee delivery, CoAP handles reliability itself with four message types:
| Type | Meaning | When to use it? |
|---|---|---|
| Confirmable (CON) | Receiver must acknowledge; otherwise it is retransmitted | Commands and important values |
| Non-confirmable (NON) | No acknowledgement | Frequent readings where one missed value does not matter |
| Acknowledgement (ACK) | Acknowledges a CON message, often carrying the response | Server reply |
| Reset (RST) | Message received, but the context needed to process it is missing | For example after the device has rebooted |
The methods resemble HTTP: GET reads a resource, PUT updates or creates
it, POST asks the server to process a request and DELETE removes it.
Responses carry codes such as 2.05 Content or 4.04 Not Found, the counterparts
of HTTP 200 and 404. This is why an HTTP-CoAP proxy can translate between the two worlds easily.
📡 Which features make CoAP suitable for OT and IoT?
- Observe - a client registers with a resource and is notified automatically whenever it changes. This is the observer pattern between client and server, without a broker, and it reduces polling, network load and latency.
-
Discovery - through
/.well-known/core(CoRE Link Format, RFC 6690) a device lists its resources. A Resource Directory (RFC 9176) collects those descriptions centrally, which enables scalability to thousands of devices. - Multicast - a single request over UDP multicast reaches a whole group of devices, for example to switch every light in a zone.
- Block-wise transfer - large payloads such as firmware images travel across the network in blocks of 16 to 1,024 bytes.
- Proxying and caching - responses carry a freshness lifetime, so a gateway can buffer values on behalf of sleeping devices.
CoAP runs over IPv6 and over 6LoWPAN on IEEE 802.15.4 radios, but also over Wifi, Bluetooth networks and cellular links such as NB-IoT. The best-known protocol built on top of it is LwM2M from OMA SpecWorks: the device management protocol for firmware updates, configuration and diagnostics that is widely used in M2M applications over NB-IoT.
🔄 What is the difference between CoAP and MQTT?
CoAP and MQTT are often mentioned together, but they follow different models:
| Property | CoAP | MQTT |
|---|---|---|
| Model | Request/response (REST) plus Observe | Publish/subscribe through a broker |
| Standard | IETF RFC 7252 (2014) | OASIS; version 3.1.1 also ISO/IEC 20922 |
| Transport | UDP; also TCP, TLS and WebSockets (RFC 8323) | TCP; MQTT-SN variant for UDP and sensor networks |
| Fixed header | 4 bytes | At least 2 bytes |
| Security | DTLS or OSCORE | TLS |
| Discovery | Built in through /.well-known/core |
Not in the protocol; topics are agreed in advance |
| Multicast | Yes | No |
| Central component | Not required | Broker required |
In short: CoAP suits direct interaction with individual, often sleeping devices. MQTT suits distributing data to many consumers, as in a Unified Namespace. In practice a gateway often converts CoAP data to MQTT, AMQP or OPC UA.
🏭 Where is CoAP used in practice?
| Application | Example | Why CoAP? |
|---|---|---|
| Building Automation | HVAC sensors, lighting, occupancy detection | Battery power, mesh networks, multicast |
| Energy and utilities | Smart meters, energy telemetry | Device management through LwM2M over NB-IoT |
| Water sector | Level measurement, remote pump monitoring | Little data, long battery life |
| Manufacturing | Wireless vibration and temperature sensors for Condition Monitoring | Low-cost sensors that feed Predictive Maintenance |
| Edge Computing | Gateway that reads CoAP sensors and forwards the data | Translation to Historian, SCADA or cloud |
The major cloud platforms do not accept CoAP directly: AWS IoT Core works with MQTT and HTTPS, Azure IoT Hub with MQTT, AMQP and HTTPS, and Google Cloud IoT Core was shut down on 16 August 2023. CoAP devices therefore reach the cloud through an edge gateway or an LwM2M server.
🔐 How do you secure CoAP?
RFC 7252 defines four security modes: NoSec (no protocol-level security), PreSharedKey, RawPublicKey and Certificate, the last three
using DTLS. The mandatory-to-implement cipher suites are TLS_PSK_WITH_AES_128_CCM_8 and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8. DTLS 1.3 (RFC 9147, 2022) shortens the handshake. OSCORE protects the CoAP messages themselves, so encryption and authentication remain end-to-end even across proxies and gateways.
From a cybersecurity point
of view, the biggest risk is an unauthenticated UDP service reachable from the internet. Since December
2018 attackers have abused open CoAP devices for reflection and amplification DDoS: a GET request of about 21 bytes to /.well-known/core returns on average a reply of
around 720 bytes, an amplification of roughly 34 times. In 2019 hundreds of thousands of abusable devices
were visible worldwide. Other threats are spoofed senders, a replay attack on unprotected commands, and exhaustion of memory and battery.
🛠️ How do you deploy CoAP securely in an OT environment?
A practical hardening approach in five steps:
- Inventory - record every CoAP device and gateway in the asset inventory, including firmware version and security mode.
- Choose a security mode - NoSec only inside a fully isolated segment; otherwise DTLS with certificates or OSCORE, backed by sound certificate management and device identity management.
- Segment - place sensor networks in their own zone according to IEC 62443 and network segmentation; block UDP 5683 and 5684 at the internet edge with an industrial firewall.
- Limit - apply rate limiting on gateways and servers, as RFC 7252 recommends, and enable multicast only where it is needed.
- Monitor - include CoAP traffic in security monitoring; Wireshark dissects CoAP and DTLS out of the box.
Typical default values from RFC 7252 help when tuning timeouts and firewall rules:
| Parameter | Default value | Meaning |
|---|---|---|
| ACK_TIMEOUT | 2 s (randomised 2-3 s) | Initial wait for an ACK |
| MAX_RETRANSMIT | 4 | Maximum number of retransmissions, with doubling wait time |
| MAX_TRANSMIT_SPAN | 45 s | Longest time between first and last transmission |
| EXCHANGE_LIFETIME | 247 s | How long a Message ID is considered in use |
| NSTART | 1 | Simultaneous outstanding requests per server |
In the Netherlands and the EU this is also becoming a legal matter. The Cyber Resilience Act requires products with digital elements, including CoAP sensors and gateways, to be secure when placed on the market. Manufacturers must report actively exploited vulnerabilities from 11 September 2026; the full requirements apply from 11 December 2027. Organisations covered by the Dutch Cyberbeveiligingswet (in force since 15 August 2026) must include such devices in their risk management, for example using NIST SP 800-82 or the NIST CSF as a framework, and set out the rules in their security policy.
❓ Frequently asked questions
Is CoAP the same as HTTP?
CoAP is not HTTP, but it uses the same REST model with URIs, methods and status codes. CoAP is binary, runs over UDP by default and has a fixed 4-byte header, which makes it suitable for microcontrollers. An HTTP-CoAP proxy can translate requests between the two protocols.
Which port does CoAP use?
CoAP uses UDP port 5683 by default for unsecured traffic (coap://) and UDP port 5684 for
traffic protected by DTLS (coaps://). For CoAP over TCP or TLS (RFC 8323) the same port
numbers apply on TCP. In OT environments neither port should be open to the internet.
When should you choose CoAP instead of MQTT?
CoAP is the logical choice for small, often battery-powered devices that you want to address directly, without a broker and with built-in discovery and multicast. MQTT is a better fit when many systems need the same data through publish/subscribe. Many architectures combine both, with a gateway that converts CoAP to MQTT.
Is CoAP secure enough for industrial use?
CoAP can be deployed securely with DTLS or OSCORE, strong device identities and network segmentation. The NoSec mode offers no protection at all, and open CoAP devices have been abused for DDoS amplification since 2018. Treat the security of CoAP devices as seriously as that of other OT assets in your IEC 62443 zones.
What is the difference between CoAP and LwM2M?
CoAP is the transfer protocol for resources; LwM2M from OMA SpecWorks is a device management protocol that runs on top of it. LwM2M defines standard objects for firmware updates, configuration and diagnostics, among others. Many NB-IoT modules and wireless sensors use LwM2M over CoAP for remote management.
Do cloud platforms support CoAP directly?
AWS IoT Core and Azure IoT Hub do not support CoAP directly; they work with MQTT, AMQP and HTTPS. CoAP devices therefore usually reach the cloud through an edge gateway or an LwM2M server that converts the data. Google Cloud IoT Core no longer exists since 16 August 2023.
📌 In summary
CoAP brings the web’s REST model to devices with minimal resources: a 4-byte header over UDP, its own reliability through CON and NON messages, and extensions for Observe, discovery, multicast and block-wise transfer. In OT it appears in wireless sensor networks, building management, energy and water, usually behind a gateway that translates to MQTT, OPC UA or SCADA. Its weak spot is security: without DTLS or OSCORE and without segmentation, a CoAP device is an open UDP service that attackers abuse for DDoS.
CoAP is the lightweight web protocol for the smallest OT and IoT devices; deploy it only with DTLS or OSCORE, in an isolated zone and behind a gateway.