Skip to content

Topic ACLs

MQTT topic-based access control (TAC) is a critical mechanism for enforcing granular permissions on publish/subscribe operations. By restricting client access to specific topics, administrators can prevent unauthorized data exposure, ensure compliance with privacy policies, and mitigate attack vectors like topic enumeration or data interception. This section explains how to implement fine-grained topic permissions using MQTT brokers and best practices for securing topic hierarchies.

Core Concepts of Topic-Based Access Control

Publish/Subscribe Operations

  • Publish: Clients send messages to specific topics. Access control ensures only authorized clients can publish to a topic.
  • Subscribe: Clients request to receive messages from specific topics. Access control ensures only authorized clients can subscribe to a topic.

Topics and Hierarchy

MQTT topics are hierarchical strings separated by slashes (e.g., sensors/temperature). Brokers enforce access rules based on: - Exact topic matches (e.g., sensors/temperature) - Wildcards (+ for single-level wildcards, # for multi-level wildcards)

Access Control Lists (ACLs)

ACLs define which clients can: - Subscribe to a topic - Publish to a topic - Use wildcards for subscriptions/publishes

Implementing Topic-Based Access Control

Broker Configuration (Mosquitto Example)

Mosquitto uses an acl_file to define topic permissions. Example configuration:

acl_file /etc/mosquitto/acl.conf
acl_anonymous false

In acl.conf: 

allow publish client1 user1 sensors/temperature
allow subscribe client1 user1 sensors/temperature
deny subscribe client2 user2 sensors/pressure

Example: Restricting Wildcard Access

To prevent unintended wildcard subscriptions: 

allow subscribe client1 user1 sensors/# 
deny subscribe client2 user2 sensors/pressure

MQTT 5.0 Access Control

MQTT 5.0 introduces topic-based access control via the Access flag in CONNECT packets. Example: 

mosquitto_sub -h broker -t "sensors/temperature" -u user1 -P pass1 --will-topic "sensors/status"

Security Considerations

Authentication Before Authorization

Always require clients to authenticate (e.g., username/password, TLS) before applying ACLs. Without authentication, attackers can bypass access controls.

Wildcard Risks

  • + allows single-level wildcards (e.g., sensors/+/humidity)
  • # allows multi-level wildcards (e.g., sensors/#)
  • Overuse of wildcards can inadvertently grant access to sensitive topics. Restrict wildcard usage to trusted clients.

MQTT 5.0 Best Practices

  • Use MQTT 5.0 for granular access control (e.g., ACCESS_READ, ACCESS_WRITE).
  • Combine with TLS to encrypt topic traffic and prevent eavesdropping.

Best Practices

  • Audit ACLs Regularly: Ensure rules align with current security policies and user roles.
  • Limit Wildcard Use: Avoid broad wildcards unless necessary.
  • Combine with TLS: Encrypt all MQTT traffic to protect topic data in transit.
  • Use Role-Based ACLs: Group clients by roles (e.g., admin, sensor, user) to simplify permission management.

Key takeaways

  • Topic-based access control (TAC) restricts publish/subscribe operations to specific topics.
  • Configure ACLs in brokers like Mosquitto to define granular permissions.
  • Use MQTT 5.0 for advanced access control features like topic-level permissions.
  • Always enforce authentication before applying ACLs and limit wildcard usage to mitigate risks.