Unsecured IoT Protocols: MQTT, Telnet, and CoAP Exposure Trends

In September 2019, there were 7.8 million devices responding to Telnet connections on port 23 across the public internet — and that number was still growing. At the same time, 4.6 million MQTT brokers were accepting unencrypted connections on port 1883, exposing IoT sensor data, industrial control messages, and smart home commands to anyone who cared to listen. These aren't theoretical vulnerabilities. They're real services, on real IP addresses, responding to TCP SYN probes from Rapid7's Project Sonar. I processed four months of that scan data to understand just how exposed the IoT protocol landscape actually is, and the results paint a picture that's both concerning and surprisingly nuanced.

How I Measured This

The data in this article comes from Rapid7's Project Sonar, a security research project that performs regular internet-wide scans. I processed TCP SYN scan snapshots from June through September 2019, covering the key IoT-associated ports: MQTT (1883), MQTT over TLS (8883), Telnet (23), Telnet alternate (2323), and the surveillance camera Telnet port (9527).

Each scan sends a TCP SYN packet to every routable IPv4 address on the target port. A SYN-ACK response means something is listening. This doesn't tell us what's running behind the port or whether authentication is required — it tells us the port is open and accepting connections, which is the first step in any attack chain.

For context, I also pulled SSH (port 22) numbers to establish a baseline for a "healthy" protocol that's supposed to be internet-facing. SSH showed 24.3 million responding IPs with a growth rate of +20.7% over the same period, reflecting legitimate infrastructure expansion. The IoT protocol numbers should be read against that baseline.

If you want to check what ports are open on your own infrastructure, our port scanner can probe specific targets. For a broader view of security patterns across the DNS ecosystem, the security dashboard tracks related findings.

MQTT: The IoT Messaging Protocol That Shouldn't Be Public

MQTT — Message Queuing Telemetry Transport — was designed in 1999 for low-bandwidth, high-latency connections between oil pipeline sensors. It's a publish-subscribe messaging protocol: devices publish data to "topics" on a broker, and other devices subscribe to those topics to receive updates. It's elegant, lightweight, and now the backbone of everything from smart home systems to industrial SCADA networks.

The problem is that MQTT was designed for trusted networks. The protocol itself has optional username/password authentication, but many implementations ship with it disabled. When an MQTT broker is exposed on port 1883 without authentication, anyone can subscribe to all topics using the wildcard `#` and silently receive every message flowing through the system.

Here's what the exposure numbers look like:

The unencrypted MQTT count dropped 18.4% over four months, from 5.7 million to 4.6 million. That sounds like progress until you realize that 4.6 million is still an enormous number of brokers accepting plaintext connections from the entire internet.

What makes MQTT exposure particularly dangerous is the nature of the data flowing through it. In industrial settings, MQTT topics might carry temperature readings, pressure values, or actuator commands. In smart homes, you'll find door lock states, motion sensor triggers, and camera feeds. In healthcare IoT, it could be patient monitoring data. All of this traverses the broker in plaintext when TLS isn't configured.

I've seen researchers demonstrate connecting to exposed MQTT brokers and receiving real-time GPS coordinates from vehicle tracking systems, energy consumption data from smart meters, and even authentication tokens from poorly designed IoT applications. The wildcard subscription feature that makes MQTT so useful for legitimate applications also makes it trivially exploitable.

Telnet: The Protocol That Won't Die

Telnet is older than most of the people reading this article. Developed in 1969, it transmits everything — including passwords — in cleartext. SSH replaced it for legitimate remote administration decades ago. By any reasonable measure, Telnet should be extinct on the public internet.

It isn't. Not even close.

Standard Telnet on port 23 grew 3.7% over these four months, reaching 7.8 million endpoints. While the alternate IoT ports declined, the main Telnet port was still expanding. This is happening years after the Mirai botnet demonstrated — catastrophically — what happens when millions of Telnet-enabled devices sit on the public internet with default credentials.

In October 2016, Mirai took down DNS provider Dyn with a DDoS attack that peaked at 1.2 Tbps, disrupting Twitter, Netflix, Reddit, and dozens of other major services. Its method was brutally simple: scan the internet for devices with open Telnet ports, try a list of 62 common default username/password combinations, and conscript successful logins into a botnet. The source code was released publicly, spawning dozens of variants that are still active today.

