# MQTT Protocol Explained: Brokers, Topics and QoS for Reliable Industrial IoT Data

> What is the MQTT protocol and how does it work? Learn brokers, topics, QoS levels and security, then build a reliable IoT data flow with a 7-step checklist.

Source: https://digitalbridge.com.tr/en/blog/mqtt-protocol-industrial-iot.html
Publisher: Digital Bridge Teknoloji (https://digitalbridge.com.tr)
Topic: IoT & Hardware
Published: 2026-09-28 · Updated: 2026-10-30

The MQTT protocol is a lightweight publish/subscribe messaging standard: devices send data to a central broker under a named topic, and any application needing that data subscribes to the topic. It uses little bandwidth and copes well with unreliable links, making it one of the most widely used ways to move sensor data from the field to the cloud.

## Key takeaways

- With MQTT a device connects only to the broker; SCADA, reporting and alarm software subscribe to the same data without touching the device.
- QoS 0 delivers at most once, QoS 1 at least once and QoS 2 exactly once; QoS 1 is common for alarms and counters.
- A retained message keeps the last value on a topic; Last Will publishes "device offline" automatically after an unexpected disconnect.
- MQTT security comes from configuration: TLS encryption (usually port 8883), per-device identity, topic-level access control and a broker kept off the internet.
- MQTT complements Modbus and OPC UA rather than replacing them: a gateway reads field data and publishes it to the centre over MQTT.

## Why does IoT field data go missing?

Most IoT projects start small: a handful of sensors and a device that posts readings straight to a web service. For the first few weeks nothing looks wrong. Then the number of sites grows, a cellular link drops overnight, the server goes down for maintenance, and every reading sent during that window quietly disappears.

The underlying problem is architecture rather than protocol. When each device talks directly to each application, adding a new report or a new consumer means changing firmware on devices already in the field. Pushing updates to hundreds of remote units is slow, and every update carries risk. The wider picture of industrial IoT in the factory is explained in [what is IIoT](https://digitalbridge.com.tr/en/blog/what-is-iiot.html).

MQTT breaks that coupling. The device only knows the broker; the [SCADA](https://digitalbridge.com.tr/en/blog/what-is-scada.html) system, the reporting tools, the alarm service and the [time-series database](https://digitalbridge.com.tr/en/blog/time-series-database-iot-data.html) each subscribe to the same data without knowing about one another. You add a consumer without touching a single device.

## What does an unreliable IoT data flow cost?

Small gaps turn into large blind spots once device counts climb. [IoT Analytics' State of IoT 2025 report](https://iot-analytics.com/number-connected-iot-devices/) expects connected IoT devices to grow 14% to 21.1 billion in 2025 and reach 39 billion by 2030. At that scale, one bespoke connection per device simply stops being manageable.

The first bill arrives on the shop floor. If an alarm is raised at the sensor but never reaches the control room, the stoppage only "starts" when someone happens to notice it.

> According to [Siemens' The True Cost of Downtime 2024 report](https://assets.new.siemens.com/siemens/assets/api/uuid:1b43afb5-2d07-47f7-9eb7-893fe7d0bc59/TCOD-2024_original.pdf), large plants average **25 unplanned downtime incidents a month** and lose **27 hours** of production a month.

The second bill is paid in security. A broker left open without passwords or encryption exposes every reading in the field, and sometimes every command as well. The [Verizon 2026 Data Breach Investigations Report](https://www.verizon.com/business/resources/T1ae/reports/2026-dbir-data-breach-investigations-report.pdf) found ransomware present in 48% of all breaches, and any service left unprotected on the internet, an IoT broker included, is a potential way in. The same report found that exploitation of vulnerabilities became the most common initial access vector, at 31% of breaches, so keeping broker software patched is part of security too.

## How the MQTT protocol works: five core ideas

[mqtt.org](https://mqtt.org/) describes MQTT as an OASIS (Organization for the Advancement of Structured Information Standards) standard for Internet of Things (IoT) messaging built on a lightweight publish/subscribe model. Five ideas cover most of what an engineering team needs:

- **Broker:** the server every message passes through. It decides who may connect and which topics each client may publish or subscribe to.
- **Topic:** the address of a message, written as a slash-separated path such as `site1/line2/press3/oil_temp`. The `+` wildcard matches one level and `#` matches everything below it.
- **QoS (quality of service):** QoS 0 means at most once, QoS 1 at least once and QoS 2 exactly once. Higher levels add assurance, and also traffic and latency.
- **Retained messages:** the broker keeps the last value on a topic, so a dashboard that subscribes later shows the current state straight away instead of a blank panel.
- **Last Will and Testament:** when connecting, a device registers a message to publish if it drops off unexpectedly. "Device offline" then reaches the alarm system without anyone polling for it.

Connections run over TCP (Transmission Control Protocol); port 1883 is conventionally used for unencrypted traffic and 8883 for TLS (Transport Layer Security). MQTT 5, the current version as of 2026, added features that matter in operations, including reason codes on errors, message expiry and shared subscriptions for load-balancing consumers.

On industrial sites you will often meet Sparkplug B, a specification from the Eclipse Foundation. MQTT leaves the payload format open; Sparkplug fixes the topic structure, data types and device birth and death messages, so equipment from different vendors appears consistently in one SCADA system.

## MQTT vs HTTP, OPC UA and Modbus: protocol comparison

MQTT is not the answer to every integration question; in building automation, for example, HVAC and lighting controllers usually speak [the BACnet protocol](https://digitalbridge.com.tr/en/blog/bacnet-building-automation.html). Placing MQTT next to the alternatives you are most likely to meet, HTTP, OPC UA (Open Platform Communications Unified Architecture) and Modbus TCP, makes its role clearer:

| Criterion | MQTT | HTTP / REST | OPC UA | Modbus TCP |
|---|---|---|---|---|
| Communication model | Publish/subscribe via a broker | Request/response | Client/server plus PubSub | Polling (master/slave) |
| Data model | Open; standardised by Sparkplug | Open, usually JSON | Rich, hierarchical, typed | Numbered registers |
| Tolerance of broken links | High: QoS, sessions, Last Will | Low: retries left to the app | Moderate | Low |
| Bandwidth | Very small header overhead | Relatively high | Moderate | Low |
| Typical use | Field to cloud, fan-out to many consumers | Application-to-application integration | Machines, SCADA and MES | Meters, analysers, simple devices |

In practice MQTT, HTTP, OPC UA and Modbus are links in one chain, not competitors. An energy meter is read over [Modbus](https://digitalbridge.com.tr/en/blog/modbus-rtu-vs-tcp.html), machine data is modelled with [OPC UA](https://digitalbridge.com.tr/en/blog/opc-ua-explained.html), and a gateway publishes the result over MQTT.

Talking to business systems is usually handled in a separate [API integration](https://digitalbridge.com.tr/en/blog/api-integration-explained.html) layer: MQTT gathers data from the field, while APIs carry it on to applications such as ERP or CRM.

Filtering and buffering data beside the line before it leaves the site is covered in our piece on [edge computing in manufacturing](https://digitalbridge.com.tr/en/blog/edge-computing-manufacturing.html). Which bearer network the device uses is a separate decision again, discussed in [LoRa vs NB-IoT vs cellular](https://digitalbridge.com.tr/en/blog/lora-vs-nb-iot-vs-cellular.html); see also our glossary entry on [NB-IoT](https://digitalbridge.com.tr/en/glossary.html#nb-iot).

## How to build an MQTT data flow: a seven-step framework

Standing up an MQTT broker takes an afternoon. Making the MQTT data flow something you can run for years without surprises takes design. This order heads off the most common mistakes:

1. **Inventory the data.** List each device, the values it produces, how often and in what unit. Plan to send values only when they change (report by exception) rather than repeating a flat reading every second.
2. **Design the topic hierarchy.** Fix the order, for example organisation, site, area, device, measurement, and stick to lower-case naming rules. Keep serial numbers and personal data out of topic names.
3. **Choose QoS per stream.** Frequent temperature readings usually live happily on QoS 0. Counters, production totals and alarms need QoS 1 with a consumer that discards duplicates; reserve QoS 2 for the few flows that truly need it.
4. **Standardise the payload.** Every message should carry value, unit and a timestamp taken from the device clock. Consider Sparkplug B where consistency across vendors matters.
5. **Build security in from day one.** Make TLS mandatory, give every device its own identity, and use access control lists so a device can publish only to its own topics. Never expose the broker directly to the internet.
6. **Test for disconnection.** Pull the plug deliberately and check that Last Will, persistent sessions and on-device buffering deliver a complete data set once the link returns.
7. **Monitor and document.** Track connected clients, queue growth and certificate expiry on the broker, and write down the template for onboarding a new device.

Before go-live, run the installation past this checklist:

| Checkpoint | Question to ask | Consequence of a wrong answer |
|---|---|---|
| Encryption | Is port 1883 closed externally, with every client on TLS? | Data and passwords cross the network in clear text |
| Identity | Does each device have its own credentials or certificate? | One leaked password opens the whole estate |
| Authorisation | Can a device publish only to its own topics? | One device can impersonate another |
| Disconnection | Is data buffered while a device is offline? | Gaps in charts and incomplete reports |
| Commands | Are command topics separate and tightly permissioned? | An unauthorised user can operate field equipment |
| Monitoring | Is there an alert on broker load and connection count? | Problems surface through customer complaints |

Where MQTT carries remote commands, its security cannot be separated from the wider OT network. Network segmentation and remote access rules are covered in [OT security for SCADA](https://digitalbridge.com.tr/en/blog/ot-security-scada.html). If topics or payloads carry anything linked to a person, such as a driver ID on a vehicle tracker, that data may count as personal data under Turkey's data protection law (KVKK), much as it would under GDPR in Europe, so have the legal position reviewed before rollout.

## How Digital Bridge delivers MQTT projects

Digital Bridge starts every MQTT project with discovery and a needs analysis. We map the devices on site, their existing protocols, the connectivity available and the decisions the data has to support, then issue a written proposal setting out scope, phases and fee. Site assessments for Industry 4.0 projects are free of charge.

Where off-the-shelf hardware does not fit, our [IoT device manufacturing](https://digitalbridge.com.tr/en/technology-hardware/device-manufacturing-iot.html) service designs the circuit board, enclosure and firmware within one team. Because the same people write the firmware and the dashboard, topic structure, QoS choices and offline behaviour stay consistent on both sides. The stages are described in our [IoT device development process](https://digitalbridge.com.tr/en/blog/iot-device-development-process.html).

In the pilot we connect a few points and bring the data into our [remote monitoring platform](https://digitalbridge.com.tr/en/industry-40/remote-monitoring-saas.html). It accepts data from Modbus TCP/RTU devices, sensors publishing over MQTT and systems sending data via REST API, and runs on a monthly subscription with maps, alarm rules and a mobile app. See our [guide to IoT remote monitoring platforms](https://digitalbridge.com.tr/en/blog/remote-monitoring-iot-platform.html) for selection criteria, and [remote pump station monitoring](https://digitalbridge.com.tr/en/blog/remote-pump-station-monitoring.html) for a field example.

Inside a plant the data must also reach operators and production software. We connect MQTT values to [SCADA and HMI screens](https://digitalbridge.com.tr/en/industry-40/scada-hmi.html) and handle the ERP or MES side through our [system integration](https://digitalbridge.com.tr/en/technology-hardware/system-integrations.html) work. Our [cyber security consultancy](https://digitalbridge.com.tr/en/consultancy/cyber-security.html) team joins the project for broker and network security design.

## Where to start with MQTT

You do not need to rework the whole estate to adopt MQTT. Pick the one data flow where missing readings hurt most, write down the topic structure and QoS decisions, and run a disconnection test with a few devices. For machines with no [PLC](https://digitalbridge.com.tr/en/glossary.html#plc) at all, [retrofitting legacy machines](https://digitalbridge.com.tr/en/blog/retrofitting-legacy-machines.html) is a sensible first read, and the rest of our [IoT and hardware articles](https://digitalbridge.com.tr/en/blog/topic/iot-donanim.html) cover the surrounding decisions.

To work out how your field devices should connect over MQTT, [get in touch with our team](https://digitalbridge.com.tr/en/contact.html). During discovery we map your current setup and propose a concrete scope for a first pilot.

## Frequently Asked Questions

### What is the main difference between MQTT and HTTP?

HTTP works on request and response: the client opens a connection each time it sends or asks for data. With MQTT a device connects to the broker once and keeps the connection open, publishing whenever values change, and every subscriber receives the message at the same moment. That makes MQTT more efficient on low-bandwidth, unreliable links and when one reading has to reach several applications.

### Which MQTT QoS level should I use?

QoS 0 is enough for frequent readings where losing one sample does no harm. Use QoS 1 for data that must not be lost, such as meter counts, production totals and alarms, and make sure consumers discard duplicate messages. QoS 2 provides exactly-once delivery but generates the most traffic, so it should be kept for the small number of flows that genuinely require it.

### Is MQTT secure?

The protocol itself does not enforce security; that comes from how the broker and clients are configured. The essentials are TLS encryption, a separate identity or certificate for each device, access control lists that restrict each device to its own topics, and a broker that is never exposed directly to the internet. A broker opened without these settings can leave field data and commands visible to anyone.

### Can existing Modbus devices send data over MQTT?

Yes, and the devices themselves do not need replacing. A gateway installed on site polls Modbus RTU or TCP devices at set intervals, converts each value into an MQTT message with unit and timestamp, and publishes it to the broker. The same gateway can buffer data during outages and send only changed values, which keeps traffic on metered or low-bandwidth links to a minimum.

### What does an MQTT deployment cost?

The cost is driven by the installation around the protocol rather than MQTT itself. The main factors are the number of devices and measurement points, whether existing equipment needs gateways or new hardware, whether the broker runs on-premises or in the cloud, security and certificate management, SCADA or ERP integration and any platform subscription. A site survey and a written proposal are needed before a firm figure can be given.

### What is Sparkplug B and do I need it?

Sparkplug B is a specification that sits on top of MQTT and standardises topic structure, data types and device state messages. It is not mandatory; for small, single-vendor installations your own topic and payload rules may be perfectly adequate. It becomes valuable when equipment from several vendors must appear consistently in one SCADA system and device online or offline status has to be reported in a standard way.

### Which port does MQTT use?

MQTT runs over TCP, and port 1883 is conventionally used for unencrypted connections while 8883 is used for connections encrypted with TLS. In a secure field installation port 1883 is closed to the outside and every device connects over 8883 with its own credentials or certificate. That way readings and passwords never cross the network in clear text.