01 / Field notes
Executive Summary
An MQTT broker can require a valid login and still give every connected device excessive access. A temperature sensor might be allowed to publish its reading but should not gain permission to send another device's commands or subscribe to private telemetry from the entire installation.
Mosquitto's documentation explicitly separates authentication from topic access control. MQTT 5.0 defines protocol behavior including subscriptions and retained messages, but the application still needs an appropriate authorization policy. [1][2] The useful review unit is a client, an action and a topic—not simply whether the connection succeeded.
This guide uses a private test broker and fictional sensors. It does not instruct readers to discover or connect to exposed brokers belonging to other people.
02 / Field notes
Prerequisites / Lab Setup
Use a broker you administer in an isolated test environment. Create two device identities and one read-only dashboard identity. Use invented telemetry with no location or personal data. Record broker version, listeners, authentication method and the exact access-control mechanism in use.
Keep credentials out of command history, screenshots and shared examples. Consult the broker's supported secret-handling method and current configuration documentation. Do not expose the test broker to the public internet for convenience. If production devices cannot be interrupted, perform a read-only policy review before planning a controlled change.
03 / Field notes
Technical Analysis
Define permissions in both directions
A publisher sends to a topic; a subscriber receives matching messages under the broker's policy. A role that needs one direction does not automatically need the other. Start by describing the business operation, then translate it into the broker's documented authorization syntax.
| Fictional identity | Intended permission | Operation that should fail |
|---|---|---|
| Sensor A | Publish its own temperature reading | Publish Sensor B's reading or a control command |
| Sensor B | Publish its own temperature reading | Subscribe to unrelated private telemetry |
| Dashboard | Read the approved sensor readings | Publish device commands |
| Maintainer | Perform a specific maintenance action | Retain administrator rights after the task ends |
Topic hierarchy can help organize policy, but naming alone does not enforce it. A path containing a device ID is not proof that the authenticated client owns that ID. Bind allowed topics to the trusted client identity using the broker's supported controls and test the effective result.
Review wildcards and default behavior
Broad subscriptions can cover more data than an application actually needs. Inspect wildcard rules and default allow or deny behavior in the selected broker and plugin. A narrow rule on one listener does not establish the behavior of another listener with different settings.
Mosquitto 2.0 and later require an explicit authentication choice, but that choice can still permit anonymous access if configured that way. [1] Version alone therefore does not prove the intended security posture. Review the running configuration and test each relevant entry point.
Include retained and queued data in the test
MQTT's retained-message mechanism can make a previous message available to a later subscription under the protocol's rules. Session-related behavior can also affect delivery after reconnecting. [2] Your authorization review should cover reconnects and existing message state, not only a fresh connection with an empty broker.
In the fictional exercise, publish a harmless retained status message, then connect the dashboard and verify expected delivery. Repeat with an identity that should not receive that topic. After changing access, test the documented revocation behavior and reconnect path. Do not infer success from a user interface that simply stopped refreshing.
Keep command topics separate in the policy review even if the same application displays telemetry and controls. A stale reading is an availability issue; an unauthorized command can change physical behavior. Use simulated devices for command tests so a mistaken permission cannot operate a real lock, heater or machine.
Give each device a lifecycle
Shared credentials make it difficult to remove one device without affecting every device. Where the platform supports it, use distinct identities and a documented provisioning and retirement process. Record which service owner can revoke a lost or replaced device and how remaining devices will continue operating.
As installations grow, the future challenge is policy maintenance across many devices and integrations. Generate policies from an accountable inventory where practical, but review the generated scope. Automation should reduce inconsistent permissions, not replicate an overly broad template everywhere.
04 / Field notes
Mitigation / Defense
- Describe each identity's publish and subscribe needs before writing access rules.
- Test cross-device publishing, unauthorized subscriptions and read-only identities.
- Review every listener, wildcard and default rule in the effective broker configuration.
- Include retained messages, reconnects and permission changes in controlled tests.
- Retire device credentials and policies when the device or integration is removed.
Use the IoT inventory worksheet to connect identities with physical devices. Use machine-identity lifecycle guidance for the broader ownership and credential process, while checking which mechanisms your broker actually supports.
05 / Field notes
References
Sources checked 28 October 2026. The MQTT reference is OASIS MQTT 5.0; broker authorization details are implementation-specific. Sensor identities and topics are fictional. The article presents no internet scanning, real-device commands or claim that a password alone makes a deployment safe.
- Authentication methods ↗Eclipse Mosquitto · accessed 2026-10-28
- MQTT Version 5.0 ↗OASIS · accessed 2026-10-28
Questions readers ask
Does requiring a password secure every MQTT topic?
No. Authentication establishes a client identity; topic authorization determines what it may publish and receive. Configure and test both.
Are topic names a safe place for secrets?
No. Treat names as routing metadata that may appear in logs and monitoring. Do not embed passwords, tokens or unnecessary personal information in them.
About this edition: Articles include AI-assisted drafting and editing. Conceptual illustrations are not evidence of a real incident or product test. Read our sourcing and review standards.
Research improves with scrutiny. Send a correction with the article URL and supporting evidence.
Contact the editorial desk ↗
