If you’ve spent any time in industrial automation, IoT development, or embedded systems, you’ve probably run into the acronym MQTT.

It keeps showing up in smart factory discussions, home automation setups, SCADA systems, and edge computing architectures, and for good reason.

In this guide, you’ll learn exactly what MQTT is, how it works under the hood, why it’s become one of the most widely used messaging protocols in automation and IoT, and where it fits relative to alternatives like HTTP and OPC UA.

What Is MQTT?

MQTT (Message Queuing Telemetry Transport) is a lightweight, publish-subscribe messaging protocol designed for constrained devices and low-bandwidth, high-latency, or unreliable networks.

In plain terms: MQTT is a way for machines, sensors, and software systems to exchange small messages efficiently, even over slow or unstable network connections.

It operates on top of TCP/IP and was built from the ground up with three things in mind:

• Minimal bandwidth usage: messages are compact, with very little overhead.
• Low power consumption: suitable for battery-operated sensors and remote devices.
• Reliable delivery: even when network connections are intermittent.

This combination makes MQTT particularly well-suited for.

• Industrial sensor networks
• SCADA and remote monitoring systems
• Smart building automation
• IoT devices (temperature sensors, flow meters, PLCs, edge nodes)
• Mobile applications that need real-time data updates

A Brief History of MQTT

MQTT was invented in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Arcom, now Cirrus Link).

The original use case? Monitoring oil pipelines via satellite involves extremely limited bandwidth, unreliable connections, and the need for low-power consumption in remote sensors.

The protocol was designed to use as little battery power and bandwidth as possible while still ensuring data was reliably transmitted.

Key milestones

Year	Event
1999	MQTT developed by IBM and Arcom for satellite SCADA monitoring
2010	MQTT 3.1 released royalty-free by IBM
2013	MQTT submitted to OASIS for standardization
2014	MQTT 3.1.1 became an official OASIS standard
2019	MQTT 5.0 released with enhanced features for large-scale deployments

Today, MQTT is an open standard maintained by OASIS and is deployed in hundreds of millions of devices worldwide.

How MQTT Works: The Core Concepts

MQTT follows a publish-subscribe (pub/sub) pattern, which is fundamentally different from the request-response model you may be familiar with from HTTP.

The Three Core Components

There are three roles in an MQTT system

Publisher (Client)

A device or application that generates data and sends it as a message to a specific topic. Examples: a temperature sensor on a pipeline, a PLC reporting machine status, a flow meter.

Subscriber (Client)

A device or application that declares interest in one or more topics and receives messages published to those topics. Examples: a SCADA server, a dashboard application, a cloud analytics platform.

Broker (Server)

The central hub that receives all published messages and routes them to the correct subscribers.

The broker is the only component that publishers and subscribers connect to directly; they never communicate with each other directly.

The Publish-Subscribe Flow

Here’s a simplified walkthrough of how a message travels through an MQTT system.

[Temperature Sensor]  →  publishes to topic "plant/line1/temperature"
          ↓
      [MQTT Broker]   →  routes message to all subscribers of that topic
          ↓
  [SCADA Dashboard]   →  receives and displays the temperature value
  [Cloud Logger]      →  receives and logs the value to a database
  [Alarm Controller]  →  evaluates if the value exceeds a threshold

The key advantage here is decoupling: the sensor doesn’t need to know who is listening. It just publishes. The broker handles distribution. This makes systems far more scalable and easier to maintain.

The MQTT Broker: The Heart of the System

The MQTT broker is a server that manages all message routing. Every client, whether publisher or subscriber, connects to the broker, never to each other.

What the Broker Does

• Accepts connections from clients
• Receives messages from publishers
• Filters messages by topic
• Delivers messages to all matching subscribers
• Manages retained messages (more on this below)
• Handles QoS negotiation
• Manages persistent sessions for offline clients

Popular MQTT Brokers

Broker	Type	Best For
Mosquitto	Open Source	Local/embedded deployments, testing
EMQX	Open Source / Enterprise	High-throughput industrial systems
HiveMQ	Commercial / Community	Enterprise IoT, automotive
VerneMQ	Open Source	Clustered, distributed deployments
AWS IoT Core	Cloud (SaaS)	Cloud-based IoT architectures
Azure IoT Hub	Cloud (SaaS)	Microsoft ecosystem IoT

For most industrial environments and lab setups, Eclipse Mosquitto is the most widely used starting point.

It’s lightweight, well-documented, and runs on Linux-based edge devices or industrial PCs with minimal resources.

Retained Messages

A broker can store the last known message for a topic. When a new subscriber connects to that topic, the broker immediately delivers the retained message so the subscriber doesn’t have to wait for the next publish event to get data. This is especially useful for device status or configuration topics.

Last Will and Testament (LWT)

When a client connects to the broker, it can specify a Last Will message. If the client disconnects unexpectedly (e.g., power loss, network failure), the broker automatically publishes the LWT message to a designated topic.

This gives other subscribers a way to know that a device went offline critical for industrial fault detection.

