Mqtt Security

MQTT Security

Client Authentication

MQTT brokers can verify client identity through three mechanisms, listed from weakest to strongest:

Client IDs

• All MQTT clients must provide a client ID
• The client ID links subscriptions to the client and TCP connection
• Client IDs must be unique; use them for basic identification, not as a sole authentication factor

Username and Password

• Brokers can require a valid username/password before permitting connections
• Credentials are transmitted in cleartext without transport encryption -- always combine with TLS
• The username can also be used to restrict access to topics
• This is the most common authentication method

x509 Client Certificates

• The most secure authentication method, but the most complex to deploy
• Requires provisioning and managing certificates on every client
• Best suited for a small number of clients requiring high assurance
• Provides mutual authentication between client and broker

Topic Access Control

• Restrict which clients can subscribe to and publish on specific topics
• Use the username as the primary access control identifier
• The client ID can serve as a secondary control mechanism
• Apply least-privilege: grant only the specific topics each client needs

Data Protection

TLS Transport Encryption

• TLS encrypts the entire MQTT connection, including headers, topic names, and payload
• This is a TCP/IP-level protection, not MQTT-specific
• Protects all parts of the MQTT message, not just the payload
• Requires TLS client support, which may not be available on constrained IoT devices

Payload Encryption

• Application-level encryption of the message payload only
• Provides end-to-end encryption (client to client), not just client to broker
• Does not require broker configuration or support
• Does not protect credentials (username/password) on the connection itself
• Use when TLS is not feasible on constrained devices or when end-to-end confidentiality is required

Choosing Between TLS and Payload Encryption

For maximum security, use both: TLS for transport and payload encryption for end-to-end confidentiality.

Implementation Checklist

• TLS is enabled on all broker listeners
• Client authentication is required (username/password or x509 certificates)
• Credentials are never transmitted without TLS
• Topic ACLs restrict publish/subscribe access per client
• x509 certificates are used for high-assurance clients
• Payload encryption is used when end-to-end confidentiality is required
• Client IDs are unique and tracked
• Default/anonymous access is disabled on production brokers

References

• MQTT v5.0 OASIS Standard — Section 5: Security
• OWASP MQTT Security Guide
• OWASP Transport Layer Security Cheat Sheet