MQTT security guide

Secure MQTT from the device identity to the topic

A production MQTT deployment needs layered controls: TLS, client authentication, explicit ACL authorization, protected secrets, network boundaries, and evidence when something goes wrong.

Explore access controls Review MQTT basics

Threat model

Start with the failure modes MQTT cannot prevent alone

The protocol is intentionally lightweight. Security comes from the deployment choices around it.

Network eavesdropping

Plain MQTT can expose credentials, topic names, and payloads to anyone who can observe the network path.

Client impersonation

Shared credentials and predictable client IDs make it difficult to distinguish a real device from an attacker.

Over-broad topic access

A valid client can still cause damage if it may publish commands or subscribe across unrelated tenants and device groups.

Availability abuse

Connection floods, wildcard subscriptions, retained-message abuse, and reconnect storms can exhaust broker resources.

Security boundary
Security boundary	Credible threat	Primary control	Residual risk
Device	Extracted secrets, cloned firmware, or a stolen unit impersonates a client.	One protected credential per device, secure boot and storage where available, and individual revocation.	A valid compromised device can still perform every action its current policy permits.
Broker	Credential guessing, session takeover, broad subscriptions, and resource exhaustion.	TLS, authentication, client-ID checks, default-deny topic policy, quotas, and audit events.	TLS and ACLs do not correct unsafe payload handling or eliminate availability attacks.
Control plane	An operator account or automation token changes policies, issues credentials, or suppresses evidence.	Strong operator authentication, least-privilege roles, change review, and immutable audit export.	A sufficiently privileged account remains a high-impact target; separate duties and recovery access.
Network	Interception, DNS or route manipulation, scanning, and connection floods reach the endpoint.	Certificate and hostname validation, restricted ingress, segmentation, and rate limits.	Encryption does not hide endpoint metadata or guarantee upstream network availability.

Defense in depth

Build the controls in the right order

01
Encrypt and validate transport
Require TLS 1.2 or newer, validate the broker hostname and certificate chain, and remove plain listener access from production networks.
02
Give every device an identity
Issue independent credentials so one compromised device can be revoked without rotating an entire fleet.
03
Authorize every topic action
Evaluate publish and subscribe separately, bind filters to a device role, and deny access that is not explicitly required.

Rotate and revoke

Track issuance, limit exposure, rotate on schedule or incident, and make revocation fast enough to use.

Constrain the network

Use firewalls, private paths, rate limits, and segmentation so broker access is not broader than the workload requires.

Monitor the control plane

Record failed authentication, denied topics, credential changes, reconnect bursts, and unusual subscription fan-out.

Client authentication

Choose identity strength from device constraints

The strongest scheme is the one the device can store, rotate, validate, and recover safely throughout its lifecycle.

Authentication method
Authentication method	Best fit	Strength	Operational requirement
Unique username and password	Constrained devices and straightforward fleets	Good with validated TLS and strong unique secrets	Secure storage, rate limiting, rotation, and revocation
Client certificate (mTLS)	Managed hardware and high-assurance device identity	Strong cryptographic identity during the TLS handshake	PKI issuance, protected private keys, renewal, and revocation
Short-lived token	Gateways and applications with an identity provider	Scoped and time-limited when validated correctly	Trusted token minting, clock handling, refresh, and audience checks

Executable Mosquitto TLS baseline (replace file paths)

listener 8883
allow_anonymous false
password_file /etc/mosquitto/passwords
acl_file /etc/mosquitto/acl

cafile /etc/mosquitto/certs/ca.crt
certfile /etc/mosquitto/certs/broker.crt
keyfile /etc/mosquitto/certs/broker.key
tls_version tlsv1.2

Executable client verification (synthetic endpoint)

mosquitto_sub \
  -h mqtt.example.invalid -p 8883 \
  --cafile ./ca.crt \
  -u sensor-042 -P 'REPLACE_ME' \
  -i sensor-042-check \
  -t 'factory/shanghai/line-1/sensor-042/command' \
  -d

Least privilege

Make topic policy reviewable

Express the device contract as narrow publish and subscribe filters, then test both allowed and denied topics before rollout.

Sensor device policy

