An MQTT broker is the central messaging server of an IoT network: it receives the data that devices publish and distributes it to every subscribed application. Every sensor reading, every command sent to an actuator, and every value shown on a dashboard passes through it.

The typical scenario explains it well: a factory with 2,000 sensors measuring temperature, vibration, pressure, and power consumption produces one reading per sensor every 30 seconds, while the central platform sends commands back to actuators and PLCs in real time. Something has to manage that message flow efficiently, or the system stops being operable long before it reaches production.

This guide explains what the broker is, how it works, which features matter in production, and what the options are in 2026, from Mosquitto to managed cloud brokers.

What Is MQTT and Why Does It Dominate IoT?

MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol designed for resource-constrained devices and unreliable networks. It was created by Andy Stanford-Clark of IBM and Arlen Nipper in 1999 to monitor oil pipelines in the desert via satellite: low bandwidth, high latency, unstable connections. That is the profile of most IoT networks.

The MQTT specification is built on a publish/subscribe (pub/sub) model that works the opposite way to HTTP's client/server model:

In HTTP, the client asks the server: "Is there any new data?" (polling). Inefficient when data arrives at variable frequency.
In MQTT, devices publish data to a topic. Applications that want that data subscribe to the topic. The broker intermediates: it receives publications and distributes them to all subscribers.

This decoupling changes how the system scales:

A sensor can publish data without knowing how many applications consume it.
You can add 1,000 new subscribers without touching a single line of the producer's code.
Devices and applications can restart independently without losing messages.

MQTT runs over TCP/IP with minimal overhead: the fixed header is just 2 bytes. Compared to HTTP, it consumes 10–100x less bandwidth for the same data volume. That is why it has become the standard IoT messaging protocol, and why protocol comparisons like MQTT vs CoAP vs HTTP consistently conclude that MQTT is the optimal choice for most sensor use cases.

What Exactly Is an MQTT Broker?

The MQTT broker is the central server of the system. It is the intermediary that:

Accepts connections from devices (publishers) and applications (subscribers).
Receives messages published on topics.
Filters and distributes those messages to all clients subscribed to the matching topic.
Manages authentication and access control.
Stores messages temporarily when a subscriber is disconnected (QoS 1 and 2, persistent sessions).

Diagram of an MQTT broker distributing messages from publishers to subscribers through topics

Devices do not communicate directly with each other. Everything passes through the broker. This centralized architecture simplifies security, monitoring, and system management at scale.

Anatomy of an MQTT Message

An MQTT message has three elements:

Topic: a hierarchical string that identifies the message. For example: `plant/line-A/compressor-01/temperature`. Subscribers can use wildcards: `plant/line-A/#` (everything in line A) or `plant/+/compressor-01/temperature` (compressor-01 on any line).
Payload: the message content. Can be plain text, JSON, binary, Protobuf... MQTT imposes no format.
QoS (Quality of Service): defines the delivery guarantee:
- QoS 0: "fire and forget," no confirmation and no retry
- QoS 1: "at least once," broker acknowledgement with possible duplicates
- QoS 2: "exactly once," guaranteed delivery without duplicates at the cost of higher overhead

Key Features of an MQTT Broker in Production

Not all brokers are equal. For a production IoT deployment, these are the factors that determine whether a broker handles real-world load.

Scalability and Throughput

How many messages per second can it process? How many simultaneous connections does it support? A production broker for a mid-scale industrial installation must handle at least 10,000 messages/second and 50,000 simultaneous connections without degradation. Modern enterprise brokers (EMQX, HiveMQ) scale horizontally to millions of connections through clustering.

Persistence and Sessions

When an IoT device loses connectivity because of a network failure, a restart, or a battery issue, what happens to messages published during the downtime? With persistent sessions (QoS 1/2 and `cleanSession=false`), the broker stores pending messages and delivers them when the device reconnects. Essential for sensors in locations with intermittent connectivity.

Last Will and Testament (LWT)

The LWT mechanism allows a device to register, at connection time, a message that the broker will automatically publish if the connection drops unexpectedly. Subscriber applications detect immediately that a device has disconnected, without polling or artificial timeouts. In industrial systems, this presence signal is the foundation of state monitoring.

Authentication and Authorization

A production broker must support:

Username/password or TLS client certificate (mTLS) authentication
ACL (Access Control Lists) authorization: which clients can publish/subscribe to which topics
Integration with LDAP/AD directories or external identity systems

Without strict topic-level access control, a compromised device can read or inject data anywhere in the system. OT and IoT cybersecurity starts at the broker.

Retained Messages

A retained message is the last value published on a topic that the broker stores indefinitely. When a new subscriber connects, it immediately receives the last retained value without waiting for the next sensor transmission cycle. Without this, a freshly opened dashboard would stay blank until the next reading arrives.

Broker Bridging

