MQTT turns 27: Why the protocol matters even more now

TL;DR

Today marks the 27th anniversary of MQTT. The protocol built in 1999 to monitor an oil pipeline over satellite now carries real-time operational data across smart factories and is becoming the way AI agents sense and act on the plant floor.

• MQTT still fits industrial reality because patchy networks and constrained devices never went away. As an open standard, any conforming client works with any conforming broker.
• AI makes MQTT more valuable because agents need live, contextualized operational data and an event-driven way to act on it.

Who this blog is for: Manufacturing and digital transformation leaders deciding which data foundation their AI programs will run on.

In 1999, when anxiety around the Y2K bug was at fever pitch, the Spice Girls were taking girl power global and some questionable fashion choices were being made, a new protocol was quietly introduced that would continue to shape the path of industrial data almost thirty years later. We asked Simon Johnson, HiveMQ Distinguished Engineer and OASIS MQTT Committee Chairman & Specification Editor, to share his thoughts as we celebrate the 27th anniversary of MQTT.

The history of MQTT started with one hard problem: monitoring an oil pipeline over a slow, expensive satellite link. Twenty-seven years later, the problem that the protocol was originally created for hasn’t gone away - unreliable networks, constrained devices and expensive links are still everywhere. Now, around 12 billion devices use MQTT. It has become the real-time backbone for industrial data and the feed AI agents increasingly depend on.

MQTT - the open publish/subscribe messaging protocol designed to move data reliably between constrained devices and the systems that use it, even over unreliable networks - is standardized by OASIS and version 3.1.1 is published as ISO/IEC 20922.

As chair of the OASIS MQTT Technical Committee and editor of the specification, I often get asked about the history of MQTT and where it's going. For this anniversary, I wrote this post to answer the questions I hear most often from manufacturing leaders, from security headlines to what AI changes for the data foundation they're building.

Why is MQTT still relevant for industrial IoT 27 years later?

The conditions that MQTT was designed for haven't gone away. Patchy networks and constrained devices are everywhere in industry, from remote pumping stations to decades-old production lines.

The protocol adds just enough on top of TCP/IP to deliver a payload reliably. It's also simple to implement, which is why the same protocol runs on an 8-bit microcontroller as happily as it does in the cloud.

MQTT is an open standard. There's one specification text with testable rules, so any conforming client works with any conforming broker. For manufacturers, that means no vendor lock-in at the most foundational layer of their data architecture.

The strong open-source ecosystem has put MQTT within reach of every developer. Projects such as Eclipse Paho, Eclipse Mosquitto, MQTT.js, the HiveMQ MQTT Client and HiveMQ Broker let teams start experimenting without waiting on a procurement cycle.

Publish/subscribe also matches how operational data actually flows. One temperature reading can matter to the maintenance team, the quality system, the energy dashboard and an analytics model at the same moment. With MQTT, each new consumer is a subscription rather than another point-to-point integration. That's why it became the backbone of OT/IT convergence and the unified namespace (UNS).

How have MQTT use cases changed since 1999?

MQTT has moved from niche telemetry to the data backbone of industrial operations. Each version of the specification marked a step along the way.

• 1999, telemetry over satellite. MQTT started as a way to monitor SCADA systems and remote assets such as pipelines over expensive satellite links.
• MQTT 3.1.1 (2014), from polling to publish/subscribe. It moved IoT from HTTP polling to structured publish/subscribe for smart homes, smart meters, mobile apps and messaging.
• MQTT 5.0 (2019), the integrator's protocol. Version 5.0 brought MQTT into enterprise and cloud integration. A typical connected-vehicle fleet can generate around 100,000 messages per second, while a single smart factory can produce 25,000 to 50,000.
• From moving data to being the data backbone. MQTT now sits at the center of the UNS, OT/IT convergence, analytics and digital twins.
• Today, moving at both ends. MQTT-SN extends messaging to devices across diverse network environments, including satellite and NB-IoT, supporting applications such as livestock tracking and emergency response. Meanwhile, MQTT is also being used to connect AI agents in the enterprise.

Today, MQTT works as a family of related protocols that share one publish/subscribe model.

Why has MQTT been in the headlines this year?

