Is port 5683 (CoAP) exposed, and why does it matter for DDoS?
Port 5683 is the default UDP port for CoAP, the Constrained Application Protocol built for low-power IoT and sensor devices. CoAP supports an optional encrypted mode (DTLS), but a huge number of internet-reachable CoAP devices run without it — and because a small request can trigger a much larger response, an exposed CoAP service doesn't just risk the device itself, it can be abused to flood a completely unrelated third party with traffic.
By AdminKit team, Netbase JSC · Updated October 23, 2026
What CoAP is, and why 5683 is reachable at all
CoAP (RFC 7252) is a lightweight, RESTful protocol built for constrained devices — sensors, actuators and other low-power IoT hardware — modeled on HTTP’s GET/PUT/POST semantics but running over UDP for a much smaller footprint. Like several other machine-to-machine protocols covered on this site, it supports an optional secure transport (DTLS) but ships, and is frequently deployed, without it turned on.
Why an exposed CoAP service is a DDoS risk, not just a privacy one
This isn’t theoretical. NETSCOUT’s ASERT research team documented a spike in real-world DDoS attacks abusing CoAP starting in January 2019, measuring an average amplification factor of roughly 34x — a 21-byte request to a device’s /.well-known/core resource-discovery endpoint produced a response of around 720 bytes, letting an attacker spoof a victim’s IP address and multiply a small amount of outbound traffic into a much larger flood hitting the victim. The Shadowserver Foundation’s 2020 internet-wide scan found more than 464,000 CoAP devices still reachable this way, warning that some exposed services also leak credentials or allow remote code execution beyond the DDoS risk.
How to check your own exposure
AdminKit’s planned open ports check is designed to test whether UDP port 5683 on your own public IP responds to an external request — the same basic reachability test the amplification research above used to find hundreds of thousands of devices in the first place.
How to fix it
- Turn on DTLS (CoAP’s encrypted, authenticated mode) if your device or gateway supports it, rather than running plain CoAP.
- Firewall UDP port 5683 from the internet if the device only needs to talk to a local hub or gateway — most consumer and industrial CoAP use cases don’t need direct internet reachability at all.
- Disable or restrict the
/.well-known/coreresource-discovery response if your device software allows it, since that’s specifically the request amplification attacks abuse.
CoAP shares its core problem — a lightweight protocol that supports security but doesn’t require it — with MQTT; see is port 1883 (MQTT) open on my router for the closely related anonymous-access issue on that protocol. The amplification pattern itself isn’t unique to CoAP either — SSDP, the discovery protocol behind UPnP, has been abused the same way when a router answers it from outside the local network.
Defensive use only
Every check this page links to is for assets you own or are explicitly authorized to test. Never scan, probe, or attempt to connect to a network or device you don’t control — AdminKit’s active checks only ever run against the IP making the request or an asset you’ve verified ownership of. See our Disclaimer and Acceptable Use Policy for the full terms.
This guide is general information, not a security audit of your specific network — see our disclaimer for what AdminKit's guidance does and does not commit to.
Frequently asked questions
Is my device actually at risk, or is this only about attacking other people?
Both — an exposed CoAP service can be used to flood a third party, which is the documented DDoS risk, and separately, researchers have found that some exposed CoAP services also leak information or allow remote code execution on the device itself.
Why does a tiny request produce such a disproportionately large response?
The commonly-abused request asks for /.well-known/core, CoAP's resource-discovery endpoint, which can list a device's full set of available resources — a response many times larger than the request that triggered it.
Does turning on DTLS fully fix this?
It fixes the amplification risk for that specific device, since DTLS requires a handshake an attacker can't complete by just spoofing a source IP — but confirm your gateway or hub actually supports and enforces it, since CoAP's spec makes DTLS optional, not mandatory.
Is CoAP exposure as well known a problem as MQTT or Telnet?
Less publicized to a general audience, but well documented in security research — NETSCOUT and Shadowserver have both tracked hundreds of thousands of exposed CoAP devices being abused for real DDoS attacks since 2019.
Related tools
Want AdminKit to watch this for you?
Free checks tell you the state today. Protective DNS and monitoring tell you when it changes.