In distributed architectures spanning multiple plants or countries, it is common to have local brokers at each facility with a central broker in the cloud. An MQTT bridge synchronizes topics between brokers, allowing data to flow from local installations to the central system without directly exposing plant brokers to the Internet.

Security: The Most Common Attack Vectors

A poorly configured MQTT broker exposes the entire IoT infrastructure. What you cannot ignore:

Public broker without authentication: public test brokers (broker.hivemq.com, test.mosquitto.org) accept anonymous connections. Never use them in production or with real data.
Unencrypted communication: MQTT messages without TLS travel in plain text. Anyone with network access can read or inject messages. TLS 1.3 is mandatory in production.
Overly permissive ACLs: if all devices can publish and subscribe to all topics, a compromised sensor can inject false data across the entire network. ACLs must restrict each client to exactly the topics it needs.
Default or hardcoded credentials: MQTT device passwords must be rotated periodically and stored securely.

See the guide to OT cybersecurity for industrial AI and IoT for a detailed analysis of attack vectors and infrastructure-level countermeasures.

The Main MQTT Brokers in 2026

Eclipse Mosquitto

Mosquitto is the reference open source broker. Lightweight, efficient, extensively documented, with Eclipse community support. A good fit for small and medium projects, development, testing, and edge deployments where resources are limited. Its limit: it does not scale horizontally (single-node), and clustering requires advanced manual configuration.

Best for: Raspberry Pi, edge gateways, projects with <10,000 connections
License: EPL/EDL (open source)

EMQX

EMQX is a high-performance broker written in Erlang, designed for millions of concurrent connections with low latency. Native distributed architecture. Supports automatic clustering, message persistence, advanced authentication (JWT, LDAP, OAuth), integrated rule processing (Rule Engine), and bridging. Widely adopted in telecom, automotive, and large-scale industry.

Best for: large-scale industrial deployments, multi-tenant IoT platforms
License: open source (Community) + Enterprise

HiveMQ

HiveMQ is enterprise-oriented, focusing on compliance, certified support, and extensibility via plugins. Widely used in automotive (vehicle connectivity) and sectors with strict audit requirements such as healthcare and energy. Native clustering, high availability.

Best for: enterprise projects with demanding SLAs, regulated sectors
License: commercial (with limited free edition)

VerneMQ and NanoMQ

VerneMQ: open source, with a distributed architecture similar to EMQX, a solid option for high-availability clusters without license costs. NanoMQ: designed specifically for edge computing and embedded gateways with very limited resources (written in C, ~200 KB footprint).

On-Premise vs Cloud: Where to Deploy the Broker

The choice between a broker on your own infrastructure or in the cloud depends on several factors. For industrial applications with sensitive data, critical latency, or strict compliance requirements, an on-premise broker in your own datacenter or production facility is the right call. For projects with geographically distributed devices, teams without infrastructure experience, or fast scaling needs, managed cloud brokers (AWS IoT Core, Azure IoT Hub, HiveMQ Cloud, EMQX Cloud) remove the operational burden.

Many production projects adopt a hybrid architecture: local brokers at each facility with bridging to a central cloud broker for consolidation and analysis.

MQTT in IoT Architecture: Where the Broker Fits

In a typical 2026 IoT architecture, the MQTT broker occupies the central messaging layer, between field devices and the application platform:

IoT architecture with an MQTT broker: sensors and gateway publish data consumed by the platform and dashboards

IoT sensors measuring temperature, vibration, CO₂, or level publish their readings to the broker every N seconds or when an event occurs. The IoT gateway acts as aggregator and protocol translator: it converts data from LoRaWAN, Modbus, or BLE sensors to MQTT format before sending it to the central broker. The IoT platform subscribes to relevant topics, processes the data, and stores it for visualization and analysis.

In the reverse direction, the platform can publish commands (open valve, restart device, change alert threshold) that actuators receive as subscribers to the corresponding topic.

For projects requiring local processing or operating in areas with intermittent connectivity, deploying a Mosquitto broker directly on the gateway makes sense: it acts as a local broker and bridges to the central cloud broker. This is the standard edge processing pattern; we cover it in Edge AI in Industrial IoT.

Is your team designing the messaging architecture for an IoT project? Talk to our architecture team →

MQTT and Sparkplug: The Advanced Industrial Standard

Sparkplug is a payload and namespace specification built on top of MQTT, developed by Cirrus Link Solutions and now maintained by the Eclipse Foundation. Designed specifically for SCADA and industrial automation, it defines how to structure topics and messages to ensure interoperability between devices from different manufacturers.

The five capabilities Sparkplug requires from the MQTT broker:

Decoupled pub/sub architecture: producers and consumers operate independently
Session State Awareness: the broker maintains device session state for re-delivery after reconnection (via LWT)
Unified Namespace: a standardized topic scheme (`spBv1.0/[GroupID]/[MessageType]/[EdgeNodeID]/[DeviceID]`)
Central Data Repository (CDR): the broker as the hub of all industrial real-time data
Single Source of Truth: the broker stores the up-to-date state of all devices as the single reference