Three years after Mirai, the Telnet attack surface was still growing. The 7.8 million figure represents devices that are not just vulnerable in theory — they're actively accepting connections on the protocol that Mirai used to build the most famous IoT botnet in history.

Port 9527 is particularly interesting. This is the default Telnet management port for many Chinese-manufactured IP cameras and DVRs, including widespread brands like Dahua and XiongMai. The 23% decline from 4.5 million to 3.5 million over four months likely reflects a combination of ISP-level blocking, firmware updates pushed after Mirai, and devices simply going offline. But 3.5 million is still a staggering number of surveillance cameras accepting Telnet connections from the internet.

The Encryption Gap

One of the more telling comparisons in this data is between MQTT on port 1883 (unencrypted) and MQTT on port 8883 (TLS-encrypted).

In September 2019, there were 4,648,376 unencrypted MQTT endpoints and 3,887,681 encrypted ones. That's a ratio of roughly 1.2:1 — for every encrypted MQTT broker, there were 1.2 unencrypted ones.

Both declined over the measurement period: unencrypted MQTT fell 18.4% while encrypted MQTT fell 21.7%. The faster decline of encrypted MQTT is counterintuitive at first, but it likely reflects the fact that TLS-enabled brokers tend to be more professionally managed and therefore more likely to be intentionally pulled behind firewalls or VPNs, while the unencrypted ones are more likely to be forgotten consumer devices or misconfigured deployments that nobody is actively maintaining.

The gap matters because MQTT without TLS exposes not just the message payload but also any authentication credentials. Even if a broker requires a username and password, those credentials are sent in plaintext and can be captured by anyone on the network path. An attacker who intercepts MQTT credentials can then authenticate to the broker and publish malicious commands — potentially controlling physical devices like industrial valves, building HVAC systems, or smart locks.

For the protocol to be secure, TLS isn't just a nice-to-have. It's a fundamental requirement. The fact that more brokers were running without it than with it tells you everything about the state of IoT security configuration in that era.

What's Actually Improving

Not everything in this data is bad news. Several IoT-specific ports showed meaningful declines:

• Port 9527 (cameras): -23.0%, from 4.5M to 3.5M
• MQTT 8883 (encrypted): -21.7%, from 5.0M to 3.9M
• MQTT 1883 (unencrypted): -18.4%, from 5.7M to 4.6M
• Port 2323 (alt Telnet): -5.6%, from 3.7M to 3.5M

The camera port decline is the most encouraging. After Mirai specifically targeted these devices, there was clearly a measurable response — whether through firmware updates, ISP port blocking, or consumer awareness. A 23% drop in four months suggests active remediation rather than natural attrition.

The MQTT declines are harder to interpret. They could reflect security improvements, or they could reflect the protocol's adoption cycle — brokers being moved to cloud-managed services that don't expose raw MQTT ports, for instance. AWS IoT Core, Azure IoT Hub, and Google Cloud IoT all provide managed MQTT endpoints that wouldn't show up in internet-wide scans because they're behind the cloud provider's infrastructure.

But then there's the elephant in the data: standard Telnet on port 23, growing at +3.7%. This growth likely comes from new IoT devices being deployed with Telnet enabled by default, faster than old ones are being retired or patched. The IoT market was (and still is) expanding rapidly, and many manufacturers continued shipping devices with Telnet management interfaces despite everything the security community had been shouting since 2016.

Why IoT Devices Stay Exposed

Understanding why millions of devices remain exposed requires understanding the economics and logistics of IoT deployment:

Manufacturer defaults favor convenience over security. A device that works out of the box sells better than one that requires configuration. Enabling Telnet by default, shipping without TLS, and using universal default passwords all reduce support costs and friction. The manufacturer bears no cost when these devices get compromised — that cost falls on the device owner and, through DDoS attacks, on the internet at large.

Most IoT devices have no meaningful update mechanism. A $30 IP camera doesn't have the same over-the-air update infrastructure as an iPhone. Many devices require manual firmware updates via a web interface or USB stick, which effectively means they'll never be updated. Some devices have update mechanisms that stop working when the manufacturer shuts down their cloud servers, leaving the device permanently stuck on whatever firmware version it shipped with.

