MQTT Security Checklist for Connected Products
A practical MQTT security checklist for IoT makers: authentication, TLS, topic authorisation, per-device credentials and broker hardening, with the mistakes we find most.
Zyberum Security Team · Published · 8 min read
If your product talks to a cloud backend, there is a good chance MQTT carries the messages, and a good chance the broker is the weakest part of the system. MQTT is a lightweight publish and subscribe protocol: devices publish to topics and subscribe to topics, and a broker routes between them. The protocol itself does almost nothing for security, so the safety of the whole fleet rests on how the broker is configured and how the application uses it. This checklist is what we work through on every IoT test that involves a broker.
The one mistake that breaks everything
The most damaging MQTT finding is missing topic authorisation. A broker checks that a client authenticated, then lets that client subscribe to any topic it asks for. Because devices usually publish to predictable topics (device/{id}/telemetry, device/{id}/command), one valid account, often recovered from a single device’s firmware, can subscribe to every other device’s data and publish commands to them. We have turned one set of extracted broker credentials into full read and write access to an entire fleet in a single afternoon. Per-device credentials do not help here unless the broker also restricts each device to its own topics.
The checklist
Work top to bottom. Each item is something we actively test.
Authentication
- Every client authenticates. Anonymous connections are disabled on the broker.
- Credentials are per device, not one shared account burned into every unit.
- Device credentials are provisioned, not shipped in the firmware image, and can be rotated and revoked.
- Where the hardware supports it, devices use client certificates (mutual TLS) instead of passwords.
Transport
- TLS is enforced (port 8883). Plaintext (1883) is closed, or bound only to localhost.
- The device verifies the broker certificate. A device that accepts any certificate is open to a machine-in-the-middle, which we test for directly.
- TLS 1.2 or 1.3 only, modern cipher suites, certificate pinning where the update process allows it.
Authorisation
- Each device may publish and subscribe only to its own topics. This is an access control list on the broker, enforced per client.
- Wildcard subscriptions (
#,+) are not available to device accounts. - Command topics are writable only by the backend, not by other devices.
Broker hardening
- The broker is patched and not exposing its admin or metrics interface to the internet.
- Default accounts are removed. Many brokers ship with a known test user.
- Message size, connection rate and subscription count are limited, so one client cannot exhaust the broker.
- Logging is on, and failed authentication and unusual subscriptions are visible to your monitoring.
Application design
- No secrets, personal data or command tokens travel in clear topic names or retained messages.
- Retained messages and last-will payloads are reviewed. They often leak state to any subscriber.
- The backend validates payloads. A device must not be able to send a malformed message that crashes the consumer.
What we see in practice
Across IoT pentests of ESP32-based modules, broker setups and the cloud APIs behind them, the same handful of issues come up. Anonymous access left on “for testing”. One shared account for the whole product line, recoverable from any unit’s flash. TLS present but the device not verifying the certificate, so a local attacker can sit in the middle. And, most often, no topic authorisation at all, so any authenticated device sees every other device. None of these are exotic. They are configuration defaults that never got changed before shipping.
How this maps to compliance
For products in scope of the Cyber Resilience Act, Annex I requires protection of the confidentiality and integrity of data and of communication. An MQTT broker that lets one device read another’s data is a direct gap against that requirement. For connected radio equipment, EN 18031 points the same way on network communication and access control. A broker configuration review and an IoT pentest give you the evidence that the controls work.
Where to start
Fix topic authorisation first: it closes the fleet-wide exposure that everything else enables. Then enforce TLS with certificate verification on the device, move to per-device credentials, and harden the broker. Zyberum tests brokers, devices and the cloud APIs behind them under written authorisation, and never tests a system without it. See IoT security or book a free call.
FAQ
Frequently asked questions
Does MQTT have built-in security?
Barely. The MQTT specification defines a username and password field and leaves transport security to TLS underneath, but it defines no encryption and no authorisation model of its own. Everything beyond a plaintext password is the broker configuration and the application design, which is where we find most of the problems.
Is a username and password enough for an MQTT broker?
No. A password only proves who connected. Without per-topic authorisation, any authenticated client can usually subscribe to every other device's topics, which is the single most common MQTT finding. You need authentication, TLS and topic-level authorisation together.
Should MQTT ever be reachable from the internet without TLS?
No. Port 1883 is plaintext. If the broker is reachable from the internet on 1883, credentials and all telemetry travel in clear text. Use TLS (port 8883) and, where you can, client certificates for the devices.