MQTT Tenant Isolation: Keeping Customers' Data Separate

MQTT tenant isolation is what guarantees that one customer can never read, write or slow down another customer's messages. In this article you will learn the difference between logical and physical isolation, how noisy-neighbor protection works, which failure modes to test for, and how to choose the right level of separation for each customer.

Why Tenant Isolation Matters

If your product connects devices that belong to different customers, the broker is holding their data side by side. A single mistake, such as a wildcard subscription that matches too much, a shared credential, or a client ID collision, can expose one customer's telemetry to another or let a misbehaving fleet degrade everybody's service. Those incidents are hard to explain to customers and expensive to clean up.

Isolation has three dimensions, and a good design addresses all of them:

1. Confidentiality. A tenant cannot read another tenant's messages, retained values or session data.
2. Integrity. A tenant cannot publish into another tenant's topics or take over its sessions.
3. Availability. A tenant cannot consume so much capacity that others suffer.

Logical vs Physical Isolation

Logical Isolation

With logical isolation, tenants share the same broker processes and machines, and the software keeps them apart. Each tenant has its own identities and its own topic space, and per-tenant quotas cap resource usage. This is how most shared cloud services work, and when implemented carefully it is a strong boundary for confidentiality and integrity.

Its limit is that physical resources are still pooled. Quotas bound the impact of a noisy neighbor, but a tenant on a shared cluster cannot get capacity guarantees that are independent of everyone else.

Physical Isolation

With physical isolation, a tenant gets its own cluster: separate processes, separate machines, and often separate network endpoints. Nothing another customer does can touch its CPU, memory or connections. It costs more because capacity is reserved rather than pooled, and it takes longer to provision.

A further step is to place that dedicated cluster inside the customer's own cloud account, which adds ownership of the infrastructure itself. That is the bring-your-own-cloud model described in BYOC MQTT broker.

Noisy-Neighbor Protection in Practice

Noisy neighbors are rarely malicious. The usual causes are mundane:

• Firmware that reconnects immediately on failure, creating a connect storm.
• A test script publishing in a tight loop without a delay.
• Oversized payloads, such as images, sent where small JSON was expected.
• Thousands of subscriptions created by a client that never unsubscribes.

Effective protection works at the level of the client and the tenant: caps on connections, message rate, payload size and subscriptions; blocking of addresses after repeated failed logins; and clear feedback to the client. In MQTT 5, reason code 0x97 (Quota exceeded) tells the client precisely why a publish or connection was refused. Read more about how MQTT broker connection quotas affect client design.

Identity Is the Foundation

Isolation fails fastest at the identity layer. Follow these rules:

• Never share credentials across tenants. Every customer gets its own credentials, and ideally every device does too.
• Bind client IDs to credentials. In MQTT, a second connection with the same client ID kicks the first one off. If client IDs are not tied to identities, one tenant could disrupt another by reusing its IDs.
• Use TLS everywhere. Credentials sent over plain TCP on a public network can be captured. Port 8883 or 8084 should be the default for production.
• Rotate secrets. Plan rotation from day one, including how devices receive new credentials.

The MQTT security best practices guide covers these controls in more depth.

Testing Your Isolation

Do not assume isolation works; verify it. A minimal test plan:

1. Connect a client with tenant A's credentials and subscribe to #. Publish from tenant B. Tenant A must receive nothing.
2. Try to connect with tenant B's client ID using tenant A's credentials. The broker must reject it.
3. Publish retained messages as tenant B, then subscribe as tenant A to the same topic name. No retained message may arrive.
4. From tenant A, exceed the connection or rate limit. Confirm tenant B's latency and connections are unaffected.
5. Fail login for tenant A repeatedly from one address. Confirm the block applies to that address, not to tenant B.

Here is a small Python script, using paho-mqtt 2.x, for test 1. Run it with tenant A's details while another client publishes with tenant B's.

import ssl
import time
import paho.mqtt.client as mqtt

received = []

def on_connect(client, userdata, flags, reason_code, properties):
    print("Tenant A connected:", reason_code)
    client.subscribe("#", qos=0)

def on_message(client, userdata, msg):
    received.append(msg.topic)
    print("Unexpected message:", msg.topic)

client = mqtt.Client(mqtt.CallbackAPIVersion.VERSION2, client_id="YOUR_CLIENT_ID",
                     protocol=mqtt.MQTTv5)
client.username_pw_set("YOUR_USERNAME", "YOUR_PASSWORD")
client.tls_set(cert_reqs=ssl.CERT_REQUIRED)
client.on_connect = on_connect
client.on_message = on_message
client.connect("YOUR_BROKER_HOST", 8883, keepalive=30)
client.loop_start()
time.sleep(60)   # publish from tenant B during this window
client.loop_stop()
print("Isolation OK" if not received else f"Leak: {len(received)} messages")

On your own broker you will of course see your own tenant's traffic, so run this test with a tenant that has no publishers of its own.

How ConnectMQ Isolates Tenants

ConnectMQ applies isolation at different strengths depending on the plan:

• Serverless (Free and Paid). Brokers share a cluster with multi-tenant isolation. Each broker has generated credentials, client IDs bound to those credentials, and per-plan quotas, for example up to 25 connections on the free plan and up to 1,000 on the paid plan. Flood protection and IP blocking after repeated failed logins guard the shared cluster.
• Dedicated. Your broker runs on an isolated cluster, so no other customer shares its capacity.
• BYOC. The broker runs in your own cloud account and ConnectMQ manages it.
• Self Managed Enterprise. For organizations that operate the platform themselves.

The public test broker at broker.connectmq.com is deliberately the opposite of isolated: its demo area is readable by everyone and is meant only for experiments. Use it to learn, never for customer data. The free public MQTT broker page lists its limits.

Choosing the Right Level

Start from what your customers and contracts require, not from what is technically possible:

• No customer data, just learning: the public broker.
• Your own product, one owner of all data: a private Serverless broker.
• Many customers with ordinary requirements: one isolated broker per customer, or a shared broker with strictly enforced separation in your own backend.
• Customers with capacity guarantees or regulatory needs: Dedicated or BYOC.

For how SaaS products combine these options, see MQTT for IoT SaaS.

Get Started with ConnectMQ

Create an isolated broker in minutes on the free Serverless plan at app.connectmq.com, no credit card required. When a customer needs stronger guarantees, move them to a Dedicated cluster or BYOC with the same client code. The managed MQTT broker overview and the cloud MQTT broker guide explain the plans in more detail.

Frequently Asked Questions

What is the difference between logical and physical MQTT isolation?

Logical isolation keeps tenants apart in software on shared machines; physical isolation gives a tenant its own cluster. Physical isolation also removes noisy-neighbor effects entirely.

Can another customer on a shared broker read my messages?

Not if the provider isolates tenants correctly. Each tenant should have its own credentials and topic space, which you can verify with a wildcard subscription test.

What happens when a tenant exceeds its quota?

The broker refuses the extra connection or message. MQTT 5 clients receive a reason code such as 0x97 so they can back off and log the cause.

Is the public test broker isolated?

No. The public area of broker.connectmq.com is readable by everyone and is intended for testing only.