CoAP and LwM2M Device Management Security Guide

Millions of constrained devices, from smart meters to asset trackers, are managed over CoAP and OMA LwM2M, and a single weak bootstrap credential or NoSec deployment can hand an attacker control of the whole fleet. CoAP is the lightweight web protocol for constrained nodes; LwM2M builds a device management model on top of it, with a bootstrap server, management servers and a firmware update object. Both offer strong security options: DTLS with pre-shared keys, raw public keys or certificates, and OSCORE with EDHOC for end-to-end protection through proxies. This guide explains which option fits which deployment, how to run bootstrapping and credential lifecycle safely, how to protect firmware updates and how to stop CoAP being used for amplification attacks. It goes deeper than the IoT Security Guide and is for IoT platform engineers, device makers and security architects.

Key takeaways

NoSec belongs only in the lab. The LwM2M Security object offers NoSec mode, and unauthenticated CoAP on the internet invites both takeover and amplification abuse.
The bootstrap server is the root of trust for the fleet. It provisions every management server credential, so its keys, accounts and logs need the highest protection, and its account on the device should expire.
Choose transport or object security deliberately. DTLS protects hop by hop and breaks at proxies; OSCORE protects CoAP requests end to end through proxies and suits multi-hop and gateway designs.
Per-device credentials, never shared ones. Pre-shared keys reused across devices or generated with weak randomness mean one extracted key opens many devices.
Firmware update is a privileged operation. The LwM2M Firmware Update object moves images; signing and verification of those images is your job and must be enforced on the device.

How CoAP and LwM2M fit together

CoAP (RFC 7252) is a request and response protocol modelled on HTTP but designed for constrained nodes and lossy networks, usually over UDP, with DTLS as its security binding. The default ports are 5683 for coap and 5684 for coaps. LwM2M, published by OMA SpecWorks, defines a client on the device, one or more LwM2M Servers that manage it, and a Bootstrap-Server that gives the client its server accounts and credentials. Devices expose numbered objects: Security (object 0), Server (1), Access Control (2), Device (3), Firmware Update (5) and OSCORE (21) are the ones that matter most for security.

LwM2M version	Release (OMA releases page)	Security-relevant additions
1.0	February 2017	Object model, bootstrap, CoAP over UDP and SMS with DTLS
1.1	July 2018	Enhanced bootstrapping, CoAP over TCP and TLS, wider LPWAN support
1.2	November 2020	MQTT and HTTP transports, improved bootstrapping, LwM2M CBOR encoding
1.2.1 and 1.2.2	December 2022 and June 2024	Security and transport updates; 1.2.2 listed as latest on 27 October 2026

Version 1.2 of the Security object adds resources for SNI, a proposed cipher suite list, TLS 1.3 features, signature algorithms and a link to an OSCORE object instance, so the security options available depend on both the client and server versions. Check that your device stack and management platform support the same version before relying on a feature.

Choosing a security mode

The LwM2M Security object defines five security modes for each server account: 0 Pre-Shared Key, 1 Raw Public Key, 2 Certificate, 3 NoSec and 4 Certificate mode with EST. CoAP itself defines matching DTLS modes. RFC 7925, the TLS and DTLS 1.2 profile for IoT, makes TLS_PSK_WITH_AES_128_CCM_8 mandatory for pre-shared keys and TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 for raw public keys and certificates, with secp256r1 as the recommended curve.

Mode	How it authenticates	Strengths	Weaknesses	Use when
Pre-Shared Key (0)	Symmetric key and PSK identity known to device and server	Smallest code and handshake; works on the most constrained devices	Server holds every device secret; no forward secrecy in pure PSK suites; key injection at manufacture must be protected	Very constrained devices with a secure factory or SIM-based provisioning path
Raw Public Key (1)	Device and server public keys pinned to each other	Asymmetric keys, no PKI needed, server holds no device secrets	Pinning and rotation are manual; no revocation infrastructure	Closed fleets talking to one operator
Certificate (2)	X.509 certificates chained to a trust anchor	Scales across operators; supports revocation and rotation	Larger code and messages; certificate lifecycle and trust anchor updates required	Large or multi-tenant fleets and devices with enough memory
Certificate with EST (4)	Certificates enrolled and renewed over EST	Automated enrolment and renewal from the bootstrap flow	Requires an EST service and policy; more moving parts	Fleets needing automated certificate rotation
NoSec (3)	None	Simple testing	No confidentiality, integrity or authentication	Isolated lab networks only

For certificate enrolment patterns see the IoT and Device Certificate Provisioning (EST, SCEP) Guide, and for hardware-backed device keys the IoT Device Identity with TPM and DICE Guide.

DTLS or OSCORE

