←

MQTT in Manufacturing: Protocol, Architecture and Use Cases

By Mark Kobbert · Last updated: March 2026

What Is MQTT?

MQTT (Message Queuing Telemetry Transport) is a lightweight messaging protocol based on the publish/subscribe model, designed for efficient, reliable communication between devices over constrained or unreliable networks. Originally developed in 1999 by Andy Stanford-Clark (IBM) and Arlen Nipper for monitoring oil pipelines via satellite, MQTT has become the de facto standard for edge-to-cloud data transport in Industrial IoT (IIoT) environments.

In manufacturing, MQTT is the protocol that moves machine data from IoT gateways on the shop floor to cloud platforms where it is processed, analyzed, and turned into real-time dashboards and KPIs. It is specifically designed for scenarios where bandwidth is limited, network connections are intermittent, and thousands of devices need to communicate simultaneously.

How MQTT Works: Publish/Subscribe Architecture

MQTT does not use the request/response pattern familiar from HTTP. Instead, it uses a publish/subscribe model with three core components: publishers, subscribers, and a broker.

Component	Role	Manufacturing example
Publisher	Sends messages to a topic. Does not know or care who receives them. Completely decoupled from subscribers.	An IoT gateway on a press publishes a message to the topic `plant/line3/press7/cycle` every time the press completes a cycle.
Broker	Central message router. Receives all published messages and distributes them to matching subscribers. Manages connections, sessions, and message delivery guarantees.	Azure IoT Hub (or Mosquitto, HiveMQ, EMQX) receives messages from all IoT gateways in all plants and routes them to the MES platform.
Subscriber	Subscribes to topics and receives all messages published to those topics. Can subscribe to specific topics or use wildcards.	The MES cloud platform subscribes to `plant/+/+/cycle` to receive cycle data from all machines in all plants.
Topic	Hierarchical string that categorizes messages. Topics use forward slashes as level separators. No pre-registration needed.	`plant/wilnsdorf/line2/press4/status`, `plant/wilnsdorf/line2/press4/alarm`, `plant/wilnsdorf/line2/press4/cycle`.

The key advantage of publish/subscribe over request/response: publishers and subscribers are completely decoupled. The IoT gateway does not need to know whether one system or twenty systems are consuming its data. It publishes to a topic, and the broker handles distribution. This makes the architecture inherently scalable.

MQTT Quality of Service (QoS) Levels

MQTT defines three Quality of Service levels that determine how reliably messages are delivered. Choosing the right QoS level is critical in manufacturing, where a missed machine signal can mean undetected downtime or a lost production count.

QoS level	Delivery guarantee	How it works	Manufacturing use case
QoS 0: At most once	Fire and forget. Message is sent once. No acknowledgment. May be lost.	Publisher sends message. Broker does not confirm receipt. No retry.	Non-critical telemetry where occasional data loss is acceptable. Example: ambient temperature readings every 10 seconds.
QoS 1: At least once	Guaranteed delivery. Message is sent and acknowledged. May be delivered more than once (duplicates possible).	Publisher sends message. Broker acknowledges (PUBACK). If no acknowledgment received, publisher retries. Duplicates must be handled by the receiver.	Production counts, cycle completions, downtime events. Every event must arrive, and the receiver can handle duplicates. Most common QoS in manufacturing.
QoS 2: Exactly once	Guaranteed delivery, exactly once. No duplicates, no losses. Highest overhead.	Four-step handshake: PUBLISH, PUBREC, PUBREL, PUBCOMP. Ensures message is delivered exactly once.	Safety-critical events, financial transactions, quality decisions where duplicates would cause errors. Rarely used in high-frequency machine data due to overhead.

MQTT vs. OPC UA vs. HTTP: Protocol Comparison for Manufacturing