# Mosquitto ACL: username is the unique device identity
pattern write factory/shanghai/line-1/%u/telemetry
pattern write factory/shanghai/line-1/%u/state

# It may receive only its own commands
pattern read factory/shanghai/line-1/%u/command

# Unlisted topics are denied by default

Review publish and subscribe permissions independently.

Bind topic filters to the authenticated device identity.

Add negative tests for sibling devices, command topics, and broad wildcards.

Reuse reviewed templates for devices with the same role.

Audit policy edits and credential changes.

Practice revoking one device without disrupting its peers.

Release gate

Rotate without creating a shared-secret outage

Broker and identity-provider APIs differ. Use this vendor-neutral sequence as an operational runbook, then map each step to your platform.

01
Inventory the identity and blast radius
Record the device owner, policy, last use, secret type, issue time, expiry, and a tested recovery path.
02
Issue a second credential with bounded overlap
Keep the old credential active only for a short migration window. Give the replacement the same or narrower topic policy, never broader access.
03
Prove the new path before cutover
Reconnect with full TLS validation, confirm permitted traffic, run negative topic tests, and capture the new identity in logs.
04
Revoke the old credential and terminate sessions
Disable the server-side identity, disconnect existing sessions, and verify that reconnect and publish attempts fail.
05
Close the evidence loop
Remove the old secret from devices and stores, record completion, and alert on any later use of the revoked identity.

Compromise path: revoke first, investigate second

For a suspected theft, skip planned overlap: disable the identity, end active sessions, preserve broker and control-plane logs, narrow affected policies, issue a replacement only to a re-established device, and watch for reuse.

Operations checklist

Production MQTT security baseline

Use the release gate below, then download the full printable checklist for transport, identity, authorization, rotation, network, monitoring, and incident response.

TLS is mandatory

Reject invalid certificates, remove insecure fallbacks, and verify device clocks and trust stores.

Secrets are device-scoped

No factory-wide passwords in firmware, spreadsheets, source code, or copied configuration bundles.

Policies are tested

Expected traffic succeeds and cross-device, cross-tenant, and unauthorized command paths fail.

Incidents are actionable

Operators can identify, revoke, investigate, and replace a compromised identity with a documented playbook.

Download the production checklist

Primary sources

Standards and implementation references

Protocol facts and examples in this guide are grounded in standards bodies and implementation owners. Product capabilities are stated separately below.

What RunMQTT currently provides

Private RunMQTT brokers expose TLS and secure WebSocket endpoints, generated per-device username/password credentials, reusable publish/subscribe topic policies, policy testing, and immediate access removal when a device is deleted. The product does not currently expose customer-managed mTLS identities, external token authentication, network allowlists, or in-place credential rotation in the dashboard; replace a credential by creating and validating a new device identity, then deleting the old one. The public broker is a shared testing sandbox and is not a production security control.

MQTT security FAQ

Does MQTT include encryption by default?

No. MQTT defines messaging behavior, while TLS protects the transport. A plain connection on port 1883 can expose credentials, topics, and payloads to the network.

Is TLS enough to secure an MQTT deployment?

TLS protects data in transit and authenticates the broker, but it does not decide which topics a valid client may use. Pair TLS with unique identity, topic authorization, secure credential storage, and monitoring.

Can username and password authentication be secure?

Yes, when every device receives a unique strong secret, the connection validates TLS, secrets are stored safely, failed attempts are limited, and rotation and revocation are operationally possible.

How should MQTT topic permissions be modeled?

Separate publish from subscribe rights and grant only the narrow topic filters required by a device role. Avoid broad # access for field devices and test every policy against expected and denied topics.

Related MQTT resources

Apply the security model to a working client, then inspect how MQTT fits with other real-time technologies.

Start with the failure modes MQTT cannot prevent alone

Network eavesdropping

Client impersonation

Over-broad topic access

Availability abuse

Build the controls in the right order

Encrypt and validate transport

Give every device an identity

Authorize every topic action

Rotate and revoke

Constrain the network

Monitor the control plane

Choose identity strength from device constraints

Make topic policy reviewable

Rotate without creating a shared-secret outage

Inventory the identity and blast radius

Issue a second credential with bounded overlap

Prove the new path before cutover

Revoke the old credential and terminate sessions

Close the evidence loop