Direct answer

Bind each authenticated MQTT principal to the smallest publish and subscribe operations required by its role. A device should normally publish only its own telemetry, events, reported state, and acknowledgements, while subscribing only to its own command or desired-state branches. Deny everything else. Derive tenant and device scope from trusted identity attributes, never from a topic segment supplied by the client.

Scope and non-scope

MQTT authorization answers whether a connected principal may publish to a topic or create a subscription filter. It does not establish device identity, validate payload fields, or enforce authorization after data leaves the broker. Those controls belong to credential provisioning, schema validation, and downstream services.

Broker ACL syntax is vendor-specific. The design below is portable, but variable substitution, rule order, retained-message checks, shared subscriptions, and administrative bypasses must be verified against the chosen implementation.

Build the authorization model first

List principals by behavior rather than organization chart: device, gateway acting for a bounded set of devices, tenant application, platform service, operator, bridge, and broker administrator. For each role, record exact publish topics and exact subscription filters. Keep publishing and subscribing separate; permission to observe a branch must not imply permission to write it.

Use one authoritative mapping from credential to tenant, device, and role. A certificate subject, token claim, or provisioning record may supply those attributes after verification. Reject a connection when the mapping is absent or ambiguous. Do not let a client authenticate as device-42 and then choose device-17 in its topic.

Design topics so policies remain obvious. Given v1/{tenant}/devices/{device}/telemetry, a device rule can interpolate trusted tenant and device values. A command service may publish to the commands branch but should not publish device telemetry. A tenant consumer may subscribe across its tenant, while global analytics needs a distinct, audited role rather than an accidental wildcard.

Implementation steps

  1. Set deny-by-default behavior for publish, subscribe, retained operations, and administrative APIs.
  2. Create a machine-readable matrix with principal role, operation, topic template, and business owner.
  3. Generate broker rules from trusted identity attributes where the product supports it.
  4. Treat broad + and # filters as privileged capabilities; cap fan-out and review owners.
  5. Determine whether authorization checks the requested filter, each resulting topic, or both.
  6. Apply equivalent checks to retained messages, Last Wills, shared subscriptions, bridges, and system topics.
  7. Log denied operations with principal, rule, topic, and reason while redacting sensitive data.
  8. Test policies against a real broker before every rule or topic-schema change.

Negative tests that matter

A device must not publish as another device, subscribe to a sibling, write command topics, or escape its tenant using wildcards. A tenant service must not subscribe above its prefix. An expired or revoked credential must lose access according to the stated revocation window. A bridge must not import topics that bypass local policy. A Last Will must be authorized when CONNECT is accepted, not discovered only after an unclean disconnect.

Also test retained delivery. Some systems check permission when a retained publication is written, others when it is delivered, and secure designs need both boundaries considered. Test policy reload while clients remain connected; a cached decision must not silently survive longer than the security model allows.

Failure modes

Rule order can turn a narrow deny into an ineffective statement after a broad allow. String-prefix matching can confuse similarly named tenants when topic levels are not parsed. Shared-subscription prefixes can evade naive filter checks. Administrative dashboards and HTTP publish APIs may bypass MQTT ACLs. Large wildcard subscriptions can become availability incidents even when legitimately authorized.

Implementation checklist

  • Authentication produces a trusted principal, tenant, device, and role mapping.
  • Publish and subscribe policies are separate and deny by default.
  • No device-controlled value expands its authorization scope.
  • Wildcards, retained messages, wills, bridges, and shared subscriptions are covered.
  • Negative tests run against the actual broker version.
  • Policy changes invalidate or refresh cached decisions.
  • Denials are observable without leaking credentials.
  • Non-MQTT broker APIs enforce equivalent authorization.

Operational evidence

Keep the reviewed authorization matrix, generated broker policy, negative-test results, and a trace from authenticated identity to the final rule decision. Sample denied operations by reason and watch for sudden increases after firmware or policy rollout. Periodically enumerate privileged service and bridge accounts and compare their observed topics with approved scope. An emergency override needs an owner, expiry, audit trail, and post-incident removal check. During incident response, preserve the effective policy version as well as configuration source: troubleshooting the intended template is useless if the broker loaded something different.

Primary sources

The OASIS MQTT 5.0 specification defines topic filters, subscriptions, retained publications, wills, and authorization-related reason codes, but not an ACL language. Pair it with the selected broker’s official authorization documentation and NIST SP 800-207 for decisions based on verified identity and explicit policy rather than network location.