DTLS secures the transport between two endpoints. When a CoAP proxy, gateway or cross-proxy to HTTP sits in the path, DTLS terminates there and the proxy sees the request in clear. OSCORE (RFC 8613, July 2019) instead protects the CoAP message itself with COSE, so request semantics such as method, resource and payload stay protected end to end while proxies can still forward messages.

What OSCORE protects: the method code and payload are encrypted, and options are split into inner options such as Uri-Path and Uri-Query, which are encrypted, and outer options such as Uri-Host and Proxy-Uri, which proxies need to read. The messaging layer fields and the Token are not protected.
Algorithms: AES-CCM-16-64-128 is the mandatory default AEAD and HKDF with SHA-256 is mandatory for key derivation.
Security context: each pair shares a Master Secret, Sender ID and Recipient ID, with optional Master Salt and ID Context; in LwM2M these live in the OSCORE object (21), linked from the Security object. Servers keep a replay window, 32 by default.
Key establishment with EDHOC: OSCORE needs its Master Secret established somehow. EDHOC (RFC 9528, March 2024) is a compact authenticated Diffie-Hellman exchange designed to set up an OSCORE context, with mutual authentication, forward secrecy and identity protection, using X.509, C509, CWT or CWT Claims Set credentials in three messages.
Context state: a device that loses its sequence number state after a reboot risks nonce reuse with the same keys. Confirm how your stack persists or re-derives the OSCORE context before deploying.

Decision guidance

Direct device to server over IP: DTLS (or TLS over TCP from LwM2M 1.1) is simpler and widely supported.
Through gateways, proxies, SMS or non-IP paths: OSCORE keeps protection end to end where DTLS would terminate at an intermediary. LwM2M also supports non-IP delivery through the 3GPP SCEF, with its own port and application ID resources in the Security object.
Small fleet, one operator: raw public keys avoid PKI overhead. Large or multi-party fleets: certificates, ideally with EST renewal, scale better and allow revocation.

Bootstrapping and credential lifecycle

Bootstrapping is where most fleet-wide risk sits. The Bootstrap-Server writes Security and Server object instances, including secret keys, into each device. Whoever controls it controls every device it bootstraps.

Factory credentials: inject a unique bootstrap credential per device in a controlled manufacturing step, ideally into a secure element or hardware-protected storage. RFC 7925 warns that poor randomness can produce the same key pair on many devices; test key generation.
Bootstrap account expiry: set the Bootstrap-Server Account Timeout so the client purges the bootstrap account after use. A value of 0, or leaving the resource out, makes the account lifetime infinite.
Access control: use the Access Control object (2) to grant each LwM2M Server only the operations it needs on each object instance. An Access Control Owner value of 65535 means the instance is created and changed only during bootstrap, which suits security-critical objects.
Server credential rotation: rotate LwM2M Server credentials by re-bootstrapping or by writing new Security object instances over a protected session, and record the change in the device registry.
Decommissioning: revoke certificates or delete PSKs and OSCORE contexts on the server side when a device is retired, and wipe credentials before refurbishment.

See the IoT Device Onboarding Guide and the Identity for IoT Fleets Guide.

Where identity fits

Each device's PSK, private key or OSCORE Master Secret is a non-human identity credential, and the bootstrap and management servers hold privileged machine credentials of their own. The management platform's operator accounts and API keys can push configuration and firmware to every device, so they deserve the same controls as cloud administrator accounts: phishing-resistant MFA for people, short-lived scoped credentials for automation, and logging of every write and execute operation. Store server-side PSK databases and private keys in an HSM or managed key service, and never export them into support tooling.

Firmware updates over LwM2M

The Firmware Update object (5) lets a server push a package directly or provide a Package URI for the device to pull, and reports progress through State and Update Result resources. Update Result value 5 means "Integrity check failure for new downloaded package", but the object does not itself define how the image is signed.

Sign and verify: sign images at build time and verify the signature on the device before install, with anti-rollback. The SUIT manifest approach is one option. See the IoT Secure Firmware Update Guide (SUIT, signed OTA).
Protect the Package URI: serve pulled images over coaps or https from an authenticated endpoint; a URI to an unprotected server lets an attacker swap images if signing is weak.
Staged rollout: use small device rings, watch Update Result and State values, and keep a rollback image.
Monitor failures: spikes in Update Result 5 (integrity failure) or 8 (update failed) can mean tampering or a bad build.

Abuse of CoAP: amplification and exposure

Because CoAP usually runs over UDP, responses can be larger than requests, and unauthenticated servers exposed to the internet can be used to reflect traffic at a victim, which ATT&CK tracks as Reflection Amplification (T1498.002). RFC 7252 says servers should rate limit responses and that clients sending requests without DTLS should use random tokens of at least 32 bits for internet use.

