As of October 28, 2026, a comprehensive scan conducted via the ZoomEye search engine has identified 2,188,380 internet-facing devices actively responding to queries using the Constrained Application Protocol (CoAP). This figure represents a significant baseline of reachable endpoints that utilize a protocol specifically architected for low-power, resource-constrained environments. CoAP, standardized under RFC 7252 in 2014, was engineered to facilitate communication for devices that lack the computational overhead required for traditional heavy-duty web protocols, such as TLS handshakes or verbose HTTP headers. From industrial sensors and building automation controllers to complex utility meters, these millions of devices are now operating in an environment far more exposed than their original design specifications anticipated.
Understanding the Protocol Landscape
To understand the significance of these 2.19 million reachable endpoints, one must first distinguish between a simple port scan and a protocol-aware probe. The ZoomEye query service="coap" does not merely count hosts with port 5683 open; it filters for devices that successfully parsed a CoAP request and returned a valid, structured response. Because CoAP operates over UDP, it lacks the connection-oriented handshake of TCP, making it inherently "silent" until probed. By verifying the presence of a version field, token, and specific response codes, security researchers can confirm that these devices are not just answering, but actively communicating via the CoAP protocol.
This measurement intentionally consolidates two distinct operational modes. While CoAP typically runs on UDP 5683, it is also frequently deployed on port 5684, where traffic is encapsulated within Datagram Transport Layer Security (DTLS). Security analysts have noted that attempting to separate these two categories often leads to unreliable data, as many constrained devices fail to complete a formal DTLS handshake with unknown or untrusted scanners. Consequently, the figure of 2,188,380 serves as a total footprint of reachable CoAP-enabled infrastructure, rather than a bifurcated count that might reflect the limitations of the scanning methodology rather than the actual deployment reality.
The Mechanism of Discovery
The core concern for network security professionals lies in the standard functionality of the /.well-known/core discovery resource, defined in RFC 6690. This endpoint is designed to allow clients to automatically discover the capabilities and resources hosted on a device. A simple GET request to this path returns a link-format document that serves as a complete map of the device’s internal interface.
For a developer, this is a feature that simplifies integration; for a potential adversary, it is a comprehensive inventory tool. The list returned might include sensitive paths such as /sensors/temp, /actuators/valve, /config/network, or even administrative functions like /config or /reset. By design, this discovery mechanism often functions without requiring prior authentication. The security assumption, which has historically been common in the IoT space, is that the network itself is trusted and isolated. However, as these devices are increasingly integrated into broader enterprise networks or connected to the public internet through permissive router configurations, this "trusted network" assumption frequently fails to hold.
Operational Vulnerabilities: Multicast and Authentication
The operational architecture of CoAP introduces two primary security challenges: the use of multicast and the optional nature of authentication.
CoAP is built to support multicast, allowing a single request to be sent to a group address, which in turn triggers responses from every device within that group. While this is highly efficient for synchronized industrial control systems, it acts as a significant request amplifier. A small, carefully crafted request can result in a disproportionately large volume of responses. While RFC 7252 suggests implementing restrictions to mitigate the risks of reflection and amplification attacks, the practical security of the network relies entirely on the implementation choices of the device manufacturer.
Furthermore, CoAP lacks a mandatory, built-in authentication layer. Security features such as OSCORE (RFC 8613) or DTLS are available, but they are optional and require complex provisioning. In many real-world deployments, these features are either disabled or left with default, factory-set credentials. If a device is shipped with a pre-shared key (PSK) that is never updated, or if OSCORE is bypassed during installation due to the difficulty of distributing master secrets, the device essentially becomes an open node, trusting any packet it receives from the network.
Historical Context and Chronology
The evolution of CoAP reflects the broader trajectory of the Internet of Things (IoT). Following its standardization in 2014, the protocol was widely adopted for its efficiency. However, the rise in the number of exposed devices has been gradual and largely unnoticed by the broader security community.
- 2014: RFC 7252 is published, establishing the technical foundation for CoAP.
- 2016-2018: Early deployments in smart cities and industrial automation begin to scale. During this period, the protocol is largely confined to private, segmented networks.
- 2020-2024: The proliferation of industrial IoT (IIoT) leads to a rapid increase in deployments. Many devices are connected to enterprise networks without sufficient firewall segmentation.
- 2026: Large-scale scanning operations, such as those performed via ZoomEye, reveal that over 2 million devices are reachable globally, raising urgent questions about the default security postures of these installations.
Analysis of Implications
The data does not suggest that all 2.19 million devices are compromised; rather, it highlights an expansive, exposed attack surface. The existence of these devices in an accessible state confirms that a significant portion of critical infrastructure—spanning environmental control, utility management, and industrial monitoring—is operating in a state of high visibility.
For network defenders, the primary task is not to eliminate CoAP, but to manage its reach. The presence of these devices on public-facing IP addresses is often the result of misconfiguration at the edge, such as an overly broad NAT rule or the lack of an effective stateful packet inspection (SPI) firewall. Organizations are encouraged to audit their network perimeters to ensure that UDP 5683 and 5684 are restricted to known, trusted collectors.
Industry analysts emphasize that this is an inventory problem. Security teams must move beyond simple port counting and actively query their own internal assets to determine what information is being exposed via /.well-known/core. By understanding which devices are broadcasting their internal resource maps, organizations can implement more granular access controls, effectively shielding these constrained devices from unauthorized discovery.
Conclusion and Recommendations
The prevalence of CoAP on the public internet is a testament to the protocol’s success in achieving its design goals: efficiency and ease of deployment. However, the same characteristics that make it ideal for low-power sensors also make it a point of concern in modern threat modeling. As the lines between operational technology (OT) and information technology (IT) continue to blur, the assumption of network-level trust is no longer sustainable.
Moving forward, the industry must prioritize the implementation of robust identity management for IoT devices. This includes the widespread adoption of OSCORE to ensure application-layer security, moving away from reliance on network-layer perimeter security. Furthermore, manufacturers and system integrators must adopt a "security by default" posture, ensuring that discovery endpoints are not exposed to the public internet and that authentication is a mandatory requirement rather than an optional configuration. As the number of reachable CoAP devices continues to grow, the necessity for a shift toward zero-trust principles in the constrained device space becomes increasingly critical for the stability and integrity of global industrial and utility infrastructure.
Related posts:
