15 Jun 2026 · 3 min read
Your MQTT broker probably trusts everyone
security · mqtt · ot · architecture
If you have been anywhere near industrial data in the last few years, you have heard the pitch for the Unified Namespace. Stop wiring every system to every other system. Put one broker in the middle, let everything publish what it knows and subscribe to what it needs, and the spaghetti turns into a clean, single source of truth. It is a genuinely good idea, and I am a fan.
So I did the honest thing and pointed a man on the wire at one. A broker running a real tank-and-pump simulation, the kind of setup a plant would actually build. I wanted to know whether the modern stack had learned the lesson the old protocols never did.
It had not, and it was easier than the old protocols.
The first thing I looked at was how clients connect. Every single connection in my capture
carried no username and no password, and the broker waved every one through. That is not a
misconfiguration I engineered. It is the default posture of most brokers the day they are
stood up, a setting called allow_anonymous that starts life switched on. There was no
encryption either, so every topic and every value sat on the wire in plain text. Reading
the entire live state of the plant took nothing more than joining the network and asking
for everything.
Then the part that should make you sit up. Publish-subscribe was built to take a message and hand it to everyone who cares about it. So from a throwaway machine, with no credentials, I published one message to the valve command topic. Close the valve. The broker took it without a question and delivered it to every subscriber, including, in a real plant, the controller that acts on commands. My machine was a number the broker had never seen and never checked, and for that moment it had a hand on the plant.
This is the same shape as the pump and the name-brand PLCs earlier in this series. Anyone who can reach the network reads everything and writes what matters. The protocol got newer and the trust model stayed exactly the same, because the convenient way to run a broker, no login and no encryption, is also the insecure way, and convenient is what ships.
There is a twist that makes it worse before it makes it better. A broker is a hub. Everything meets there. One open broker is not read-and-write access to one device, it is read-and-write access to every site publishing into it, which is the entire selling point of the pattern and the entire risk of leaving it open.
And now the better part, because this is where the modern stack earns its keep. Unlike the old protocols, MQTT can defend itself, and the fix is not a network rebuild. Turn anonymous access off and make every client prove who it is. Give each client a rulebook so a tank sensor can publish its own readings and nothing else, which means a hijacked sensor cannot publish a valve command no matter what it pretends to be. Run encryption so the man on the wire reads nothing. If you are on Sparkplug, use its built-in birth-and-death contract so the system notices an imposter. All of that is config and a certificate, not concrete.
So the Unified Namespace does not remove the trust problem. It moves it to a hub and makes the hub convenient to leave open. The consolation, and it is real, is that this door could have said no. I have the full capture, the anonymous connections, and the one-line publish that moved the valve, in the lab write-up. The one-sentence version: the broker asked me for nothing, and it did not have to.
Keep reading
Newsletter
New essays, by email.
SCADA, cloud, AI, and the plant floor — a short email when something new is published. No noise, unsubscribe anytime.


