MQTT

Expanded Definition

MQTT is a publish and subscribe messaging protocol designed for constrained environments where bandwidth, power, and latency matter. In NHI security, it is important because devices, gateways, and automation agents often use MQTT to move operational messages, but also to carry tokens, certificates, and other non-human identity material.

Its security model is not inherent to the protocol alone. Practitioners must layer broker authentication, topic-level authorization, and transport encryption to avoid treating MQTT as a trusted internal bus. Guidance varies across vendors on how much policy should live in the broker versus the surrounding IAM stack, but the operational principle is consistent: MQTT topics should be scoped like resources, not treated like free-form channels. For broader governance context, the NIST Cybersecurity Framework 2.0 is a useful external anchor for access control and communications protection.

The most common misapplication is exposing a broker with weak authentication and broad topic permissions, which occurs when teams assume device traffic is low risk because it is small and machine generated.

Examples and Use Cases

Implementing MQTT rigorously often introduces operational overhead, because every publisher, subscriber, and broker path must be authenticated and reviewed, requiring organisations to balance device agility against tighter authorization and certificate lifecycle management.

• Industrial sensors publish telemetry to a broker, while only a specific maintenance service account can subscribe to a restricted diagnostics topic.
• A fleet management platform uses MQTT to deliver commands to remote devices, but each command path is bound to a unique identity and short-lived credential.
• A CI/CD system publishes deployment events to MQTT, and build agents consume them only after broker-side policy confirms the source and topic scope.
• IoT gateways forward data into a central broker, with mutual TLS and per-topic ACLs preventing lateral movement between tenants.

These patterns align with NHI governance guidance in Ultimate Guide to NHIs, especially where device identities and secrets are distributed across large fleets. At the standards level, the NIST Cybersecurity Framework 2.0 supports the same idea through controlled communications and least-privilege access.

Why It Matters in NHI Security

MQTT matters because it often becomes the transport layer through which machine identities prove who they are, receive instructions, and exchange sensitive operational data. When broker access is overly broad, attackers can subscribe to sensitive topics, inject messages, or replay credentials into downstream systems. NHI Management Group research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is a strong reminder that messaging security and identity security are inseparable.

MQTT also becomes a governance issue because secrets may travel through edge devices, brokers, and automation platforms that are difficult to inventory. That makes visibility, rotation, and offboarding critical. In practice, teams should treat every MQTT principal as an NHI with a defined owner, scope, and revocation path, rather than as an anonymous device endpoint. Ultimate Guide to NHIs is especially relevant here because it frames lifecycle controls as a core defense, not an afterthought.

Organisations typically encounter MQTT risk only after a broker compromise, at which point topic abuse, stale credentials, and exposed device identities become operationally unavoidable to address.

Related resources from NHI Mgmt Group

• What breaks when MQTT TLS settings are missing the right certificate files?
• Should teams use server-only TLS or mutual TLS for MQTT monitoring?
• MQTT Over TLS