Dimension	MQTT	OPC UA	HTTP/REST
Communication model	Publish/subscribe via broker.	Client/server with optional pub/sub (OPC UA Part 14).	Request/response. Client polls server.
Primary use in manufacturing	Edge-to-cloud transport. Moving machine data from IoT gateways to cloud platforms over LTE, Wi-Fi, or WAN.	Machine-to-gateway or machine-to-MES communication. Rich data model with context (data types, units, ranges).	ERP integration, API calls, web dashboards. Not suitable for high-frequency machine data.
Protocol overhead	Minimal. 2-byte fixed header. Designed for low bandwidth.	Moderate. Rich data model adds overhead. Binary encoding (UA Binary) more efficient than XML.	High. Text-based headers. Not designed for constrained networks.
Network requirements	Works over LTE, satellite, unreliable Wi-Fi. Designed for intermittent connectivity.	Requires stable LAN or reliable network. Not designed for intermittent connectivity.	Requires stable network. High bandwidth consumption.
Data model	Payload-agnostic. MQTT transports bytes. Structure is defined by the application (JSON, Protobuf, binary).	Rich, standardized data model. Variables include data type, engineering unit, range, timestamp, quality. Standardized by IEC 62541.	Application-defined. Typically JSON or XML.
Security	TLS encryption, username/password, client certificates. Broker-level access control.	TLS encryption, X.509 certificates, application-level security, fine-grained access control per node.	TLS (HTTPS), OAuth, API keys.
Scalability	Excellent. Broker handles millions of connections. Designed for massive IoT deployments.	Good for plant-level. Each server has connection limits. Not designed for millions of concurrent connections.	Good with load balancing. Higher resource consumption per connection.

In practice, MQTT and OPC UA are not competitors. They are complementary. OPC UA is the standard for reading rich, contextualized data from modern PLCs on the shop floor. MQTT is the standard for transporting that data efficiently from the edge to the cloud. A typical IIoT architecture uses OPC UA at the machine level and MQTT for the cloud transport layer.

MQTT in Manufacturing: Where It Is Used

Use case	How MQTT is used	Why MQTT is the right choice
IoT gateway to cloud MES	IoT gateways on machines publish cycle counts, machine states, alarms, and process data to an MQTT broker (e.g., Azure IoT Hub). The cloud MES subscribes and processes the data.	Low bandwidth (LTE). Intermittent connectivity (cellular). Thousands of gateways publishing simultaneously. MQTT handles all of this natively.
Multi-plant data aggregation	IoT gateways in plants across multiple countries publish to a central cloud broker. The MES platform subscribes to all plants and provides unified dashboards and KPIs.	Plants may have different network conditions (LAN in Germany, LTE in Mexico, Wi-Fi in China). MQTT works across all network types with consistent behavior.
Brownfield machine connectivity	Digital I/O gateways capture machine signals (cycle complete, running/stopped, alarm) and publish them via MQTT. No LAN infrastructure needed in the plant.	Many brownfield plants have no Ethernet infrastructure on the shop floor. MQTT over LTE eliminates the need for network cabling entirely.
Alarm and event streaming	PLC alarms captured via OPC UA at the edge are forwarded to the cloud via MQTT. The MES platform correlates alarms with downtimes and quality defects.	Alarm data is event-driven and bursty. MQTT's pub/sub model handles variable message rates efficiently without polling overhead.
Energy monitoring	Energy meters connected to analog inputs (4-20 mA) on IoT gateways publish consumption data via MQTT to the cloud platform for real-time energy dashboards.	Energy data is continuous, low-bandwidth telemetry. MQTT's minimal overhead is ideal for this type of data stream.

How SYMESTIC Uses MQTT

