Threat model first
MQTT is often deployed in environments with weak networks and devices that are physically accessible. That means eavesdropping, credential theft, and rogue publishers are real risks.
A security plan starts with a threat model: who can access the network, what data is sensitive, and what happens if a device is compromised.
TLS everywhere
TLS should be the default for all MQTT connections. It protects credentials and data in transit and prevents trivial sniffing on shared networks.
Use modern TLS versions and rotate certificates. If devices are constrained, plan for certificate footprint and update strategy early.
Authentication choices
Username/password is common but often too weak. Client certificates or short-lived tokens are better options, especially for fleets of devices.
Bind identities to device provisioning. Avoid shared credentials across many devices; they make revocation impossible.
Topic ACLs and least privilege
ACLs should restrict both publish and subscribe rights. A thermostat should not subscribe to topics meant for a different building.
Design your topic hierarchy to make ACLs simple. If your topics are messy, your security rules will be messy too.
Broker hardening
Limit anonymous connections, enforce connection limits, and monitor unusual activity. Many attacks are noisy if you are watching.
Separate public and private brokers. If you need a public bridge, isolate it and protect internal topics.
Audit and observability
Log authentication failures, subscription attempts, and unusual publish rates. These signals catch misconfigurations and malicious behavior.
Security is ongoing. Add alerts for suspicious patterns and review them regularly.
Security in product design
Security controls must be usable. If provisioning is too complex, teams will bypass it. Build a provisioning flow that is simple and repeatable.
Document security rules in the same place as topic definitions so teams do not treat them as afterthoughts.