Is MQTT secure? The protocol itself provides only the hooks for security, a username and password field and support for running over TLS, and it is exactly as secure as the deployment around it. This article explains what MQTT does and does not protect, which threats actually hit real systems, the myths that cause trouble, and the layers that turn an MQTT setup into a secure one.
What MQTT Itself Provides
MQTT was designed as a lightweight messaging protocol, and its specification deliberately leaves most security to other layers. Out of the box you get:
- A username and password field in the CONNECT packet, sent as plain bytes.
- MQTT 5 enhanced authentication hooks (an authentication method and AUTH packets) for challenge-response schemes the broker implements.
- Reason codes that let the broker say "bad credentials" or "not authorized".
- Transport independence, so MQTT can run over TLS or secure WebSockets.
What the protocol does not provide on its own:
- No encryption. Without TLS, every topic, payload and password is readable on the wire.
- No authorization model. Which client may use which topic is up to the broker.
- No payload integrity or signing. A message carries no proof of who created it beyond the connection it arrived on.
- No rate limiting or abuse protection. That is a broker feature.
The OASIS MQTT specification even has a security chapter that frames these as implementation responsibilities. So the honest answer to "is MQTT secure" is: MQTT is securable, and security is a property of the broker, the clients and the network design.
The Threats That Actually Matter
| Threat | How it happens | Primary protection |
|---|---|---|
| Eavesdropping | Traffic on port 1883 captured on Wi-Fi, ISP or cloud network | TLS on 8883 / 8084 |
| Credential theft in transit | Password read from an unencrypted CONNECT | TLS with certificate verification |
| Open brokers | Broker exposed to the internet with anonymous access | Authentication, no anonymous production access |
| Credential extraction from devices | Password hard-coded in firmware or stored in plain flash | Per-device credentials, encrypted storage |
| Impersonation | Attacker connects with a stolen or shared client ID | Client IDs bound to credentials |
| Cross-tenant access | Weak isolation on a shared broker | Tenant isolation |
| Malicious commands | Anyone able to publish to a command topic | Authorization, command validation on device |
| Denial of service | Connection floods, message floods, brute-force logins | Quotas, flood protection, IP blocking |
Scans for exposed brokers regularly find systems on port 1883 with anonymous access, leaking sensor data and sometimes accepting commands. Those are configuration failures, not protocol vulnerabilities, which is why most of the real work is operational. See exposed MQTT brokers for how they are found and closed.
Common Myths About MQTT Security
"MQTT is insecure because it sends passwords in plain text."
It sends them in plain text inside the MQTT layer, the same way HTTP Basic authentication does. Over TLS the whole connection is encrypted, including the CONNECT packet. The problem is running MQTT without TLS, not MQTT itself.
"Port 1883 is fine inside our network."
Internal networks get compromised, Wi-Fi gets sniffed and "temporary" port forwards become permanent. Treat every network as untrusted and use TLS everywhere you can. Reserve plain 1883 for public test data that you would be happy to see anywhere, like the demo traffic on the free public MQTT broker.
"A long random client ID is a secret."
Client IDs appear in logs, dashboards and topic paths. They identify a client; they do not authenticate it. Security comes from the credential the client ID is bound to.
"TLS makes payloads secure end to end."
TLS protects each hop between a client and the broker. The broker sees the payload in plain form. If you need end-to-end confidentiality from device to application, add MQTT payload encryption on top.
"Nobody would bother attacking my sensors."
Automated scanners do not care what your sensors measure. They look for open ports and default credentials, and an exposed broker can be used as a foothold or as a free relay.
The Layers That Make MQTT Secure
- Transport encryption. TLS 1.2 or newer on port 8883, or secure WebSockets on 8084 for browsers, with certificate verification enabled in every client.
- Authentication. No anonymous access to production data. Unique credentials per device and service.
- Identity binding. Client IDs tied to credentials so one client cannot impersonate another.
- Isolation and authorization. Separate tenants and environments; restrict topics where your broker supports it, and design topic trees with identity and direction visible. The MQTT ACL guide covers both approaches.
- Abuse protection. Connection and message quotas, flood protection and blocking of brute-force login attempts.
- Device hardening. Encrypted credential storage, Secure Boot, disabled debug ports, signed firmware updates.
- Operations. Credential rotation, monitoring of connection state and anomalies, and a plan for revoking a compromised device.
How a Managed Broker Closes the Gaps
Several of those layers are broker-side, and they are exactly the parts that self-hosted deployments most often get wrong: certificates expire, anonymous access stays on after a test, a password file is shared by every device. A managed MQTT broker takes those responsibilities over.
Here is how ConnectMQ maps to the layers above:
| Layer | ConnectMQ |
|---|---|
| Transport encryption | TLS on 8883 and secure WebSocket on 8084 (path /mqtt) with a Let's Encrypt certificate |
| Authentication | Generated username and password per broker credential set |
| Identity binding | Client IDs bound to issued credentials |
| Isolation | Multi-tenant isolation between customers; Dedicated plan for an isolated cluster; BYOC in your own cloud account |
| Abuse protection | Per-plan quotas, flood protection, IP blocking after repeated failed logins |
| Visibility | Dashboard, live topic explorer and $SYS/broker/connection/{clientId}/state for per-client connection state |
ConnectMQ does not enforce per-topic ACLs, so its security boundary is the tenant and the broker: if two groups of clients must not see each other's data, give them separate brokers, and keep untrusted users behind your own backend rather than handing them broker credentials. Device hardening and credential rotation remain your responsibility, as they would with any broker; the guides on secure MQTT credentials on devices and MQTT security best practices cover them.
Quick Self-Assessment
Answer these about your current deployment:
- Does any production client connect on port 1883?
- Does any client disable certificate verification?
- Do two or more devices share one credential?
- Is any credential hard-coded in a firmware image or a public repository?
- Can you revoke a single device in minutes without affecting others?
- Would you notice if a device started connecting from an unexpected place or publishing at ten times its normal rate?
A "yes" to any of the first four or a "no" to either of the last two marks the place to start.
Get Started with ConnectMQ
Get TLS, authentication, identity binding, tenant isolation and abuse protection from day one with a cloud MQTT broker that is managed for you. Create a free Serverless broker at app.connectmq.com, no credit card required, and connect your first device over port 8883 in minutes.
Frequently Asked Questions
Is MQTT secure without TLS?
No. Without TLS, usernames, passwords, topics and payloads can be read by anyone who can capture the traffic. Use port 8883 or secure WebSockets for anything beyond public test data.
Is MQTT more or less secure than HTTP?
They are comparable. Both rely on TLS for encryption and on the server for authentication and authorization; neither is secure in plain-text form.
Does MQTT 5 improve security?
MQTT 5 adds enhanced authentication, re-authentication and richer reason codes, which make secure designs easier to build and debug. It does not add encryption by itself.
Is a public MQTT broker safe to use?
For learning and demos with non-sensitive data, yes. Public brokers are readable by everyone, so production data belongs on a private broker with credentials and TLS.
