A message broker that routes publish and subscribe traffic between devices and applications using the MQTT protocol. In IoT ecosystems, it often becomes a central control point for telemetry and commands. If broker authentication, topic authorization, or transport security is weak, the broker can become a direct path to device compromise.
Expanded Definition
An MQTT broker is the intermediary that receives published messages, filters them by topic, and delivers them to subscribed clients. In NHI security, that broker is not just a transport component; it is a policy enforcement point that decides which devices, services, and AI agents can speak to one another.
Definitions vary across vendors when brokers are embedded in edge platforms, IoT hubs, or managed messaging services, but the security question is the same: who can authenticate, what topics they can access, and whether the channel is protected end to end. MQTT in practice should be evaluated alongside NIST Cybersecurity Framework 2.0 for access control and resilience expectations, and against the broader NHI lifecycle guidance in Ultimate Guide to NHIs.
The broker becomes especially sensitive when service accounts, API keys, or device certificates are reused across fleets, because a single compromise can create broad publish and subscribe abuse. The most common misapplication is treating the broker as a simple plumbing layer, which occurs when teams enable default credentials or topic wildcards without explicit authorization boundaries.
Examples and Use Cases
Implementing an MQTT broker rigorously often introduces operational overhead, requiring organisations to weigh low-latency device messaging against tighter identity controls, certificate management, and topic governance.
- A building automation platform uses one broker to route temperature telemetry from sensors and command messages to controllers. The broker must verify device certificates and restrict write access to command topics.
- A manufacturing environment segments brokers by plant or line so that a compromised device cannot publish to unrelated systems. This reduces blast radius but increases certificate rotation and policy administration burden.
- An edge analytics service uses an MQTT broker to collect events from gateways, then forwards only approved topics to cloud services. This pattern aligns with the identity and lifecycle discipline described in the Ultimate Guide to NHIs.
- A healthcare device fleet authenticates through mutual TLS and topic-level ACLs so that monitoring applications can subscribe to status events without gaining command privileges. That control model is consistent with NIST Cybersecurity Framework 2.0 outcomes for access governance.
In each case, the broker is effectively an identity junction, not just a data relay.
Why It Matters in NHI Security
MQTT brokers matter because they concentrate trust at the exact point where machines exchange operational data, and that makes weak authentication or topic authorization immediately dangerous. NHIMG reports that 97% of NHIs carry excessive privileges, which is a useful warning sign for broker deployments where devices, gateways, and service accounts often accumulate broad publish rights over time.
When a broker is misconfigured, attackers can inject false telemetry, issue unauthorized commands, or pivot laterally across fleets that were assumed to be segmented. This is why broker security must be treated as part of the NHI control plane, with strong secrets handling, certificate-based authentication, least-privilege topic design, and regular review of dormant credentials. The broader risk picture in Ultimate Guide to NHIs shows how quickly secret sprawl and excess privilege become operational failures rather than theoretical issues.
Organisations typically encounter broker security as a business problem only after a device fleet starts misbehaving or command traffic is abused, at which point MQTT broker governance becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and OWASP Agentic AI Top 10 address the attack and risk surface, while NIST CSF 2.0, NIST Zero Trust (SP 800-207) and NIST AI RMF set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Broker auth and topic ACLs map to secret and credential management risk. |
| NIST CSF 2.0 | PR.AC-4 | MQTT brokers are access enforcement points for machine identities. |
| NIST Zero Trust (SP 800-207) | SC-7 | Broker traffic should be segmented and verified under zero trust principles. |
| NIST AI RMF | If AI agents use MQTT, broker trust becomes part of AI risk governance. | |
| OWASP Agentic AI Top 10 | Tool-using agents may abuse broker access if commands are over-permissive. |
Treat broker channels as untrusted and enforce segmentation plus continuous verification.
Related resources from NHI Mgmt Group
- How should security teams govern third-party access when OAuth is abstracted away by a broker?
- What breaks when an app relies on a hidden token broker for external data access?
- Why do broker ACLs often fall short for real-time data governance?
- What breaks when broker and partner access is not lifecycle-managed?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on August 26, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
