MQTT Connected Billions of IoT Devices. The Broker Still Holds the Authority.

Vendor and Product Reality

MQTT's vendor landscape is unusually broad for a protocol of its age. The OASIS MQTT Technical Committee maintains the v3.1.1 (ISO/IEC 20922) and v5 specifications. The reference Eclipse Paho client libraries cover C, Java, Python, JavaScript, Go, and a dozen other languages and are the de facto starting point for new device implementations. Eclipse Mosquitto is the canonical open-source broker, ubiquitous in development, hobbyist, and small-fleet production deployments. HiveMQ and EMQX are the dominant commercial broker vendors, with HiveMQ targeting industrial and automotive customers (BMW, Audi, Mercedes-Benz Connected Vehicle, Liebherr) and EMQX targeting massive-scale telecom and consumer IoT. AWS IoT Core, Azure IoT Hub, and the various successors to Google Cloud IoT Core integrate MQTT into managed cloud back ends. Sparkplug B, a payload specification published by the Eclipse Foundation, layers a state-aware data model on top of MQTT for industrial automation use cases.

The protocol's wire-level shape has remained stable across versions. Clients connect to a broker, authenticate (typically via TLS client certificates, username/password, or platform-specific SAS tokens), then PUBLISH to topics or SUBSCRIBE to topic filters. The broker matches incoming PUBLISH packets against active subscriptions and forwards the payload to matching subscribers. Quality-of-service levels control delivery guarantees: QoS 0 (at most once), QoS 1 (at least once), QoS 2 (exactly once). MQTT v5 added user properties (key-value metadata on each packet), shared subscriptions (load balancing across subscriber groups), enhanced authentication exchanges, message expiry intervals, response topics for request/response patterns, and reason codes that disambiguate failure modes. These are real ergonomic improvements; they did not alter the protocol's authority shape.

The commercial maturity is significant. MQTT brokers run inside automobiles, oil-and-gas SCADA systems, factory-floor PLC networks, smart-meter back ends, hospital telemetry systems, and the bulk of consumer-grade IoT. The protocol is well-understood, the tooling is mature, and the operational patterns are documented. The gap analyzed below is not a quality criticism; it is a description of where authority sits in a protocol that was deliberately designed to be small.

The Architectural Gap

MQTT's authority is two-layered and both layers are external to the payload. The first layer is transport authentication: TLS, mutual-TLS, SASL mechanisms, or proprietary token schemes establish that the connecting client is who it claims to be. The second layer is broker-side authorization: an access-control list, a plugin policy engine, or a managed-service policy document declares that this authenticated client may publish to those topics and subscribe to these. Both layers terminate at the broker. Once the broker has accepted a PUBLISH packet, the payload bytes flow to subscribers without any protocol-level statement about what those bytes mean, who attests to them, or what governance regime they were produced under.

Rules do not ride in the payload. A temperature reading from a calibrated medical-device sensor and a temperature reading from a hobbyist weather station look identical to MQTT once both have been authorized to publish to their respective topics. There is no protocol slot for "this reading was produced under FDA-compliant calibration," "this reading is governed by the operator's quality policy," or "this reading must not propagate beyond the EU data-residency boundary." Such metadata can be jammed into JSON payload fields or, in MQTT v5, into user properties, but those conventions are bilateral negotiations between publishers and subscribers, not protocol-level guarantees the broker enforces or that survive store-and-forward through intermediate brokers.

The broker-centric topology compounds the problem. Every message traverses the broker. If the broker is compromised, every message is suspect. If the broker is unavailable — a non-trivial concern for edge deployments with intermittent connectivity — communication halts. Bridging brokers in hierarchical or geo-replicated topologies works at the transport level but does not propagate authority context: a message bridged from a regional broker to a central broker arrives stripped of any policy state the regional broker enforced. Sparkplug B addresses some of this by imposing a strict topic namespace and a state-aware payload, but it does so by standardizing convention, not by giving the protocol cryptographic governance primitives.

Topic namespace governance is similarly fragile. Topics are forward-slash-delimited strings whose semantics are entirely conventional. In a small deployment a single team curates the namespace by discipline. In a large multi-tenant deployment — a manufacturing conglomerate, a smart-city platform, a cross-organizational supply-chain telemetry system — the namespace drifts. Different teams collide on prefixes, retained messages accumulate under abandoned topics, deprecated structures linger because no protocol mechanism revokes them. The broker can refuse PUBLISH from unauthorized clients, but the broker cannot validate that the message claims to be what its topic implies. The namespace is a shared convention without structural enforcement.

What the Memory-Native Protocol Primitive Provides

