Mosquitto

What is Mosquitto?

Eclipse Mosquitto is an open-source MQTT broker that receives messages and forwards them between sensors, machines, applications and cloud platforms using the publish/subscribe principle. The broker supports MQTT 5.0, 3.1.1 and 3.1, is written in C and is lean enough to run on anything from a small edge gateway to a full server. This makes Mosquitto one of the most widely used building blocks in the Industrial Internet of Things, Edge Computing and Industrial Automation, and often the first concrete piece of software in a Unified Namespace within OT convergence.

🧠 Where does Mosquitto come from?

Roger Light started Mosquitto in 2009 as a hobby project, after seeing a presentation on MQTT at an open source conference by Andy Stanford-Clark, one of the protocol’s co-inventors. At that time no open-source MQTT broker existed. The project was later moved to the Eclipse Foundation and has since been called Eclipse Mosquitto.

Besides the broker, the project ships the command-line tools mosquitto_pub, mosquitto_sub and mosquitto_rr for testing messages, and mosquitto_passwd and mosquitto_ctrl for administration. Mosquitto is included in the package repositories of practically every Linux distribution and Raspberry Pi OS, and is available as an official Docker image.

⚙️ How does Mosquitto work?

Mosquitto is the central message broker in an MQTT architecture. Clients open a TCP connection to the broker and send or receive messages on topics:

1. A publisher, for example an edge device next to a PLC, publishes a measurement on Plant1/Line2/Robot5/Temperature.
2. Mosquitto receives the message and checks whether the client is allowed to publish on that topic.
3. Every subscriber with a matching subscription receives the message, for example SCADA, a historian, an alarm server or a cloud application.