Device lifespans exceed security support lifespans. A surveillance camera might operate for 10-15 years. The company that made it might provide firmware updates for 2-3 years, if that. The remaining decade is spent running vulnerable software with no possibility of patching. This is why the numbers stay so high: the installed base of insecure devices grows faster than devices are retired.

Network configuration is an afterthought. Most consumers and many small businesses don't know what ports their devices expose. They plug in a camera, it works, and they never think about it again. The device might be using UPnP to automatically punch holes in the router's firewall, exposing itself to the internet without any deliberate action by the user.

ISP-level intervention is inconsistent. Some ISPs block inbound connections to common vulnerable ports (23, 1883) on residential connections. Many don't. Even those that do often leave business-class connections unfiltered, and a surprising number of IoT devices end up on commercial networks.

The Botnet Pipeline

The data tells a story about what I think of as the "botnet pipeline" — the path from exposed device to weaponized attack node:

Stage 1: Discovery. Internet-wide scanning identifies devices with open ports. The same methodology that Rapid7 uses for research, attackers use for reconnaissance. Tools like Masscan can scan the entire IPv4 space for a specific port in under 10 minutes on a fast connection.

Stage 2: Identification. Banner grabbing and protocol fingerprinting determine what's running behind the port. An open port 23 might be a Cisco router (probably not useful, probably has a real password) or a Dahua camera (probably running default credentials).

Stage 3: Compromise. For Telnet, this means trying default credentials. Mirai's original list of 62 combinations was remarkably effective. For MQTT, no compromise is needed if the broker has no authentication — you simply connect and start subscribing or publishing.

Stage 4: Weaponization. The compromised device is enrolled in a botnet command-and-control infrastructure. It might be used for DDoS attacks, cryptocurrency mining, spam relay, or as a proxy for further attacks. The device owner rarely notices because IoT devices don't have user interfaces that would show unusual activity.

Stage 5: Persistence. Many IoT botnet infections survive reboots because they modify the device's firmware or startup scripts. Short of a factory reset (which many devices don't even support properly), the device remains compromised indefinitely.

The 7.8 million Telnet endpoints and 4.6 million unencrypted MQTT brokers in this data represent the Stage 1 attack surface — devices that have already been discovered and are waiting for exploitation. The actual number that have progressed to Stage 4 or 5 is unknowable from scan data alone, but botnet researchers consistently estimate that millions of IoT devices are actively compromised at any given time.

For reference, the scan data also showed 4.4 million exposed Redis instances and 3 million Memcached endpoints — services that should absolutely never be public-facing and represent additional attack surface beyond IoT protocols.

What Needs to Change

The pattern is clear from this data: voluntary security practices aren't working at scale. Specific changes that would actually move the numbers:

For manufacturers: Ship devices with unique passwords printed on the device label. Disable Telnet entirely — there's no legitimate reason for a consumer IoT device to have a Telnet interface in 2026. Enable TLS by default for MQTT and any other protocol that carries data. Support automatic firmware updates for the lifetime of the device, not just the warranty period.

For ISPs: Block inbound connections to high-risk ports (23, 2323, 9527, 1883) on residential connections by default. Notify customers when their devices are detected participating in botnet activity. Some ISPs already do this effectively; it needs to become universal.

For network administrators: Audit your network for exposed IoT ports. A simple scan of your external IP ranges for ports 23, 1883, 8883, 2323, and 9527 will reveal devices you probably didn't know were internet-facing. Segment IoT devices onto separate VLANs with no inbound internet access. Use our port scanner to check specific endpoints.

For regulators: The market has had over a decade to self-correct on IoT security, and the data shows it hasn't. Mandatory security standards for internet-connected devices — like the UK's PSTI Act or the EU's Cyber Resilience Act — are necessary. Minimum requirements should include unique default credentials, mandatory encryption for data in transit, and defined security update periods.

The 18.4% decline in unencrypted MQTT and the 23% decline in camera Telnet ports show that improvement is possible. But standard Telnet's 3.7% growth shows that improvement doesn't happen automatically. Every new wave of cheap, insecure IoT devices resets the clock, and the installed base of vulnerable devices continues to grow in absolute terms even as individual protocol categories shrink.