Every industrial IoT system relies on a central backbone that keeps data flowing: the MQTT broker. It manages thousands of device connections, routes data between machines, and keeps communication stable even when networks fluctuate. Without it, no industrial or IoT infrastructure can maintain secure, real-time data exchange at scale.
As the company behind Eclipse Mosquitto™, the world’s most widely adopted MQTT broker, Cedalo has seen firsthand how mission-critical industrial systems depend on the robustness, stability, and scalability of MQTT infrastructures. This guide reflects that practical perspective: what MQTT brokers do, how they work, and what enterprises must consider when operating them at scale.
MQTT Broker: Key takeaways
- An MQTT broker enables reliable, low-latency data communication in industrial IoT environments.
- Scalable MQTT broker architectures with clustering and monitoring ensure uptime and predictable operation across all connected systems.
- Industrial MQTT deployments can take the form of self-hosted, managed, or hybrid architectures. Each serves different requirements for control, compliance, and scalability, and the optimal model varies by company and production environment.
- Cedalo delivers enterprise-grade MQTT for industrial setups: Pro Mosquitto extends Eclipse Mosquitto with high availability and security, while the Cedalo MQTT Platform manages these Mosquitto deployments centrally and adds enterprise integrations.
What is an MQTT broker?
An MQTT broker is the central messaging hub in a publish-subscribe communication system. It operates using MQTT, a lightweight publish/subscribe protocol designed for efficient, reliable data exchange among connected devices. The broker receives, filters, and distributes messages, so each subscriber gets exactly the data it needs.
In an IoT network, thousands of sensors send data simultaneously. Instead of communicating directly, they use the broker to organize traffic, avoid overload, and keep data flowing smoothly. The broker manages connections, stores retained messages, and allows devices to resume sessions when reconnecting.
Data flow in MQTT always follows the same structure:
1. Publisher → 2. Broker → 3. Subscriber
| Role | Function | Example |
|---|---|---|
| Publisher | Sends data to a defined topic | A sensor reports temperature |
| Broker | Manages the topic and forwards messages | Receives the temperature and routes it |
| Subscriber | Receives data from the subscribed topic | A dashboard visualizes the temperature trend |
This decoupled model ensures low network load and allows flexible communication, easy onboarding of new devices, and the ability to scale from a handful of connections to millions. For a detailed overview of the underlying pattern, see the Pub/Sub model fundamentals.
How does an MQTT broker work?
The MQTT broker manages how data moves between connected devices. It receives messages from publishers, checks subscriber topics, and routes each message to the right recipients, a process known as the publish-subscribe pattern (pub/sub).
How message routing works in an MQTT broker:
1. Connection setup
Each device connects to the broker over a reliable TCP, TLS, or WebSocket connection that ensures messages are delivered in the correct order. During this step, the client sends a unique client ID, authentication credentials, and a keep-alive interval. If the network connection drops, the client reconnects automatically based on its configuration and keep-alive settings.
2. Publishing and subscribing
Publishers send messages to topics (e.g. factory/line1/temperature). The broker checks all subscriptions and forwards messages only to clients with matching topic filters. Wildcards such as factory/+/temperature allow flexible subscription patterns.
3. Quality of Service (QoS)
MQTT defines three QoS levels that control delivery reliability:
| Level | Description | Typical use case |
|---|---|---|
| QoS 0 | ”At most once”: the broker sends the message once without confirmation. Fastest option, but delivery is not guaranteed. | Frequent telemetry |
| QoS 1 | ”At least once”: the receiver confirms receipt. This ensures the message is delivered, but the recipient may get the same message more than once. | Status updates |
| QoS 2 | ”Exactly once”: the broker and client exchange multiple confirmation steps to guarantee that each message arrives exactly once. | Control commands |
Choosing the right QoS depends on how critical your data is. Many IoT systems combine all three levels: QoS 0 for high-frequency telemetry, QoS 1 for important status updates, and QoS 2 for commands and control messages that must arrive exactly once.
4. Session and Last Will and Testament (LWT)
The broker maintains client sessions, allowing devices to reconnect without losing state. If a device disconnects unexpectedly, the broker publishes the configured Last Will message to notify subscribed clients.
This mechanism is critical for industrial reliability. It enables state awareness, supports automatic recovery, and ensures operational continuity even during temporary network interruptions or device failures.
Scale your MQTT broker beyond a single node
Pro Mosquitto extends Eclipse Mosquitto with clustering and high availability, and the Cedalo MQTT Platform manages your brokers with central monitoring and control.
What are the technical requirements for an MQTT broker?
Industrial IoT systems demand stability, high availability, security, and scalability. The following aspects define enterprise-grade MQTT performance:
Scalability and performance
IoT networks can grow to millions of connections. To operate reliably at this scale, a high-performing MQTT broker must scale horizontally across clustered nodes, distribute load automatically, and minimize resource usage per connection.
Key factors:
- Horizontal scaling: multiple broker instances working as one cluster.
- Load distribution: balanced routing of connections, subscriptions, and message traffic.
- Resource efficiency: minimal memory and CPU usage per connection.
Security and access control
Industrial data often carries sensitive information. A secure MQTT broker enforces authentication, encryption, and role-based access control (RBAC).
| Security layer | Purpose | Example |
|---|---|---|
| Authentication | Verifies client identity | Username/password or certificates |
| Authorization | Defines topic access rights | Role-based permissions, ACLs |
| Encryption | Secures data in transit | MQTT over TLS or mutual TLS (mTLS) |
Audit trails, policy enforcement, and compliance features provide the traceability that is essential in manufacturing, energy, and other regulated sectors.
Transport security: TLS and mTLS
To protect industrial data in transit, MQTT brokers use transport-level encryption based on Transport Layer Security (TLS). TLS ensures the confidentiality and integrity of all messages exchanged between clients and the broker.
For higher security requirements, mutual TLS (mTLS) authenticates both clients and brokers using X.509 certificates. This approach is widely used in industrial environments with strict security and compliance demands, where device identity, trust boundaries, and secure communication are mandatory.
Protocol support and integration
Enterprise-grade MQTT brokers must be fully compliant with the MQTT 3.1.1 and MQTT 5.0 standards, supporting all QoS levels and advanced MQTT 5 features such as user properties, session expiry, and enhanced flow control.
For Industrial IoT use cases, Sparkplug B compatibility is increasingly important. Sparkplug B enables structured, state-aware, and interoperable data exchange between PLCs, SCADA systems, historians, and enterprise applications.
Modern IIoT architectures depend on reliable data pipelines that connect machines, applications, and cloud systems. This is why native MQTT integrations with a wide range of enterprise technologies are another key factor, including for example Kafka, InfluxDB, MongoDB, Azure Event Hubs, Google Pub/Sub, and Amazon Redshift.
This bridges the gap between Operational Technology (OT) and IT systems, ensuring that data flows seamlessly among devices, monitoring tools, analytics pipelines, databases, and business applications.
Reliability and monitoring
High availability is essential in industrial IoT environments. A production MQTT broker must provide persistent storage, automated failover mechanisms, and full operational visibility to ensure continuous data flow, even during network or node failures.
A centralized platform provides dashboards, alerts, and configuration control across all nodes. All metrics should be exportable, for example to Prometheus or InfluxDB, for custom monitoring and long-term analysis.
Typical operational metrics include:
- Connection count and session state
- Publish / receive / queued / dropped message rates
- Memory and CPU utilization
- Queue lengths and retained message counts
- Cluster health and node synchronization status
These capabilities enable early anomaly detection and reliable 24/7 operation in industrial environments.
How to choose the right deployment model for an MQTT broker
Choosing the right MQTT broker setup depends on how much control, security, and scalability your environment requires. The optimal architecture is individual and can vary by company, infrastructure, and regulatory requirements. Self-hosted, managed, and hybrid models each offer clear advantages, depending on your operational goals.
Self-hosted MQTT broker: on-premises
Deploying an MQTT broker on-premises means running all infrastructure within the organization’s physical facilities. This setup is ideal for industries with strict data residency and compliance requirements, especially when sensitive internal networks and devices (such as shopfloor machinery) must never be exposed to the internet. Industrial environments often rely on segmented networks, where machines may lack proper security hardening, making local-only deployment critical for safety and regulatory reasons.
Real-world example: many manufacturers operate on-premises brokers directly on their shopfloor networks to collect telemetry from CNC machines, PLCs, and sensors without exposing production systems to the internet.
Advantages:
- Maximum control over all data, processes, and security policies.
- Immediate local network access and integration with plant systems.
- Meets stringent compliance and regulatory requirements, ensuring no shopfloor network exposure.
Considerations and drawbacks:
- Requires dedicated IT resources for maintenance and updates.
- Hardware and facility constraints may limit scalability and failover.
- Security of internal networks must be actively managed, with isolated environments and no internet access for vulnerable devices.
Self-hosted MQTT broker: private cloud
Private cloud deployments run the MQTT broker on virtualized infrastructure owned or exclusively controlled by the enterprise, often in its own datacenter or dedicated cloud resources. This option balances control with modern scalability and automation.
Real-world example: in many private cloud deployments, global manufacturers run MQTT broker clusters within their own cloud environments to connect multiple plants via a unified, fully controlled MQTT backbone. This allows devices and applications across different sites to publish and consume data securely, while preserving complete control over network segmentation, compliance, and integration with existing OT/IT systems.
Advantages:
- Full control over data, configuration, and security policies.
- Direct integration with your own monitoring tools, data pipelines, and cloud infrastructure landscape.
- Flexible use of broker clusters: scale, move, or segment MQTT brokers in your infrastructure yourself and without external restrictions.
Considerations:
- Requires internal expertise in cloud operations, monitoring, and security configuration.
- Scaling and high availability depend on in-house infrastructure.
- Upfront design is needed for high availability and disaster recovery.
Managed MQTT broker
In managed cloud deployments, the MQTT broker is operated by a service provider, with hosting, scaling, monitoring, and backups handled externally. The customer accesses broker functionality with minimal infrastructure worries. This is best for teams that want to reduce operational overhead while maintaining MQTT performance and reliability.
Real-world example: distributed service organizations and industrial OEMs frequently rely on managed MQTT brokers to securely onboard gateways and devices from remote customer sites or field deployments. This enables large-scale fleet monitoring, remote diagnostics, and service dashboards without operating their own MQTT infrastructure.
Advantages:
- No infrastructure management or hardware overhead.
- Rapid rollout and scaling from anywhere in the world.
- Regular patches, monitoring, and support from experts.
Considerations:
- Less flexibility and less control over the underlying system and data location.
- Data residency and compliance depend on the provider region and shared controls.
- Possible limitations in security compliance or network integration.
- Stronger vendor dependency for uptime and custom integrations.
Hybrid MQTT architectures
A hybrid MQTT broker deployment flexibly combines on-premises, private cloud, and managed cloud resources, enabling organizations to optimize control, scalability, and integration for any workload or geography.
Enterprises often run brokers on-premises for maximum security, compliance, and real-time operations, while a private cloud broker acts as the central connectivity point, creating a unified, secure backbone across all distributed brokers. Hybrid setups can also integrate managed cloud brokers to handle analytics, global bridging, or backup, ensuring seamless and resilient operation across diverse infrastructure landscapes.
Real-world example: hybrid deployments are common in larger industrial environments, where edge brokers inside production lines handle time-critical local machine communication, while a central cloud or datacenter broker provides unified connectivity and an MQTT backbone across multiple sites. This allows analytics, reporting, and fleet-level monitoring systems to consume consistent, normalized data from every location.
| Requirement | Self-hosted MQTT broker | Managed MQTT broker | Hybrid |
|---|---|---|---|
| Data confidentiality | Full control | Moderate, depends on provider | Full to moderate |
| Scaling needs | Manual or user-controlled | Automatic and on-demand | Manual or automatic, depends on where brokers run |
| Maintenance effort | In-house | Lower, provider-managed | Shared, split between in-house and provider |
| Integration | Best for OT/IT, legacy, and secure networks | Best for cloud ecosystems | Best for unified multi-environment architectures |
Best practices for operating an MQTT broker
Operating an MQTT broker successfully means keeping it stable, secure, and transparent over time. These best practices show how to monitor performance, protect access, control configurations, and recover quickly after failures.
1. Monitor performance and system health
A production broker should be tracked through key metrics such as:
- Connection count: number of active clients
- Throughput: messages processed per second
- Latency: time between publish and delivery
- Error rate: failed connections or dropped packets
Dashboards and alerts provide real-time visibility. Trend analysis helps detect load peaks or memory issues before they cause downtime.
2. Maintain security and access management
Security remains an ongoing process. Rotate credentials, manage certificates centrally, and enforce RBAC to restrict user permissions. Regularly review audit logs and encryption settings to stay compliant with internal and external security standards.
3. Control configuration and version management
Use consistent configuration templates and version tracking to document every change. In clustered or multi-node scenarios, synchronize settings to prevent message routing errors or connection conflicts.
4. Enable logging and auditing
Maintain detailed logs for connections, topics, security events, and system changes. Use audit trails for compliance, especially in regulated industries.
5. Implement high availability and backups
Use clustering and failover setups to maintain uptime during node failures. Schedule regular backups of broker configuration and persistent data. Test recovery procedures to ensure rapid restoration after failures or updates.
6. Document and automate operations
Maintain clear operational procedures. Use automation tools for deployments, configuration management, and rolling updates to reduce human error.
7. Stay up to date
Regularly update broker software and all dependencies to patch vulnerabilities and access new features. Subscribe to vendor and security mailing lists for critical alerts.
Choosing an MQTT broker that scales with your infrastructure
A dependable MQTT broker keeps industrial communication across machines, plants, and cloud systems stable and secure. For engineers and system architects, it provides the foundation for data transparency, compliance, and automation at scale.
Your advantages with Cedalo:
- Proven Mosquitto technology with enterprise-grade stability
- Enterprise-grade clustering, monitoring, and security designed for industrial use
- Central management for full control and minimal downtime
- Scalable architecture from edge to multi-site production
Cedalo is the company behind Eclipse Mosquitto™, giving enterprises a combination of open-source trust and commercial reliability unmatched in the industry.
Scale your MQTT architecture with the Cedalo MQTT Platform
Gain full control over message flow, clustering, and monitoring. Pro Mosquitto builds on Eclipse Mosquitto, and the Cedalo MQTT Platform manages your deployments centrally.
MQTT Broker: Frequently Asked Questions
What are the benefits of using an MQTT broker in industrial IoT?
An MQTT broker manages all data exchange between connected devices and applications, ensuring reliable, real-time, and ordered communication even in unreliable networks. In industrial IoT, it enables monitoring, predictive maintenance, and seamless integration between machines, analytics tools, and cloud systems, all with minimal network overhead.
How does MQTT compare to other messaging protocols?
MQTT is optimized for low-bandwidth, latency-sensitive environments such as factory networks and mobile devices. Compared to AMQP or Kafka, it provides a simpler publish-subscribe model, minimal overhead, and predictable performance on constrained hardware. For a detailed comparison between MQTT, AMQP, and Kafka, see the complete MQTT protocol guide.
What security features should an enterprise MQTT broker include?
An enterprise MQTT broker must support TLS encryption, authentication, and role-based access control to protect critical data. Additional features like audit logs, monitoring, and compliance tracking ensure that communication remains secure even in regulated structures. Cedalo extends Mosquitto with centralized user management, certificate-based access control, and detailed audit logs for full operational traceability.
What is the role of MQTT in connecting OT and IT systems?
MQTT bridges operational technology (OT) and information technology (IT) by creating a shared data layer. Through the MQTT broker, machine data, ERP systems, and cloud applications communicate using structured topics, enabling transparent, consistent, event-driven data exchange across the entire organization.
Can an MQTT broker support hybrid architectures across edge and cloud?
Yes. Modern brokers support hybrid deployments where local instances manage real-time communication, while cloud brokers provide global connectivity, coordination, and unified access across distributed sites. This architecture combines the reliability of edge computing with the scalability, flexibility, and reach of cloud systems.
What makes an MQTT broker enterprise-ready?
Key requirements include high availability (clustering and failover), built-in monitoring, fine-grained access control, auditing, predictable performance, and integration with corporate security and data infrastructures.
Why choose Cedalo for improved operational reliability?
Cedalo is the company behind Eclipse Mosquitto™, the world’s most widely deployed, trusted, and resource-efficient MQTT broker. Pro Mosquitto builds on that open-source broker and adds enterprise capabilities such as clustering and high availability, while the Cedalo MQTT Platform manages these Mosquitto deployments with centralized management, advanced monitoring, security, and deep integrations. This combination of open-source reliability and enterprise-grade functionality delivers compatibility, performance, and trust for industrial environments.
