An MQTT broker that requires authentication by default
The AdminKit Secure MQTT Broker is a planned managed broker that requires credentials for every connection and limits each device to the topics it's allowed to use, aimed at IoT product builders and system integrators who today often find every connected device sharing one set of credentials with access to every topic, so a single compromised device can see or affect far more than it needs to.
Updated October 21, 2026
The problem
MQTT is a lightweight messaging protocol used across IoT deployments, from home sensors to building and factory systems. The protocol itself supports authentication, but doesn’t require it, so it’s common to find brokers running with anonymous access enabled, especially on systems that were set up for a quick proof of concept and never revisited.
An open broker means anyone who can reach it can subscribe to every topic and read whatever is being published, or publish messages of their own. On a broker used for building automation or industrial sensors, that can mean reading data that wasn’t meant to be public, or sending commands a device will act on without question.
Even on brokers that do require a login, it’s common for every connected device to share one set of credentials and have access to every topic, so a single compromised device can see or affect far more than it needs to.
How it works
The plan is for the AdminKit Secure MQTT Broker to require credentials for every connection by default, with no anonymous-access option left enabled. On top of that, per-topic access-control lists would limit each device to publishing and subscribing only to the topics it’s assigned, and anomaly detection would flag publish patterns that look unusual for a given device.
Who it’s for
- IoT product builders who need a broker with authentication and ACLs out of the box, rather than configuring one from scratch.
- System integrators deploying sensors and controls in hotels, clinics, and other buildings.
- Factories and small industrial sites running MQTT alongside other OT protocols.
What exists today, what’s planned
| Capability | Status |
|---|---|
| Check if a broker on a verified asset accepts anonymous connections (mqtt-check) | Free today |
| Managed broker requiring authentication by default | Early access |
| MQTT 3.1.1 and 5 support | In development |
| Per-topic access-control lists | In development |
| Anomalous publish-pattern detection | In development |
The mqtt-check tool only reports whether a broker is reachable and accepts anonymous connections; it does not read or log topic content. The planned broker would be a separate, managed service you’d point devices at, not a filter in front of an existing broker.
Frequently asked questions
Is the Secure MQTT Broker available yet?
No. It is early access / in development. Today you can check whether a broker on an asset you've verified you own accepts anonymous connections, using the free mqtt-check tool.
Does MQTT require authentication by default?
No. The MQTT 5.0 standard supports authentication but doesn't mandate it, so many brokers are deployed with anonymous access enabled, either by default or for convenience.
What's an access-control list (ACL) in this context?
A per-topic rule set that controls which devices can publish or subscribe to which topics, so a temperature sensor, for example, can't publish to a topic that controls a door lock.
Will it support MQTT 5?
The plan is to support both MQTT 3.1.1 and 5, since many existing devices only speak 3.1.1 while newer ones increasingly support 5.
What does 'anomalous publish pattern' mean?
A device suddenly publishing at a very different rate, to different topics, or with different payload patterns than it normally does. Flagging that is planned, not available today.
Want early access to Secure MQTT Broker with Auth and ACLs | AdminKit?
Tell us about your setup and we will reach out when it is ready for you — no spam, no newsletter.