MQTT Topics Explained {#mqtt-topics-explained}

In MQTT, a topic is a UTF-8 string that acts as an address for routing messages. Topics are hierarchical, using forward slashes / as level separators.

Topic Structure Examples

plant/line1/temperature
plant/line1/pressure
plant/line2/flow
building/floor3/hvac/status
factory/robot/arm1/state

Wildcards

MQTT supports two types of wildcards when subscribing:

Single-level wildcard: + Matches exactly one topic level.

plant/+/temperature

This would match:

• plant/line1/temperature
• plant/line2/temperature
• plant/boiler/temperature

Multi-level wildcard: # Matches any number of topic levels. Must appear at the end.

plant/#

This would match:

• plant/line1/temperature
• plant/line2/pressure
• plant/boiler/status
• plant/line1/robot/arm1/state

Best Practices for Topic Design

• Keep topics descriptive and hierarchical: site/area/device/measurement
• Use lowercase and avoid spaces
• Avoid leading slashes (/plant/... is valid but creates an empty first level)
• Don’t use # subscriptions indiscriminately in large systems — it can create broker performance issues
• Reserve $ prefix topics (e.g., $SYS/) — these are broker system topics and not for general use

Quality of Service (QoS) Levels

MQTT provides three Quality of Service levels that control the guarantee of message delivery between client and broker. Choosing the right QoS is a critical design decision in any MQTT deployment.

QoS 0: At Most Once (“Fire and Forget”)

• The message is delivered once with no acknowledgment
• The broker does not store or retry
• Fastest, lowest overhead
• Risk: message loss if the network drops

Best for

High-frequency telemetry where occasional data loss is acceptable (e.g., continuous sensor readings at 1-second intervals)

QoS 1: At Least Once

• Message is delivered at least once, with acknowledgment (PUBACK)
• Broker retries until it receives an acknowledgment
• Risk: duplicate messages possible (if acknowledgment is lost)

Best for

Most industrial sensor data where you need confidence that the message arrived, but can handle deduplication.

QoS 2: Exactly Once

• The message is delivered exactly once using a four-part handshake
• Slowest, highest overhead
• Guarantees no duplicates and no loss

Best for

Control commands, alarm events, billing data, and any message where duplicates could cause incorrect actions.

QoS Summary Table

Level	Guarantee	Latency	Overhead	Use Case
QoS 0	At most once	Lowest	Minimal	Frequent telemetry
QoS 1	At least once	Medium	Low	Most sensor data
QoS 2	Exactly once	Highest	High	Commands, alarms

Important

QoS is negotiated between the client and the broker. If a publisher sends at QoS 2 but a subscriber is connected at QoS 0, delivery to that subscriber follows QoS 0.

MQTT vs HTTP: Key Differences

HTTP is the dominant protocol of the web, but it’s not designed for machine-to-machine communication at scale. Here’s how the two compare:

Feature	MQTT	HTTP
Pattern	Publish-Subscribe	Request-Response
Connection	Persistent (long-lived)	Stateless (new connection per request)
Header overhead	2 bytes minimum	200–800 bytes typical
Direction	Bidirectional (server can push)	Typically client-initiated only
Power consumption	Very low	Moderate to high
Ideal payload size	Small (bytes to KB)	Any size
Real-time push	Native	Requires polling or WebSocket workaround
Network tolerance	High (designed for unreliable networks)	Low

When to use HTTP instead of MQTT

Configuration APIs, file transfers, web dashboards that pull data on demand, or scenarios where standard REST tooling is required.

When to use MQTT instead of HTTP

Real-time telemetry, sensor networks, machine status monitoring, or any application where bandwidth and latency matter, and devices need to push data continuously.

MQTT vs OPC-UA

In industrial automation, OPC-UA (Open Platform Communications Unified Architecture) is often compared to MQTT. They serve overlapping but distinct roles.

Feature	MQTT	OPC-UA
Primary design	Lightweight messaging	Industrial data modeling & exchange
Data model	Flat topics, raw payload	Structured nodes with data types
Security	TLS/SSL, username/password	Built-in security model (certificates)
Bandwidth	Very low	Moderate
Complexity	Low	High
Interoperability	Broad (any language/platform)	Rich (but heavier implementation)
Best for	Sensor telemetry, edge-to-cloud	PLC-to-SCADA, machine data with context

The modern answer

Many industrial architectures use both. OPC-UA is used at the device/PLC layer for structured data exchange, while MQTT (often with Sparkplug B as a payload specification built on top of MQTT) is used to transport that data to the cloud or higher-level systems.

Common Use Cases in Industrial Automation and IoT

Remote Sensor Monitoring

Gas detectors, temperature sensors, pressure transmitters, and flow meters publish readings to an MQTT broker. SCADA systems or cloud dashboards subscribe to receive real-time data without polling.

SCADA and HMI Integration

MQTT bridges field device data to supervisory systems. Combined with Sparkplug B, devices publish structured, self-describing data including engineering units, timestamps, and data type metadata.

Edge-to-Cloud Pipelines

Edge devices (industrial PCs, gateways) aggregate data locally and publish to cloud MQTT brokers (AWS IoT Core, Azure IoT Hub).

This reduces cloud ingestion costs and allows local processing even when internet connectivity is intermittent.

Smart Building Automation

HVAC systems, lighting controllers, energy meters, and access control devices communicate via MQTT to a central building management system (BMS).

Mobile and Fleet Monitoring

Remote assets, such as trucks, generators, and offshore equipment, report status via satellite or cellular connections. MQTT’s tolerance for unreliable networks makes it ideal here.

Alarm and Event Notification

Control systems publish alarm states to MQTT topics. Notification systems subscribe and trigger alerts via SMS, email, or operator dashboards without direct integration between the control system and the alerting software.

MQTT Security Best Practices

Out of the box, MQTT has minimal security. Securing an MQTT deployment is your responsibility. Here are the critical layers:

Use TLS/SSL Encryption

Always encrypt traffic between clients and the broker. MQTT over TLS runs on port 8883 (vs. unencrypted on 1883). This prevents eavesdropping and man-in-the-middle attacks.

Require Authentication

Configure the broker to require a username and password for all connections. Never leave authentication disabled in production.

Use Client Certificates (for critical systems)

For high-security environments, use mutual TLS (mTLS) where each client presents a certificate. This prevents unauthorized devices from connecting even if credentials are compromised.

Implement Topic-Level Authorization

Configure the broker’s ACL (Access Control List) to restrict which clients can publish or subscribe to which topics. A temperature sensor should not be able to publish to a topic used for control commands.

Disable Retained Messages Where Not Needed

Retained messages persist on the broker. Ensure only authorized clients can set retained messages on sensitive topics.

Keep Broker Software Updated

MQTT broker software (especially Mosquitto and EMQX) receives regular security patches. Stay current.

Getting Started with MQTT

If you want to experiment with MQTT, here’s the fastest path to a working setup:

Step 1: Install a Broker (Mosquitto)

On Linux/Debian/Ubuntu:

bash

sudo apt update
sudo apt install mosquitto mosquitto-clients
sudo systemctl start mosquitto

Step 2: Subscribe to a Topic

Open a terminal and subscribe:

bash

mosquitto_sub -h localhost -t "test/sensor/temperature"

Step 3: Publish a Message

Open a second terminal and publish:

bash

mosquitto_pub -h localhost -t "test/sensor/temperature" -m "72.5"

You’ll see 72.5 appear in the subscriber terminal immediately. That’s MQTT working.

Step 4: Explore MQTT Client Libraries

For integrating MQTT into your own applications:

Language	Library
Python	paho-mqtt
JavaScript/Node.js	mqtt.js
C/C++	Eclipse Paho C
Java	Eclipse Paho Java
Go	paho.mqtt.golang

Step 5: Try MQTT with Node-RED

Node-RED provides a visual flow editor with native MQTT nodes ideal for rapid prototyping of industrial data pipelines without heavy programming.

Frequently Asked Questions

What port does MQTT use?

MQTT uses port 1883 for unencrypted connections and port 8883 for TLS-encrypted connections. MQTT over WebSockets typically uses port 9001 or 443.

Is MQTT only for IoT?

No. While MQTT was designed with IoT and telemetry in mind, it is widely used in industrial automation (SCADA, DCS integration), mobile applications, and any architecture requiring lightweight real-time messaging.

What is MQTT Sparkplug?

Sparkplug (now Sparkplug B) is a specification developed by Cirrus Link Solutions that defines a standardized payload format and topic namespace on top of MQTT.

It adds structured data types, timestamps, and device lifecycle management, making MQTT more interoperable across industrial systems.

Can MQTT work without an internet connection?

Yes. MQTT runs over any TCP/IP network, including local area networks (LAN) without internet access. Many industrial deployments run entirely on local plant networks.

What is the difference between MQTT 3.1.1 and MQTT 5.0?

MQTT 5.0 adds significant features over 3.1.1, including: reason codes on all acknowledgments, user properties (key-value pairs in message headers), request-response pattern support, shared subscriptions for load balancing, and message expiry intervals. For most embedded and industrial use cases, 3.1.1 remains widely deployed.

Is MQTT reliable enough for industrial use?

Yes, with proper QoS configuration, TLS encryption, and broker redundancy, MQTT is deployed in critical industrial applications including oil and gas pipelines, utilities, and smart manufacturing.

The key is designing your system correctly, not assuming MQTT handles everything automatically.

Conclusion

MQTT is one of those protocols that rewards the time you invest in understanding it. Once you grasp the publish-subscribe model, topics, QoS levels, and the broker’s role, you have a powerful, lightweight tool for connecting sensors, machines, and systems, whether across a factory floor or across continents.

Its low overhead, tolerance for unreliable networks, and simple design are exactly why it became a standard in both IoT and industrial automation, and why it continues to show up in new architectures alongside newer technologies like OPC-UA, MQTT Sparkplug B, and cloud IoT platforms.

If you’re working with sensor networks, remote monitoring, or edge-to-cloud data pipelines, MQTT belongs in your toolkit.