Publishers and subscribers do not know each other: they only know the broker and the topic name. This decoupling provides scalability, low network load and asynchronous communication, which makes MQTT well suited to networks with limited bandwidth or variable latency. Wildcards (+ for a single level, # for all levels below) let a subscriber follow an entire line or plant at once.

Mosquitto also takes care of session management, QoS handling, retained messages and optional persistence to disk.

📡 Which QoS levels, retained messages and sessions does Mosquitto support?

Mosquitto supports the three MQTT QoS levels:

Higher QoS costs extra network traffic and broker memory. For critical alarms, QoS 1 is therefore the usual choice, combined with idempotent processing at the receiver.

• Retained messages - the broker keeps the last message per topic and delivers it immediately to new subscribers. Ideal for the last known machine status, configuration values, alarm status and production parameters.
• Persistent sessions - for a client with a persistent session, Mosquitto keeps its subscriptions and queues QoS 1 and QoS 2 messages while the client is offline.
• Persistence to disk - with persistence true, Mosquitto periodically writes retained messages and queues to disk so they survive a restart.
• Last Will and Testament - the broker publishes a predefined message on behalf of a client that drops off unexpectedly, useful for marking a gateway or machine as “offline”.

Together, these features increase reliability on unstable networks such as wireless links or remote sites.

🏭 Where is Mosquitto used in industry?

Within Industrial Automation, Mosquitto distributes OT data to several consumers at once:

• Machine monitoring - temperature, vibration, status and energy consumption from sensors and machines
• Edge computing - local buffering, protocol conversion and event streaming on a gateway or IPC
• Unified Namespace - all OT assets publish to one central, structured namespace
• SCADA integration - distributing process values, real-time events and alarms alongside the classic SCADA connections
• Smart manufacturing - production tracking, MES integration and feeding a digital twin
• Prototyping - with Node-RED and Mosquitto, a working data flow from machine to dashboard can be built within an hour

Common combinations are OPC UA to MQTT via a gateway, MQTT Sparkplug B as the payload standard, and a monitoring stack of Mosquitto, InfluxDB (or TimescaleDB) and Grafana for trends and dashboards. For very high volumes or long-term retention of event streams, Mosquitto is often coupled to Apache Kafka.

🔧 How do you deploy Mosquitto in an OT environment?

A practical approach for a first production-grade broker:

1. Decide its place in the architecture - choose between one broker per line at the edge, a central site broker, or both linked by a bridge. Position it according to the Purdue Model: a site broker typically belongs at level 3 or in the IDMZ, never directly reachable from the internet.
2. Design the topic structure up front - for example Site/Area/Line/Machine/Signal following the ISA-95 hierarchy. Use consistent naming, limit the depth and record the structure as a governance agreement, because topics are hard to change later.
3. Configure listeners explicitly - port 1883 only on an internal segment, 8883 with TLS for traffic between zones.
4. Set up authentication and authorisation - use the dynamic security plugin with clients, groups and roles (RBAC), or client certificates. Give each client write access only to its own topics through ACL rules.
5. Enable persistence and limits - persistence true, a suitable max_queued_messages and a maximum message size prevent memory problems with offline clients.
6. Link brokers with bridges - a bridge forwards a selection of topics to a central broker or cloud platform, with local buffering when the connection drops.
7. Monitor the broker - through the $SYS topics and an exporter to monitoring tools.

Mosquitto suits embedded systems: it has been run on a 180 MHz MIPS processor with 32 MB of RAM, and on server hardware a single instance can handle tens to hundreds of thousands of concurrent clients. In practice, performance problems mainly come from large amounts of retained data, heavy QoS 2 traffic, long queues for offline clients and unstructured topic trees.

🔐 How do you secure Mosquitto?

Because Mosquitto carries process data and sometimes commands, the broker is an attractive target within cybersecurity for OT.

Version 2.0 (December 2020) made Mosquitto secure by default: without a configuration file the broker listens only on localhost, allow_anonymous defaults to false, TLS 1.0 was disabled, and a broker started as root switches to an unprivileged user (mosquitto by default) immediately after reading its configuration. Only in the no-configuration, localhost-only mode are anonymous clients still allowed. Version 2.1 (January 2026) deprecates password_file and acl_file in favour of plugins, with removal planned for 3.0.

Mosquitto itself has no MFA; that belongs on the administration of the broker host and management interfaces. Place the broker in its own zone following the zones and conduits model of IEC 62443, behind a firewall with network segmentation, and forward broker logs to a SIEM. Recent security fixes, such as those in 2.0.19 (October 2024) and 2.0.21 (March 2025), show that patch management is needed for this small component too.

🚨 How do you make Mosquitto highly available and observable?

Broker failure means loss of telemetry, empty dashboards, missed alarms and stalled analytics. The open-source edition of Mosquitto is a single process without built-in clustering. High Availability and redundancy are therefore achieved with:

• Edge buffering - local brokers or gateways that hold data and forward it through a bridge as soon as the central broker is back
• Failover at infrastructure level - a virtual machine or container with automatic restart, for example under Docker or Kubernetes, with persistent storage
• Commercial clustering - Pro Mosquitto from Cedalo offers active-passive and active-active clustering with session persistence across nodes

These metrics are fed through an exporter into Prometheus, InfluxDB or Grafana.

🔄 How does Mosquitto differ from traditional OT communication?

Mosquitto does not replace real-time fieldbuses; it adds a data distribution layer above the control layer. It is also complementary rather than competing with OPC UA: OPC UA provides the information model, MQTT the transport to many consumers.

🏗️ What role does Mosquitto play in IT/OT convergence?

Within IT OT Convergence, Mosquitto is an event-driven communication layer between OT assets and IT platforms. It supports real-time data streaming, predictive maintenance, cloud analytics and Industrial AI as part of Industry 4.0. A bridge can forward data to cloud IoT services such as AWS IoT Core. In critical infrastructure, that cloud link is often restricted or made one-way because of security and compliance requirements, such as those of the Dutch Cybersecurity Act.

❓ Frequently asked questions

Is Mosquitto free to use in a factory?

Yes, Eclipse Mosquitto is open source under the Eclipse Public License 2.0 and the Eclipse Distribution License 1.0 and may be used commercially free of charge. For clustering, a management console and support with fixed response times, Cedalo offers the paid Pro Mosquitto edition.

Which ports does Mosquitto use?

Mosquitto uses port 1883 for unencrypted MQTT and port 8883 for MQTT over TLS by default. A listener can also offer MQTT over WebSockets; since version 2.1, the broker has its own built-in WebSockets implementation that no longer depends on the libwebsockets library.

Why does Mosquitto refuse connections after upgrading to 2.0?

Since Mosquitto 2.0, allow_anonymous defaults to false and, without configuration, the broker listens only on localhost. An existing installation with a listener but no authentication therefore rejects clients; the fix is a password file, the dynamic security plugin, or deliberately setting allow_anonymous true on an isolated network.

Can Mosquitto run as a cluster?

The open-source edition of Mosquitto has no built-in clustering and runs as a single process. You achieve high availability with edge buffering, bridges and automatic restart at infrastructure level, or with the commercial Pro Mosquitto, which offers active-passive and active-active clustering.

What is the difference between Mosquitto and MQTT?

MQTT is the open messaging protocol standardised by OASIS, whereas Mosquitto is a specific broker that implements that protocol. Other brokers such as HiveMQ, EMQX and VerneMQ implement the same protocol, so clients are interchangeable between brokers.

Is Mosquitto suitable as the broker for a Unified Namespace?

Mosquitto is a popular broker for a Unified Namespace at a single site, thanks to its low resource needs and full MQTT 5 support. For a UNS spanning several sites or with strict availability requirements, you combine Mosquitto with per-site bridges or choose a broker with clustering.

📌 In summary

Eclipse Mosquitto is the lightweight, open-source MQTT broker that since 2009 has been distributing OT data from PLCs, sensors and edge devices to SCADA, historians, dashboards and the cloud. Its strength lies in simplicity and efficiency; the points of attention are security, topic design and availability, because the open-source edition has no clustering.

Mosquitto is an excellent data distribution layer for the IIoT and a Unified Namespace, provided you get authentication, topic ACLs, TLS, segmentation and patching right from day one.