When we talk about Internet-of-Things security, we usually picture vulnerable cameras, smart locks, or poorly protected sensors. But many attacks don't need to start with the device at all. They can start with the "brains" behind it: the backend servers that store data, route messages, and control devices.

In our research paper, we measured the security of real-world IoT backends at scale, focusing on three protocols that IoT systems commonly "speak" directly: MQTT, CoAP, and XMPP. We collected and tested more than 337k publicly reachable backends and found a troubling pattern: basic security protections are often missing, outdated, or misconfigured.

What we measured (and why these protocols matter)

IoT deployments often rely on lightweight messaging protocols rather than traditional web APIs. We focused on:

• MQTT (publish/subscribe): devices publish messages to "topics," others subscribe to receive them.
• CoAP (REST-like over UDP): devices request resources (like "/sensor" or "/config") from a backend.
• XMPP (XML messaging): used for near-real-time messaging and some IoT integrations.

These protocols were designed for constrained environments, but that also means security features may be optional, inconsistently deployed, or hard to retrofit.

The three significant threats we looked for

We assessed backends as an unauthenticated outsider (non-invasive testing), and focused on three high-impact problem areas:

1) Information leakage

Some backends expose details that should never be public: software versions, topic names, resource lists, or even sensitive device data.

Across MQTT/CoAP/XMPP, 9.44% of reachable backends exposed information in ways that can enable privacy violations or further attacks.

2) Weak (or missing) authentication

Authentication is often optional in IoT deployments, and many systems omit it. Examples from the study include MQTT brokers that support wildcard topic subscriptions and XMPP servers that still support weak mechanisms such as PLAIN (credentials sent in a reversible encoding).

3) Denial of service (DoS), including amplification

CoAP is UDP-based, which makes it particularly susceptible to reflection/amplification attacks. We found that 30.38% of reachable CoAP backends were vulnerable to DoS attacks, and a large portion could be abused as amplification reflectors.

Two real examples that show the impact

To make this concrete, our paper includes motivating cases where insecure backends exposed highly sensitive data:

• A health monitoring device whose MQTT backend revealed personally identifiable information and health indicators (and even allowed inference of an outdated broker version with known vulnerabilities).
• A "smart car dongle" backend that leaked location, vehicle details, and anti-theft alarm status, precisely the kind of data that could enable real-world targeting.

The "security seatbelt" that's barely used: TLS

For TCP-based protocols (MQTT and XMPP), TLS should be a baseline protection against eavesdropping and tampering. But we observed extremely low adoption: only 0.16% of MQTT- and XMPP-speaking backends used TLS. Worse, many of the TLS-enabled ones supported outdated protocol versions (e.g., TLS 1.0/1.1), and a significant fraction were vulnerable to known weaknesses.

What operators can do right now?

The fixes are not vague, just often neglected:

• Turn on authentication and authorization (MQTT ACLs, XMPP strong auth only, CoAP access controls).
• Disable wildcard-style "list everything" exposure unless strictly needed.
• Patch and update broker/server software (many issues map directly to outdated versions).
• Use TLS (or DTLS for CoAP) where feasible, and configure it correctly (modern versions, safe ciphers, valid certs).
• If the backend doesn't need to be public, put it behind a firewall or restrict access to known networks.