Sparkplug matters most in environments where PLCs, SCADA, and IoT platforms from different vendors coexist, because it defines a shared data contract between all of them.

MQTT and Other IoT Protocols: NB-IoT and LoRaWAN

MQTT does not compete with LoRaWAN or NB-IoT: they operate at different layers. LoRaWAN and NB-IoT are radio access protocols: they define how bits travel over the air from the sensor to the gateway or the carrier network. MQTT is a messaging protocol: it defines how data is structured and distributed between applications once it has reached the IP network.

In practice, data from a LoRaWAN sensor reaches the operator's Network Server (ChirpStack, The Things Network, etc.), which forwards it via MQTT to the platform's broker. Data from an NB-IoT sensor reaches the carrier's server and is delivered to the platform via MQTT or CoAP as well. MQTT acts as the common language of the upper layers, regardless of the radio access protocol used.

How Cloud Studio IoT Implements the MQTT Broker

The Cloud Studio IoT platform integrates a high-availability MQTT broker as the central component of its messaging architecture. All devices and gateways connected to the platform communicate via MQTT with mandatory TLS 1.3, certificate or token authentication, and per-tenant ACLs ensuring data segregation between clients.

For complex industrial deployments, the platform supports the Sparkplug B protocol, enabling direct integration of SCADA equipment and PLCs that already speak this standard, without additional translation layers.

The broker is transparent to the end user of the platform: integrators and manufacturers using Cloud Studio IoT do not need to manage it directly because it is integrated, monitored, and scaled automatically. For those requiring full control, such as companies with strict data policies or on-premise infrastructure, we also offer complete platform deployment, broker included, in the client's own environment.

To see how the platform positions against other alternatives, check Cloud Studio IoT vs ThingsBoard and the IoT platform guide.

Contact our technical team to evaluate the right MQTT architecture for your project.

Frequently Asked Questions About MQTT Brokers

What is the difference between MQTT and HTTP for IoT?

HTTP uses a request/response model: the client asks, the server responds. For IoT monitoring, this means constant polling that drains battery and consumes bandwidth. MQTT uses pub/sub: data reaches the subscriber the moment it is published, without a request. MQTT header overhead is 2 bytes; HTTP minimum is 200–500 bytes. For battery-powered devices and low-bandwidth networks, MQTT is the only reasonable option.

Can I use MQTT without a broker?

No. The broker is the central component of the pub/sub model. Without a broker, devices have nowhere to publish and nothing to subscribe to. Variants such as MQTT-SN (for sensor networks without TCP/IP) use specialized gateways, but the central intermediary concept remains.

How many devices can an MQTT broker handle?

It depends on the broker and infrastructure. Mosquitto on a modest server handles 50,000–100,000 connections. EMQX or HiveMQ in cluster scale to millions of concurrent connections. For typical industrial projects, from hundreds to tens of thousands of sensors, any modern enterprise broker is sufficient if correctly dimensioned.

Is MQTT secure?

MQTT with TLS 1.3, certificate authentication, and strict ACLs is secure for production. The problem is not the protocol but poorly configured implementations: brokers without TLS, without authentication, or with overly permissive ACLs. Security in MQTT is a configuration decision, not a protocol limitation.

What is MQTT 5.0 and how does it differ from MQTT 3.1.1?

MQTT 5.0 (published in 2019) adds important capabilities: extended message properties, reason codes for responses, shared subscriptions (for load balancing among multiple consumers of the same topic), message expiry, and improved session handling. Most modern brokers and clients already support both versions.

Does MQTT work with LoRaWAN?

Yes, but at different layers. LoRaWAN manages the radio transmission from the sensor to the gateway and the network server. The LoRaWAN network server (ChirpStack, TTN) forwards messages to the application platform using MQTT as the delivery protocol. They are complementary, not alternatives.

Conclusion: The MQTT Broker as Critical Infrastructure

Every data point generated by sensors, every command received by actuators, and every value displayed on dashboards passes through the MQTT broker. Treating it as an implementation detail gets expensive.

What to remember:

MQTT dominates IoT thanks to its pub/sub model and minimal overhead (2-byte header).
The broker is the central server: it authenticates, filters, distributes, and stores messages.
In production, what matters is scalability, persistent sessions, LWT, ACLs, and bridging.
Mosquitto for edge and mid-size projects; EMQX and HiveMQ for enterprise scale; managed options (AWS IoT Core, HiveMQ Cloud, EMQX Cloud) if you do not want to operate infrastructure.
TLS 1.3 + strict ACLs are not optional.

If you are designing an IoT architecture and want to get it right from the start, our technical team can help.

MQTT Broker: What It Is, How It Works, Best Options 2026