Architecture layer	MQTT role	How SYMESTIC implements it
IoT gateway to cloud	MQTT is the transport protocol between IoT gateways on the shop floor and the SYMESTIC cloud platform on Microsoft Azure.	DI-Gateways (6x DI, 2x AI, LTE/Ethernet/Wi-Fi) publish machine data via MQTT to Azure IoT Hub. Third-party gateways (e.g., IXON) also use MQTT.
Data buffering	MQTT's persistent sessions and retained messages ensure that data is not lost during temporary connectivity interruptions. The gateway buffers and retransmits.	IoT gateways buffer machine data locally during connectivity gaps. When the connection is restored, buffered messages are published to the broker in order.
Multi-site connectivity	MQTT enables plants in different countries with different network conditions to connect to the same cloud platform without custom integration per site.	Carcoustics: 500+ machines across 7 countries (Germany, Poland, Slovakia, Czech Republic, Mexico, USA, China) connected via IXON IoT devices and MQTT to Azure.
No LAN dependency	MQTT over LTE eliminates the requirement for Ethernet infrastructure on the shop floor. Critical for brownfield plants where network cabling is impractical.	Klocke (pharmaceutical packaging): all lines connected via DI-Gateways without any LAN infrastructure, using cellular connectivity and MQTT. Deployed in 3 weeks.
Scalability	MQTT's broker architecture scales from one gateway to thousands without architectural changes. Adding a new machine means adding a new publisher.	15,000+ machines connected across 18 countries. Flat-rate-per-plant pricing. Unlimited users, unlimited dashboards, unlimited shopfloor clients.

MQTT Security in Industrial Environments

Security layer	MQTT capability	Industrial implementation
Transport encryption	TLS 1.2/1.3 encryption for all data in transit between gateway and broker.	All MQTT connections to Azure IoT Hub use TLS. No unencrypted connections allowed.
Device authentication	X.509 client certificates, SAS tokens, or username/password authentication per device.	Each IoT gateway authenticates with a unique device identity. No shared credentials across gateways.
Topic-level access control	Broker-level ACLs restrict which devices can publish or subscribe to which topics.	Gateway for Plant A can only publish to Plant A topics. Cannot read or write data from Plant B.
Network segmentation	MQTT operates over a single outbound TCP port (typically 8883 for TLS). No inbound ports need to be opened on the factory firewall.	IT/OT segmentation preserved. The gateway initiates the connection outbound. No inbound firewall rules required.

Frequently Asked Questions About MQTT

What does MQTT stand for?

MQTT originally stood for Message Queuing Telemetry Transport. The current OASIS standard (MQTT v5.0 and v3.1.1) treats "MQTT" as the protocol name without expanding the acronym, because the protocol does not actually implement message queuing in the traditional sense. It is a publish/subscribe protocol, not a message queue.

Is MQTT the same as OPC UA?

No. MQTT and OPC UA serve different purposes and are complementary. OPC UA is designed for machine-level communication with a rich, standardized data model (data types, engineering units, quality codes). MQTT is designed for lightweight, efficient transport of data from edge to cloud. In a typical manufacturing IIoT architecture, OPC UA reads data from the PLC, and MQTT transports it to the cloud platform.

Which QoS level should I use for machine data?

For most manufacturing use cases, QoS 1 (at least once) is the right choice. It guarantees that every cycle count, downtime event, and alarm arrives at the cloud platform, while keeping the protocol overhead low. The receiving application handles the occasional duplicate. QoS 0 is acceptable for high-frequency, non-critical telemetry. QoS 2 is rarely needed in manufacturing due to the overhead of the four-step handshake.

Can MQTT work without LAN infrastructure in a plant?

Yes. MQTT is specifically designed for constrained and unreliable networks. IoT gateways with built-in LTE modems can publish machine data via MQTT over cellular networks, completely bypassing the need for Ethernet cabling on the shop floor. This is particularly valuable in brownfield plants where installing network infrastructure would be disruptive and expensive.

How does MQTT handle network interruptions?

MQTT provides several mechanisms for handling connectivity gaps. Persistent sessions allow a reconnecting client to resume its subscriptions without re-subscribing. The "Last Will and Testament" feature notifies subscribers when a device disconnects unexpectedly. On the gateway side, local data buffering stores messages during outages and publishes them in order when the connection is restored.