MQTT has appeared in some security headlines this past year because the protocol is so widely used, not because of the protocol itself. With an estimated 12 billion devices using it, MQTT is the core of connected operations. Such far-reaching use makes a big, visible target.

The challenge here is almost always how MQTT has been deployed. The incidents I see involve brokers left open on the internet on port 1883, no authentication, no TLS and wildcard subscriptions that let anyone read or write every topic.

MQTT's design principle of a simple client and a sophisticated broker cuts both ways. Clients trust the broker, so a poorly run broker exposes everything behind it. In a plant, anyone who can reach that broker could see or publish production data.

The fix is well known:

• Use TLS everywhere.
• Use real authentication, such as certificates, OAuth or MQTT 5 enhanced authentication.
• Apply per-topic authorization so each client reaches only the topics it needs.
• Never expose a broker directly to the internet.
• Run an enterprise-grade broker with audit logging and monitoring.

The standard is doing its part too, MQTT 5 added enhanced authentication. In MQTT-SN 2.0, we're working on authentication and message integrity for the smallest devices, including DTLS over UDP, Protection encapsulation and keys for devices that sleep between transmissions.

For OT teams, securing MQTT doesn't mean replacing it or disrupting running lines. It means deploying it with the controls the standard already supports.

For a deeper dive into MQTT and security, explore HiveMQ’s MQTT Security Fundamentals.

Why AI makes MQTT increasingly important

AI is only as good as the data it sees. MQTT is already the real-time feed for operational data on many plant floors, which makes the protocol the natural sensory system for industrial AI.

AI agents should be event driven and contract based, and react to live state as it changes, instead of polling a database on a timer. Publish/subscribe fits that loop naturally. When an agent acts, the result is simply another event others can subscribe to.

Agent-to-agent and agent-to-tool traffic also looks a lot like device traffic. MQTT gives that traffic a shared topic space. Quality of service (QoS) and persistent sessions handle unreliable connections, while retained messages let a newly started agent see the current state immediately.

MQTT 5 already has much of what agents need, including request/response, enhanced reason codes and user properties. The OASIS MQTT Technical Committee's AI working group is exploring MQTT as a transport for agents, considering integration with both Model Context Protocol (MCP) and A2A (AgentToAgent) with a view to align with the same effort in the AMQP Technical Committee.

Raw operational data isn’t enough on its own. On the plant floor, AI only knows what it can see. An experienced operator knows which asset produced a reading and whether the value looks right but that knowledge lives in their head, where AI can’t reach it. AI delivers real value only when it has access to encoded business rules and when it runs on structured, contextualized data, where every reading carries the asset that produced it and what a valid value should look like.

AI raises the bar for industrial data. MQTT is already feeding AI the data it needs.

What's next for MQTT and industrial data?

The future of MQTT is a family of protocols sharing one publish/subscribe model, carrying contextualized data that people and AI agents can both act on.

Each version serves a different part of the operation, from MQTT-SN at the far edge to MQTT 5.0 for enterprise integration. They all share one model of how data flows, so teams don't have to rethink their architecture as they extend it.

I expect MQTT to become the transport for AI agents in industry. Those agents will watch the unified namespace and act back on the plant under proper governance. In operations where uptime and safety come first, autonomy has to be earned step by step, with people setting the guardrails.

It’s also worth noting that industrial data is also moving from collection to context. Modeled, contextualized data, not tag soup, is what AI and analytics will run on.

And finally, MQTT will stay open and community-led. The OASIS MQTT Technical Committee has reconvened and MQTT-SN 2.0 will be published soon for public review. We want users and implementers to help shape the next versions.

Why does the next industrial chapter start with the data foundation?

Twenty-seven years ago, MQTT was designed to get data out of places that were hard to reach. Today the harder problem is making that data mean something when it arrives.

That's the foundation we build on at HiveMQ. HiveMQ Platform connects, contextualizes, analyzes and acts on industrial data on a reliable MQTT backbone, so manufacturers can catch problems earlier and repeat what works across every site.

See how HiveMQ Platform builds on MQTT to turn real-time plant data into trusted intelligence.

Frequently asked questions about MQTT