Do not expose plain CoAP: block UDP 5683 at the internet edge unless a service genuinely needs it, and require coaps on 5684 or OSCORE.
Rate limit: limit response rates per source on servers and gateways, and avoid large responses to unauthenticated requests such as resource discovery.
Filter spoofing: apply source address validation on networks you operate, so spoofed requests cannot leave them.
Scan your own ranges: look for devices answering CoAP on public addresses, including test units left on cellular private APNs with internet breakout.

Botnets have long exploited exposed IoT services; see the Mirai and IoT Botnet Families Guide.

Rolling out stronger security on an existing fleet

Most fleets cannot be re-flashed at once, and a broken credential change can strand devices in the field. Work in stages and keep a way back.

Audit: query the management platform for each device's Security Mode, PSK identity or public key, Bootstrap-Server Account Timeout, LwM2M version and firmware. Flag NoSec, duplicate identities and permanent bootstrap accounts.
Lab test: on representative hardware, test the target mode (for example certificates with EST, or OSCORE) against the production server stack, including reconnection after power loss and after a network outage.
Pilot ring: move a small group of devices you can physically reach by re-bootstrapping them with new credentials. Keep the old server account valid in parallel until the new one registers successfully.
Expand: roll out in rings by region or customer, monitoring registration success, handshake failures and battery or data usage, since stronger modes can increase message size.
Roll back: if a ring fails to register, restore the previous Security object instance through bootstrap; this only works if the bootstrap path itself is still trusted, so change bootstrap credentials last.
Retire the old path: once all devices use the new mode, remove old PSKs and accounts from the servers and close plain CoAP listeners.

Detection and measurement

Server-side logs: registrations, registration updates, bootstrap requests, DTLS handshake failures, OSCORE replay or decryption failures, and every write and execute operation on Security, Server, Access Control and Firmware Update objects.
Anomalies: bootstrap requests from devices already provisioned, many devices sharing one PSK identity, registrations from unexpected networks, and sudden changes in device endpoint names.
Network: CoAP traffic on 5683 crossing the internet edge, and response volumes far larger than request volumes.

Metrics:

Percentage of devices in NoSec mode in production (target zero).
Percentage of devices with unique credentials, verified by checking for duplicate PSK identities or public keys.
Percentage of devices with a finite Bootstrap-Server Account Timeout.
Percentage of firmware updates that are signed and verified on device, and the Update Result failure rate per release.
Number of internet-exposed plain CoAP endpoints found in your address space.

Framework mapping

Framework	Reference	Applies to
NIST SP 800-53 Rev. 5	IA-3, SC-12, SC-13	Device authentication, key establishment and management, cryptographic protection
NIST SP 800-53 Rev. 5	SC-8, SC-5	Protection of management traffic; denial of service and amplification
NIST SP 800-53 Rev. 5	SI-7, CM-14, AC-3	Firmware integrity, signed components, access control on objects
NIST CSF 2.0	PR.AA-01, PR.AA-03, PR.DS-02, PR.PS-02	Device credentials, authentication, data in transit, firmware maintenance
MITRE ATT&CK v20	T1498.002, T1557, T1040	Reflection amplification, adversary-in-the-middle, sniffing of unprotected traffic
Baselines	NIST IR 8259A, ETSI EN 303 645	Device identity, secure update and secure communication requirements; see the NIST IR 8259 IoT Device Cybersecurity Baseline Guide

Common failure patterns

NoSec in production: a pilot configuration with Security Mode 3 shipped to customers.
Fleet-wide PSK: one pre-shared key or bootstrap credential burned into every device, so extracting it from one unit compromises all.
Permanent bootstrap account: the Bootstrap-Server account never expires, so anyone who compromises bootstrap can re-provision devices at will.
DTLS terminating at a gateway: a gateway decrypts and re-encrypts management traffic, becoming a high-value target that sees every credential written to devices.
Unsigned firmware over a Package URI: devices install whatever the URI serves.
Plain CoAP on public addresses: devices or test servers answering UDP 5683 from the internet and used for amplification.

Practitioner checklist

Ban NoSec outside isolated labs and verify the Security Mode on every production device.
Give every device unique bootstrap and server credentials in hardware-protected storage.
Set a finite Bootstrap-Server Account Timeout and protect the bootstrap server as a tier-zero system.
Use Access Control object instances to give each server least privilege.
Choose DTLS for direct paths and OSCORE with EDHOC where proxies or gateways sit in the path.
Follow RFC 7925 cipher suites and test device random number generation.
Sign firmware, verify on device and serve Package URIs only from authenticated endpoints.
Block plain CoAP at the internet edge and rate limit CoAP responses.
Log object writes, executes, handshake failures and bootstrap events to the SIEM.

Standards and references

Related NHI Mgmt Group resources: IoT Security Guide · MQTT Security Guide · Device and IoT Identity Guide · LoRaWAN Security Guide

CoAP and LwM2M Device Management Security Guide: DTLS, OSCORE and Secure Bootstrapping