MQTT for IoT SaaS: Building a Multi-Customer Platform on a Managed Broker

Using MQTT for IoT SaaS lets you deliver real-time device data to many customers from one product, but only if you separate those customers correctly from the first device onward. This guide shows how to choose an isolation model, design credentials and topic prefixes, onboard devices, and structure your backend on a managed broker so you can launch faster and scale without re-architecting.

The Shape of an IoT SaaS Platform

Most IoT SaaS products follow the same pattern. Devices in the field publish telemetry and status. A backend subscribes, stores data, evaluates logic and serves an API. A web or mobile app shows each customer only their own devices and sends commands back down. MQTT sits in the middle because it handles intermittent connectivity, small payloads and two-way messaging well. If the protocol is new to you, start with what an MQTT broker does.

The broker is shared infrastructure for your business, but the data on it belongs to your customers. Three design decisions follow from that:

1. How strongly are customers separated at the broker?
2. How are devices identified and authenticated?
3. How are topics structured so your backend can route data per customer?

Decision 1: Choose a Customer Isolation Model

Model A: One Broker per Customer

Each customer gets its own broker, with its own endpoint credentials and its own topic space. Devices of customer A physically cannot subscribe to customer B's topics, because they are not on the same broker namespace. Your backend connects to every customer broker as a client.

This gives the strongest separation and makes per-customer limits, offboarding and data deletion simple: delete the broker. The cost is more brokers to provision and a backend that manages many connections.

Model B: One Shared Broker with Topic Prefixes

All customers' devices connect to one broker, and each customer's topics start with a prefix such as acme/ or a customer ID. Your backend subscribes to +/devices/+/telemetry and derives the customer from the first topic level.

This is simple and efficient, but a topic prefix by itself is an organizing convention, not an access-control boundary. If any device on the broker can subscribe to #, it can see every customer's data. Use this model only when you control all device firmware and nothing customer-facing connects to the broker directly, or when your broker enforces per-tenant topic restrictions.

Model C: Tiered

Smaller customers share a broker, while large or regulated customers get their own broker, a dedicated cluster or a deployment in their own cloud account. This mirrors how many SaaS businesses price their plans.

The underlying concepts are covered in MQTT tenant isolation and multi-tenant MQTT broker architecture.

Decision 2: Credential Design

Your credential model determines how safely you can onboard, revoke and rotate devices.

• Per-device client IDs. Every device needs a unique, stable client ID. Derive it from a serial number or a provisioning record, never from a random value generated at boot, or persistent sessions will not resume.
• No credentials in public repositories or app bundles. Mobile and web apps should not hold device-level broker credentials. Have them call your API, and let the backend talk to the broker, or issue short-lived scoped credentials if your broker supports it.
• Revocation path. When a customer churns or a device is stolen, you must be able to cut it off without touching other devices.
• Rotation path. Plan how firmware receives new credentials, for example over an authenticated configuration topic or during an OTA update.

Decision 3: Topic Design for Multi-Customer Routing

A predictable topic tree makes the backend simple and keeps wildcard subscriptions safe. A pattern that works well:

<customer>/<site>/<device-id>/telemetry
<customer>/<site>/<device-id>/status
<customer>/<site>/<device-id>/cmd
<customer>/<site>/<device-id>/cmd/response

Guidelines:

• Put the customer first, so one wildcard per level gives you a full customer view.
• Keep identifiers stable and lowercase, without spaces.
• Use retained messages on status so dashboards see the last known state immediately.
• Use MQTT 5 response topics and correlation data for command-and-response flows instead of inventing your own.
• Avoid personal data in topic names; topics show up in logs and tools.

In Model A, the customer level is implied by the broker, so you can drop it from the topic or keep it for consistency across tiers.

A Minimal Backend Ingest Service

The backend subscribes, validates and stores. This Python example, using paho-mqtt 2.x and MQTT 5, ingests telemetry from a shared broker and extracts the customer from the topic. On ConnectMQ Serverless (Paid) you can scale such ingest workers horizontally with a shared subscription such as $share/ingest/+/+/+/telemetry, which spreads messages across workers.

import json
import ssl
import paho.mqtt.client as mqtt

SUBSCRIPTION = "+/+/+/telemetry"   # use $share/ingest/+/+/+/telemetry on plans with shared subscriptions

def store(customer, site, device, data):
    # Replace with your database write
    print(f"[{customer}] {site}/{device}: {data}")

def on_connect(client, userdata, flags, reason_code, properties):
    print("Ingest connected:", reason_code)
    client.subscribe(SUBSCRIPTION, qos=1)

def on_message(client, userdata, msg):
    parts = msg.topic.split("/")
    if len(parts) != 4:
        return
    customer, site, device, _ = parts
    try:
        data = json.loads(msg.payload)
    except json.JSONDecodeError:
        print("Rejected non-JSON payload on", msg.topic)
        return
    store(customer, site, device, data)

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=60)
client.loop_forever()

Integrations such as databases, notifications or analytics hang off this service, or off tools like Node-RED and Telegraf that connect to the broker as ordinary MQTT clients.

Building on ConnectMQ

ConnectMQ is a fully managed MQTT service that fits each of these models. Every broker you create gets generated credentials and a client ID bound to them, and brokers are isolated from each other on the shared cluster. That makes Model A straightforward: create a broker per customer, store its credentials in your backend, and connect your ingest service to each one.

Plan limits map naturally to SaaS tiers. The free Serverless plan supports up to 25 connections, QoS up to 1 and 256 KB messages, ideal for development and pilot customers. Serverless (Paid) supports up to 1,000 connections, QoS 2, 1 MB messages and shared subscriptions. Dedicated gives a customer an isolated cluster, and BYOC runs the broker in a cloud account you or your customer control, managed by ConnectMQ.

The portal helps support teams too: the live topic explorer and in-browser MQTT client let you see what a customer's devices are actually sending, the devices view groups equipment by ISA-95 levels for industrial customers, and threshold alert rules with an alerts log flag out-of-range values.

Launch Checklist for Your IoT SaaS

1. Isolation model chosen and documented per pricing tier.
2. Unique client ID and credentials per device, with a revocation procedure.
3. Topic tree documented and validated in the backend.
4. TLS on port 8883 (devices) and 8084 (browser clients) only.
5. Reconnect with exponential backoff and jitter in all firmware.
6. Ingest service scaled with shared subscriptions where available.
7. Separate staging broker for firmware and backend testing.
8. Monitoring and alerting for connections and message flow per customer; see the MQTT production checklist.

Get Started with ConnectMQ

Prototype your SaaS on a free Serverless broker at app.connectmq.com, no credit card required, then add a broker per customer as you sign them. You can also test ideas on the public MQTT test broker before creating an account, and read the cloud MQTT broker guide to compare hosting options.

Frequently Asked Questions

Should each SaaS customer get their own MQTT broker?

If customers or their apps connect directly, or if contracts require separation, yes. A broker per customer gives enforced isolation and simple offboarding.

Are topic prefixes enough to separate customers?

They organize data, but they only protect it if the broker enforces which prefixes each client may use. Without enforcement, any client subscribing to # would see everything.

How do I scale the backend that consumes device data?

Run several ingest workers using an MQTT 5 shared subscription so the broker load-balances messages between them.

Can my mobile app connect to the broker directly?

It can over Secure WebSocket on port 8084, but avoid embedding device credentials in the app. Route through your API or use scoped credentials per user.