MQTT is a lightweight, publish-subscribe messaging protocol designed for constrained devices and unreliable networks. It has become the dominant transport protocol for industrial IoT and Unified Namespace architectures because it decouples data producers from consumers, scales to millions of connected devices over a single broker, and sends data only when values change rather than polling continuously.
Last reviewed: 2026Reading time: ~9 minTopics: MQTT, pub/sub, broker, topics, QoS, Sparkplug B, UNS, OPC UA
What is MQTT?
MQTT, Message Queuing Telemetry Transport, is an open OASIS standard messaging protocol built on a publish-subscribe architecture. It was invented in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper (Eurotech) to connect oil pipeline SCADA systems over expensive, unreliable satellite links. The design goals of that original application—extremely low bandwidth overhead, reliable delivery across unreliable connections, and minimal CPU and memory requirements on constrained devices—are exactly why MQTT has become the dominant protocol for industrial IoT and Unified Namespace implementations.
MQTT runs over TCP/IP. Every MQTT message consists of a fixed header of just two bytes, an optional variable header, and a payload of up to 256 megabytes. The fixed header alone is what distinguishes MQTT from HTTP for IoT applications: where an HTTP request carries hundreds of bytes of header overhead per message regardless of payload size, an MQTT message delivers sensor data with minimal transport overhead. For a plant with thousands of tags publishing changes at high frequency, that overhead difference translates directly to network capacity and device battery life.
MQTT is an OASIS standard (ISO/IEC 20922) with two major active versions in industrial use: MQTT 3.1.1, which is the most widely deployed, and MQTT 5.0, which adds improved error reporting, topic aliases, and enhanced session expiry. For industrial deployments, MQTT 3.1.1 remains the baseline interoperability target, while MQTT 5.0 features are increasingly supported by modern broker products.
MQTT is not a historian or a database. MQTT is a transport protocol: it moves messages between producers and consumers through a central broker. It does not store data for historical query, it does not enforce data models or schemas, and it does not persist data beyond what the broker's retained message and persistent session features provide. Historians, time-series databases, and cloud storage platforms connect to MQTT as subscribers to collect and persist the data the protocol delivers.
The publish-subscribe model
The central architectural concept of MQTT is publish-subscribe, which is fundamentally different from the request-response model used by HTTP and the OPC UA client-server model. In a request-response system, a consumer must know where the data lives and ask for it explicitly. In a publish-subscribe system, producers publish data to a broker under a topic address, and consumers subscribe to the topics they want. The broker routes messages from publishers to all matching subscribers.
This architecture creates a key property: producers and consumers are decoupled. A PLC publishing temperature readings to a topic does not know how many applications are consuming that data, or what they are doing with it. A new analytics application can subscribe to that topic and immediately receive all future readings without any change to the PLC, the OPC server above it, or any other existing consumer. Adding consumers has no effect on producers. Adding producers does not require consumers to change their subscriptions if they use wildcard matching.
MQTT publish-subscribe architecture: producers, broker, and consumers
Topics: the addressing system
Every MQTT message is published to a topic. A topic is a UTF-8 string that serves as the address for the message. Topics are hierarchical, using the forward slash as a level separator. This hierarchy is not enforced by the MQTT protocol itself but it is the universal convention, and in industrial deployments it is structured to mirror the physical and functional hierarchy of the facility.
For industrial UNS implementations, the standard topic hierarchy follows the ISA-95 model:
MQTT topic hierarchy: ISA-95 structure in practice
AcmeCorp/Charlotte/Packaging/Line2/Filler/Temperature_degCFull qualified tag
Wildcard subscriptions:
AcmeCorp/Charlotte/#All data from Charlotte plant
AcmeCorp/+/+/Line2/+/Temperature_degCAll Line 2 temperatures enterprise-wide
AcmeCorp/#Every tag across the entire enterprise
The # wildcard matches any number of levels below the point where it appears. The + wildcard matches exactly one level. These wildcards allow a single subscription to capture any number of related data points, which is what makes MQTT an efficient transport for enterprise-scale data consumption: an AI agent or analytics platform does not need to enumerate every individual tag; it subscribes to a wildcard pattern and receives everything that matches.
Quality of Service (QoS) levels
MQTT defines three Quality of Service levels that determine how the protocol handles message delivery between a client and the broker. The choice of QoS level is a trade-off between delivery reliability and network overhead: higher QoS levels add acknowledgement handshakes that consume additional bandwidth and processing.
QoS level 0
At most once
The message is sent once with no acknowledgement. The sender does not know whether the message was received. If the network drops the packet, the message is lost permanently. No state is maintained by the broker for this delivery.
Use when
Data loss is acceptable and the next update will arrive shortly anyway. Typical for high-frequency sensor telemetry where a missed reading is inconsequential: temperature publishing every 100ms, ambient sensor data, non-critical monitoring displays.
QoS level 1
At least once
The sender retransmits until an acknowledgement is received from the broker. The message is guaranteed to arrive, but may arrive more than once if the acknowledgement is lost. Subscribers must be prepared to handle duplicate messages.
Use when
Every message must arrive but occasional duplicates are acceptable. The most common choice for industrial data that must not be lost: setpoint changes, alarm notifications, production counts, historian data feeds. Most industrial UNS deployments use QoS 1 as the default.
QoS level 2
Exactly once
A four-way handshake guarantees the message is delivered exactly once: no loss and no duplicates. Requires the most network overhead and broker processing per message.
Use when
Both loss and duplication are unacceptable: billing metering data, financial records, safety-critical commands, regulatory audit data. Use sparingly, as the overhead is significant at scale. Many industrial deployments achieve the same goal by using QoS 1 with idempotent message handling at the subscriber.
QoS applies per message, not per session. Each published message carries its own QoS level. A publisher can mix QoS 0 messages for high-frequency telemetry with QoS 1 messages for critical events within the same connection. Subscribers specify a maximum QoS they are willing to accept for a given subscription; the broker delivers at the lower of the publisher's and subscriber's QoS.
Key MQTT features for industrial deployments
Beyond the publish-subscribe core and QoS levels, four MQTT features are particularly important for industrial applications:
Retained messages
Always-current state for new subscribers
When a publisher marks a message as retained, the broker stores it as the last known value for that topic. Any new subscriber receives the retained message immediately upon subscribing, before the next update from the publisher. This solves a critical problem: a dashboard or analytics application that subscribes after the last change event would otherwise see no data until the next change. With retained messages, it instantly receives the current state of every subscribed topic. In industrial deployments, retained messages are standard practice for tag values so that any consumer connecting at any time immediately has a current view of operations.
Last Will and Testament
Automatic disconnect notification
When a client connects, it can specify a Last Will message: a topic and payload the broker should publish if the client disconnects ungracefully (network failure, crash, timeout). If the connection is lost without an explicit DISCONNECT packet, the broker publishes the will message to all subscribers of that topic, signaling that the client has gone offline. This is essential for device status monitoring in industrial deployments: a PLC or edge gateway that loses connectivity publishes an "offline" status automatically through its will message, without any explicit reconnection logic required. Sparkplug B builds its birth/death certificate pattern on top of this feature.
Persistent sessions
Message buffering across disconnections
A client can connect with a persistent session flag, instructing the broker to maintain its subscription list and buffer QoS 1 and QoS 2 messages during disconnections. When the client reconnects, the broker delivers all buffered messages. This is critical for industrial devices on unreliable cellular or WAN links: a remote sensor that loses connectivity for an hour does not lose the data published during that time if the subscribers use persistent sessions. The broker holds the messages until delivery is confirmed.
Report by exception
Publish only on change
MQTT does not enforce report-by-exception natively, but the convention in industrial deployments is for publishers (edge gateways, OPC servers, N3uron instances) to publish a new message only when a tag value changes by more than a configured deadband. This is the same exception reporting principle used by process historians to reduce storage requirements. On a network with thousands of tags, most of which are stable most of the time, report-by-exception reduces MQTT broker traffic by orders of magnitude compared to polling-based protocols. Sparkplug B formalizes this as a required behavior for edge nodes.
Sparkplug B: MQTT for industrial systems
Vanilla MQTT is a general-purpose messaging protocol that intentionally leaves payload format, topic namespace structure, and device state management to the application. This flexibility works well for greenfield IoT deployments but creates fragmentation in industrial environments: different vendors define their own topic hierarchies and payload formats, making interoperability difficult.
Sparkplug B (now an Eclipse specification) was introduced by Cirrus Link Solutions in 2016 specifically to address this. It defines three things that plain MQTT does not:
A standardized topic namespace:spBv1.0/{group_id}/{message_type}/{edge_node_id}/{device_id}. Every Sparkplug B implementation uses the same topic structure, making devices from different vendors immediately discoverable by any Sparkplug-aware subscriber.
A standardized payload format: Google Protocol Buffers (Protobuf) encoding. A Sparkplug message payload carries not just a value but also the tag name, data type, engineering units, timestamp, and metadata. A subscriber receiving a Sparkplug message gets self-describing data: it knows the value is "Temperature_degC", it is a Float32, it was 72.4, and it was measured at a specific timestamp. Plain MQTT just delivers "72.4".
Birth/death certificates and session state management: When an edge node connects, it publishes a birth certificate listing every metric it will publish, with full metadata. When it disconnects, the broker publishes a death certificate using Last Will. This enables automatic device discovery and real-time connectivity status without any out-of-band configuration.
Sparkplug B and the UNS: Sparkplug B is the payload and namespace standard that makes MQTT interoperable enough for Unified Namespace architectures. Without it, each device defines its own topic structure and payload format, requiring bespoke processing at every consumer. With it, any Sparkplug-aware consumer can connect to any Sparkplug-enabled broker and immediately understand every metric from every device, enabling the plug-and-play data infrastructure that UNS promises. N3uron, the edge platform SWTB distributes, publishes data in Sparkplug B format natively.
MQTT vs OPC UA: the right question
Engineers evaluating industrial data architecture frequently frame MQTT and OPC UA as competing standards and ask which one to use. The more useful framing is that they solve different problems, which is why mature Industry 4.0 architectures use both.
Dimension
MQTT
OPC UA
Architecture model
Publish-subscribe via broker. Producers and consumers are fully decoupled.
Client-server (plus Pub/Sub in Part 14). Clients connect directly to servers.
Protocol overhead
Very lightweight. Fixed header is 2 bytes. Minimal connection overhead.
More substantial. Rich type system, session management, and security layers add overhead.
Information model
No built-in data model. Topic structure and payload format are application-defined. Sparkplug B adds metadata.
Rich, strongly-typed information model. Nodes have types, relationships, engineering units built into the standard.
Scalability
Very high. A single broker cluster can handle millions of concurrent connections. Adding consumers has no effect on producers.
Server-client connections are more resource-intensive. Better suited to moderate-scale, tightly integrated environments.
Network suitability
Designed for unreliable, high-latency, low-bandwidth networks. Works well over cellular and WAN.
Works well on reliable LAN environments. Can traverse firewalls with configuration.
Semantic interoperability
Limited natively; depends on external convention or Sparkplug B. Two implementations can both be MQTT and still be incompatible.
Strong. Two OPC UA implementations that both claim a companion specification are semantically interoperable.
Primary industrial use case
High-frequency telemetry transport, UNS backbone, cloud connectivity, edge-to-enterprise data pipelines.
Device-to-device communication, SCADA integration, semantic data modeling, machine-to-machine control.
OPC UA servers (like TOP Server) collect device data. N3uron or Cogent DataHub translates OPC UA data to MQTT/Sparkplug B for the UNS. OPC UA Part 14 PubSub can also use MQTT as its transport. The common architecture is OPC UA at the device layer, MQTT at the enterprise transport layer.
The converging answer: OPC UA and MQTT are converging at the protocol level (OPC UA PubSub can use MQTT as transport) and at the architectural level (Sparkplug B borrows semantic concepts from OPC UA's information model). For most brownfield industrial deployments today, the practical architecture is OPC UA at the device and SCADA layer, feeding data through an edge gateway (N3uron, TOP Server) that publishes to an MQTT broker in Sparkplug B format for enterprise and cloud consumption.
How Software Toolbox products use MQTT
MQTT is embedded across SWTB's product portfolio as the primary transport for industrial data moving from OT systems toward IT, cloud, and AI consumption layers.
Model + publish
N3uron
N3uron is the primary MQTT edge platform in SWTB's stack. It connects to OT devices and OPC servers, applies ISA-95 data modeling to raw tag values, and publishes structured data to an MQTT broker using Sparkplug B. N3uron includes its own built-in MQTT broker, making it a single-product MQTT infrastructure deployment for many brownfield sites. It handles both the contextualization and the MQTT publishing in one platform.
OPC to MQTT
Cogent DataHub
Cogent DataHub bridges existing OPC DA, OPC UA, Modbus, and other protocol data sources to MQTT brokers, including cloud endpoints (Azure IoT Hub, AWS Kinesis, AVEVA Insight, InfluxDB). DataHub handles the protocol conversion from OPC Classic to MQTT, enabling legacy infrastructure that was never designed for MQTT to participate in a modern UNS architecture. It also tunnels MQTT connections securely across firewalls using its outbound-only connection model.
Route and transform
OPC Router
OPC Router includes a native MQTT client for publishing OPC data to any MQTT broker and subscribing to MQTT topics for downstream routing to databases, REST APIs, SAP/ERP, and other IT systems. It handles the visual workflow of mapping OPC tag values to MQTT topics and transforming payloads as required by downstream consumers, without custom code.
AI on MQTT data
chatUNS.ai
chatUNS.ai connects to a live MQTT-backed Unified Namespace as a subscriber and answers natural-language questions about operational data. Because the UNS is organized in the ISA-95 hierarchy and data is published with Sparkplug B metadata, chatUNS.ai can browse the namespace by topic pattern and discover what data is available, then subscribe and query it, without requiring any manual configuration of tag lists or data schemas.
Frequently asked questions
Is MQTT secure enough for industrial use?+−
MQTT runs over TCP/IP and can be secured with TLS 1.2 or higher, which encrypts all data in transit. Client authentication can be performed using username/password credentials, X.509 client certificates, or OAuth tokens, depending on broker support. Modern MQTT brokers provide access control lists (ACLs) that restrict which clients can publish or subscribe to which topics, providing authorization at the topic level.
Plain MQTT without TLS sends credentials and payload in cleartext and should never be used on any network that is not fully trusted, which in practice means it should not be used on networks that cross the IT/OT boundary. TLS-secured MQTT (MQTTS, typically on port 8883) is appropriate for any network crossing, including internet connections to cloud brokers. For OT-side deployments within a trusted plant network, plain MQTT over port 1883 is common practice, but TLS is increasingly the default even within plants.
What is the difference between MQTT and Sparkplug B?+−
MQTT is the underlying transport protocol: it defines how to connect to a broker, how to publish and subscribe, and how QoS levels work. It does not define what topic structure to use or what format the payload should be in. Two devices both implementing MQTT can be completely incompatible at the application layer because they use different topic hierarchies and payload formats.
Sparkplug B is a specification built on top of MQTT that standardizes three things plain MQTT leaves open: the topic namespace structure (spBv1.0/...), the payload encoding (Google Protocol Buffers with defined fields for tag name, type, value, engineering units, and timestamp), and device state management (birth/death certificates for automatic discovery). Sparkplug B makes MQTT applications interoperable at the application layer, not just the transport layer, which is why it is the standard choice for industrial UNS implementations.
Can MQTT work with my existing OPC DA or OPC UA infrastructure?+−
Yes. The standard bridge architecture is: existing OPC server (TOP Server or similar) collects device data using native protocols and exposes it via OPC DA or OPC UA. An edge platform (N3uron or Cogent DataHub) connects to that OPC server as an OPC client, models and contextualizes the tag data, and publishes it to an MQTT broker in Sparkplug B or standard MQTT format. The OPC infrastructure does not need to change. The MQTT layer is added above it as an additional data distribution channel.
This architecture means OT devices and SCADA systems that know nothing about MQTT participate in a modern UNS through the OPC-to-MQTT translation layer. It also means existing OPC-based applications (historians, HMI clients, SCADA) continue to function as before, while new IT and cloud applications consume the same data through MQTT subscriptions.
How does MQTT handle device reconnections after a network outage?+−
MQTT handles reconnections through two mechanisms. First, persistent sessions: if a client connects with the clean session flag set to false, the broker maintains its subscription list and buffers undelivered QoS 1 and QoS 2 messages during the disconnection. When the client reconnects, the broker delivers all buffered messages without requiring the client to re-subscribe or explicitly request missed messages.
Second, the Last Will and Testament feature signals the client's disconnection to all subscribers. When the client reconnects, it publishes a new birth certificate (in Sparkplug B) or an explicit reconnect notification. Clients that depend on knowing device connectivity status use the will message to detect the disconnection and the reconnect notification to detect recovery.
At the application level, most industrial MQTT deployments use retained messages so that the last known value of every tag is always available to new subscribers and to reconnecting clients that need to restore their view of current state quickly.
What MQTT broker should I use for an industrial deployment?+−
For small to medium industrial deployments, Mosquitto (open source, Eclipse Foundation) is widely used and well-supported. It handles tens of thousands of connections reliably and is straightforward to configure. N3uron includes its own MQTT broker, which is the simplest path for SWTB customers who are already deploying N3uron as the edge modeling platform.
For enterprise-scale deployments with multi-site federation, high availability requirements, or very large connection counts (hundreds of thousands or more), commercial brokers like HiveMQ and EMQX offer clustering, management APIs, advanced access control, and enterprise support. Both support Sparkplug B natively.
For cloud connectivity, the major cloud platforms provide managed MQTT services: AWS IoT Core, Azure IoT Hub, and Google Cloud IoT all support MQTT 3.1.1 as their standard device connectivity protocol. Cogent DataHub connects to all three directly.
Does MQTT replace OPC in my plant?+−
MQTT and OPC address different layers of the industrial data architecture and are not substitutes for each other. OPC (particularly OPC UA) is the right protocol at the device and SCADA layer: it provides a strongly-typed information model, bidirectional client-server communication, and the semantic precision that machine-to-machine control and SCADA integration require. PLCs and DCS systems will continue to expose OPC interfaces because that is what the installed base of industrial software expects.
MQTT is the right protocol at the enterprise transport layer: it is lightweight, scales to any number of consumers, works across WAN and cloud, and integrates naturally with cloud analytics platforms and AI applications. The standard architecture keeps OPC at the device and SCADA layer and adds MQTT as the transport from edge gateways outward toward IT and cloud. Software Toolbox's stack supports both, with N3uron and Cogent DataHub handling the translation between them.
Ready to add MQTT to your industrial data architecture?
Software Toolbox helps operations connect OPC-based OT infrastructure to MQTT brokers and Unified Namespace architectures, without replacing what works. Let our engineers design the right path for your environment.