The Adaptive Query memory-native protocol primitive embeds routing authority and governance into the payload itself. Each observation carries a cryptographic identity descriptor naming the credentialing authority under which it was produced, a governance envelope expressing the policy regime the observation operates under (data-residency scope, attestation class, retention rules), routing predicates declaring which consumer scopes are eligible to receive it, and a continuity anchor tying the observation to a hash chain that downstream consumers verify to detect revocation. The payload is self-describing in the structural sense that matters: a consumer can verify the observation's authority and governance without trusting the broker that delivered it.

Routing becomes content-addressable rather than topic-addressable. Where MQTT requires publishers and subscribers to agree on a topic string out of band, the primitive lets routing decisions follow the observation's declared scopes and governance. A sensor reading marked as residency-bound to one jurisdiction is structurally ineligible for delivery to consumers outside that scope, regardless of what topic a misconfigured broker might attempt to bridge it onto. A reading bearing a regulatory attestation class is recognizable as such by any consumer that cares about that class, without the consumer having to know the publisher's topic conventions in advance.

The governance metadata is a typed structure, not a free-form blob. Authority class, attestation level, residency scope, retention rule, and downstream-use constraints are named fields the consumer can validate mechanically. Continuity-based revocation propagates through the same store-and-forward path the observations themselves travel: a credentialing authority that fails to issue successor anchors is a revoked authority, and consumers detect revocation by chain stagnation rather than by querying a remote endpoint. For edge IoT deployments with intermittent backhaul — a large class of MQTT's customer base — this aligns revocation with the network's actual connectivity model.

Composition Pathway With MQTT

The primitive composes with MQTT rather than replacing it. The minimum-viable integration treats the primitive's wire format as MQTT payload bytes: publishers serialize observations into the primitive's format and PUBLISH them to MQTT topics; subscribers receive payload bytes through ordinary Paho clients and verify authority and governance at the application layer. No broker change is required, no client-library change is required, and the integration is fully compatible with HiveMQ, Mosquitto, EMQX, AWS IoT Core, Azure IoT Hub, and any other v3.1.1- or v5-compliant broker. The cost is modest payload overhead — the authority and governance descriptors add bytes, though efficient binary encoding keeps the increment manageable for constrained devices.

A deeper integration uses MQTT v5 user properties to surface the primitive's governance fields at the protocol level, allowing brokers and gateways to inspect and route on those properties without parsing the full payload. A bridging gateway between a regional MQTT broker and a central one can enforce residency scope by reading the user properties and refusing to bridge observations whose scope excludes the central broker's jurisdiction. This integration depth requires no broker modification — user properties are first-class in v5 — but it does require that the gateway adopt the primitive's vocabulary.

The deepest integration places primitive-aware verification logic inside the broker itself. Both HiveMQ and EMQX expose plugin interfaces (HiveMQ Extensions SDK, EMQX hooks) that allow custom code to inspect, transform, or reject MQTT packets at well-defined extension points. A primitive-verifying extension can validate authority signatures at PUBLISH time, attach lineage metadata to retained messages, and enforce governance-driven routing decisions before the broker's standard topic-matching logic runs. The broker's role transitions from sole authority to discovery and transport substrate, with structural governance handled by the primitive layer the extension implements.

Sparkplug B users gain a particularly natural composition path. Sparkplug already imposes a structured topic namespace and a state-aware payload; layering the primitive over Sparkplug adds cryptographic authority to the payloads Sparkplug already standardizes, without disturbing the namespace conventions Sparkplug installations depend on.

Commercial and Licensing Posture

MQTT's vendor and customer ecosystem is broad, and the licensing posture for the primitive reflects that breadth. Non-exclusive licensing is offered to broker vendors (HiveMQ, EMQX, Mosquitto-derived commercial products), to managed-service operators running MQTT at cloud scale (AWS IoT Core, Azure IoT Hub, comparable regional clouds), to industrial-IoT platform vendors building governed-telemetry products on top of MQTT, and to large end customers operating private fleets in regulated industries. Reference adapters for Eclipse Paho clients and for HiveMQ and EMQX broker extensions are published under licensing terms compatible with the dominant client and broker licenses so adopters do not face compatibility friction.

Field-of-use structuring concentrates commercial terms on regulated verticals — medical devices, automotive, energy, food-safety supply chains, defense industrial telemetry — where structural payload-level governance is becoming a procurement requirement and where broker-only authority is increasingly insufficient evidence under emerging AI, data-residency, and product-liability regimes. Unregulated and hobbyist deployments can adopt the primitive's wire format under terms that reflect the substrate's open-source character, preserving the ecosystem's accessibility while concentrating commercial relationships where structural governance carries enterprise value. For broker vendors specifically, the primitive is positioned as a complementary capability that strengthens their products in regulated markets, not as a substitute for the routing, persistence, and operational tooling that make MQTT brokers valuable in the first place.