MQTT is a lightweight publish and subscribe messaging protocol used by devices and applications to exchange small messages over unreliable or low-bandwidth networks. It uses a broker to route topics between clients, with optional authentication, TLS, and retained messages for device communication.
What MQTT is designed to do
MQTT is a lightweight messaging protocol built for small, efficient exchanges between devices and applications over unreliable or low-bandwidth networks. Its publish and subscribe model lets senders push messages to a broker without knowing the final consumers in advance.
This design makes MQTT especially useful when endpoints are constrained, intermittently connected, or distributed across many sites. The protocol offloads routing to the broker, which simplifies client logic but also makes broker trust, availability, and topic design central to the overall system.
How MQTT messaging works
In MQTT, clients publish messages to topics and subscribe to the topics they care about. The broker receives each publication, matches it to subscriptions, and forwards it to the right clients. That separation between publishers and subscribers is what makes the protocol flexible for telemetry, device control, and event delivery.
Because the broker mediates the relationship, MQTT systems depend on clear topic naming, stable broker behavior, and predictable client reconnection. Retained messages can help late-joining clients recover the latest state, but they also mean the broker may persist data beyond the moment it was first sent.
Security characteristics of MQTT deployments
MQTT is often deployed with TLS to protect data in transit and with authentication to limit who can connect, publish, or subscribe. Those controls matter because the broker is a shared trust point, and weak authentication or overly broad topic permissions can expose telemetry, commands, or operational state.
The protocol itself does not guarantee confidentiality or authorization. Security depends on how the broker is configured, how topics are partitioned, and whether publishers and subscribers are constrained to only the data they actually need. In practice, MQTT security is usually as strong as the broker policy model behind it.
Operational trade-offs in low-bandwidth and unreliable networks
MQTT is popular because it stays efficient when bandwidth is limited and connections are unstable. Small packets, lightweight session handling, and asynchronous delivery reduce overhead compared with heavier request-response protocols.
That efficiency comes with trade-offs. Reliable delivery features, retained state, and long-lived sessions can increase broker load and complicate recovery if devices reconnect at scale. Where many devices share one broker, resilience planning becomes part of the protocol design rather than an afterthought.
Risk and Threat Considerations
MQTT concentrates trust in the broker, so a weak broker configuration can expose message contents, topic structure, device telemetry, and command channels to unauthorized parties. The protocol is also attractive to attackers because connected devices often have limited defense depth and may accept long-lived credentials or permissive topic access.
Failure mechanism: An attacker who obtains broker access, abuses weak topic authorization, or intercepts unprotected traffic can read, inject, or replay messages across subscribed clients. If retained messages or persistent sessions are mismanaged, stale or malicious data can survive long enough to affect later reconnects.
Impact: Compromise can lead to device manipulation, telemetry tampering, operational disruption, credential exposure, or misuse of connected systems that rely on broker-delivered commands or state updates.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.OC-01 — Organizational Context | MQTT deployment depends on broker context, trust boundaries, and system ownership. |
| Recommendation — Define broker ownership, topic trust boundaries, and recovery expectations for MQTT traffic. | ||
| NIST SP 800-53 Rev 5 | AC-3 — Access Enforcement | MQTT security hinges on enforcing who may publish or subscribe to specific topics. |
| IA-2 — Identification and Authentication (Organizational Users) | MQTT clients need authenticated access when brokers mediate shared operational messages. | |
| SC-8 — Transmission Confidentiality and Integrity | MQTT commonly relies on TLS to protect messages in transit over untrusted networks. | |
| Recommendation — Enforce topic-level publish and subscribe permissions at the broker. Require strong client authentication before allowing broker connections. Protect MQTT traffic in transit with encrypted and integrity-protected channels. | ||
Practitioner Guidance
Why practitioners should care: MQTT is often adopted for convenience and scale, but the broker becomes a high-value control point that must be treated as part of the security boundary. Use NIST Cybersecurity Framework 2.0 to anchor broker governance, inventory, and recovery expectations around the messaging path.
What to watch for: Review whether authentication, TLS, and topic-level authorization are consistently enforced across every client type, especially devices that reconnect frequently or operate in partial trust environments. When MQTT is used in broader connected-systems architectures, NIST AI Risk Management Framework can also be useful where telemetry or control flows support AI-enabled decisions.
Practitioner takeaway: The safest MQTT deployments are the ones that assume the broker is both a routing engine and a security control point, not just a transport component.
Related resources from NHI Mgmt Group
- What do teams get wrong when they treat telemetry transport as a pure data engineering problem?
- How should security teams choose a log transport for identity and security telemetry?
- What is the difference between strong message encryption and transport-layer security in mobile apps?
- What is the difference between syslog and OpenTelemetry for telemetry transport?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org