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.
Why field data goes 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.
MQTT breaks that coupling. The device only knows the broker; the SCADA system, the reporting tools, the alarm service and the time-series database each subscribe to the same data without knowing about one another. You add a consumer without touching a single device.
What unreliable data flow really costs
Small gaps turn into large blind spots once device counts climb. IoT Analytics' State of IoT 2025 report 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, large plants average 25 unplanned downtime incidents a month and lose 27 hours of production a month.
The second bill is 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 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.
How the MQTT protocol works: five core ideas
mqtt.org describes MQTT as an OASIS standard for 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; port 1883 is conventionally used for unencrypted traffic and 8883 for TLS. MQTT 5 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. Placing it next to the alternatives you are most likely to meet 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 these protocols are links in one chain, not competitors. An energy meter is read over Modbus, machine data is modelled with OPC UA, and a gateway publishes the result over MQTT.
Talking to business systems is usually handled in a separate API integration 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. Which bearer network the device uses is a separate decision again, discussed in LoRa vs NB-IoT vs cellular.
Building an MQTT data flow: a seven-step framework
Standing up a broker takes an afternoon. Making it something you can run for years without surprises takes design. This order heads off the most common mistakes:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- 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. 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
We start 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 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.
In the pilot we connect a few points and bring the data into our remote monitoring platform. 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 for selection criteria, and remote pump station monitoring 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 and handle the ERP or MES side through our system integration work. Our cyber security consultancy team joins the project for broker and network security design.
Where to start
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 at all, retrofitting legacy machines is a sensible first read, and the rest of our IoT and hardware articles cover the surrounding decisions.
To work out how your field devices should connect over MQTT, get in touch with our team. During discovery we map your current setup and propose a concrete scope for a first pilot.