An enterprise MQTT broker has to satisfy more than developers: security architects, compliance officers, operations teams and procurement all have a say. This guide turns their typical expectations into a concrete requirements checklist, explains which deployment models answer which concerns, and shows how ConnectMQ's Dedicated, BYOC and Self Managed Enterprise options map to them, so you can run a focused evaluation instead of a sprawling one.
Why Enterprise Requirements Are Different
A startup asks "does it work and is it cheap?" An enterprise asks "where does our data go, who can touch it, what happens when it breaks, and how do we prove all of that to an auditor?" The protocol is the same MQTT 3.1.1 or 5.0 that every broker speaks, but the surrounding questions dominate the decision.
Enterprise IoT also tends to be heterogeneous: PLC gateways in plants, building systems, field equipment, mobile apps and cloud analytics, often owned by different teams. The broker becomes shared infrastructure, which raises the bar for isolation, governance and operational maturity. For the protocol basics behind all this, see what an MQTT broker does.
The Requirement Areas
1. Isolation and Tenancy
Can another customer's workload affect yours? Shared multi-tenant tiers isolate logically with credentials, namespaces and quotas, which is adequate for many uses. Enterprises with strict policies usually want physical or account-level isolation: a dedicated cluster, or a broker running inside their own cloud account.
2. Deployment Control and Data Location
Where does the broker run, and who owns the infrastructure? Options range from provider-hosted, through bring-your-own-cloud, to fully self-operated. Data residency rules, network architecture (private connectivity to plants or VPCs) and internal cloud policies typically decide this.
3. Identity, Authentication and Access
Typical questions: are credentials unique per client, can a stolen credential be revoked individually, are client IDs bound to identities, and is brute force blocked? Enterprises also ask about integration with corporate identity for human users of the management console. Be precise in your evaluation about what is available today versus on a roadmap, and treat single sign-on and fine-grained topic authorization as explicit line items to verify rather than assume.
4. Transport Security
TLS on every external connection, modern cipher suites, publicly trusted certificates or a managed private CA, and secure WebSocket for browser clients. Our MQTT security best practices guide covers what to require on the device side too.
5. Operations and Observability
Who is on call, how is the broker monitored, how are upgrades rolled out, and what visibility do you get into connections, traffic and errors? A management portal, connection state topics and alerting matter here.
6. Scalability and Resilience
Expected connection counts, message rates, burst behaviour during reconnection storms, and the recovery story when a node restarts. Ask concrete questions about architecture rather than accepting headline numbers.
7. Support and Commercial Terms
Response times, escalation paths, named contacts, and contractual commitments. Ask for these in writing during procurement; do not rely on marketing pages.
8. Industrial and Data Model Fit
For manufacturing, support for ISA-95 topic hierarchies, the Unified Namespace pattern and Sparkplug B payloads saves significant integration work.
Deployment Models Mapped to Requirements
| Requirement | Serverless (shared) | Dedicated | BYOC | Self Managed Enterprise |
|---|---|---|---|---|
| Infrastructure isolation | Logical | Isolated cluster | Isolated, in your account | Fully yours |
| Who owns infrastructure | Provider | Provider | You | You |
| Who operates the broker | Provider | Provider | Provider | You |
| Fits strict data-location policy | Sometimes | Often | Yes | Yes |
| Operational burden on you | None | None | Low (account, network) | High |
| Typical use | Pilots, small fleets | Production fleets | Regulated or policy-driven orgs | Air-gapped or fully in-house |
ConnectMQ offers all four. Dedicated gives you an isolated cluster operated for you. BYOC deploys the broker inside your cloud account while it is still managed for you, which answers the "our data stays in our account" requirement without making your team broker operators. Self Managed Enterprise is for organizations that must run everything themselves. The dedicated MQTT broker guide covers capacity planning for isolated clusters.
Capabilities You Can Verify
During enterprise evaluations, clarity beats enthusiasm. These are the capabilities you can verify:
- MQTT 3.1.1 and 5.0 on TCP 1883, TLS 8883, WebSocket 8083 and Secure WebSocket 8084 (path
/mqtt), with Let's Encrypt certificates. - Multi-tenant isolation with per-plan quotas, flood protection, IP blocking after repeated failed logins, and client IDs bound to issued credentials.
- MQTT 5 features: shared subscriptions, retained messages, session expiry, topic alias, message expiry, response topic and reason codes such as
0x97(quota exceeded). - Connection state via
$SYS/broker/connection/{clientId}/state. - Portal tools: in-browser client, live topic explorer, dashboard, devices view by ISA-95 levels, threshold alert rules and alerts log, in Turkish and English.
- Industrial features: ISA-95 and Unified Namespace topic detection, Sparkplug B decoding (Protobuf and JSON), and republishing Sparkplug B into ISA-95 topics, for example
spBv1.0/factory1/DDATA/line1/cnc1toconnectmq/factory1/production/line1/cnc1/telemetry. See Sparkplug B and the Unified Namespace.
Equally important is what to plan around. ConnectMQ is a broker, not an integration platform: there is no built-in rule engine, webhook system or database and Kafka bridge. Enterprises integrate by running their own MQTT clients, for example Node-RED, Telegraf or a small service, that subscribe and write to their historian, data lake or stream platform. Many architects prefer this because the integration layer stays under their control. Likewise, ask directly about clustering, replication, per-topic authorization and contractual availability for your specific deployment rather than assuming them.
Integration Pattern: A Subscriber You Own
A typical enterprise pattern is a shared-subscription consumer group that writes to an internal system. Running several instances of this service splits the load automatically (shared subscriptions require a plan that supports them).
import json
import ssl
import paho.mqtt.client as mqtt
GROUP_TOPIC = "$share/historian/connectmq/+/production/+/+/telemetry"
def write_to_historian(topic: str, payload: dict) -> None:
# Replace with your database or stream client.
print(topic, payload)
def on_connect(client, userdata, flags, reason_code, properties):
if reason_code.is_failure:
print("Connect failed:", reason_code)
return
client.subscribe(GROUP_TOPIC, qos=1)
def on_message(client, userdata, msg):
try:
write_to_historian(msg.topic, json.loads(msg.payload))
except (ValueError, UnicodeDecodeError):
print("Skipping non-JSON payload on", 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.reconnect_delay_set(min_delay=1, max_delay=60)
client.connect("broker.connectmq.com", 8883, keepalive=60)
client.loop_forever()
Replace the hostname with your Dedicated or BYOC endpoint in production.
An Enterprise Evaluation Checklist
Use this as the skeleton of your RFP or proof-of-concept plan:
- Document the deployment model your policies require: shared, dedicated, BYOC or self-managed.
- List data-location and network constraints, including private connectivity needs.
- Confirm protocol versions and ports, including WebSocket for browser apps.
- Verify per-client credentials, revocation and brute-force protection.
- Specify topic-level authorization needs and confirm how they will be met.
- Define expected peak connections, message rates and payload sizes.
- Test a reconnection storm in the proof of concept.
- Confirm monitoring visibility: connection state, traffic, alerts.
- Identify integration targets and who builds and runs the subscriber layer.
- Agree support terms, escalation contacts and commitments in writing.
- Validate industrial needs: ISA-95, Unified Namespace, Sparkplug B.
- Plan the migration from pilot to production, including credential rotation.
For the broader context of hosting choices behind this checklist, read the cloud MQTT broker pillar and our guide to the managed MQTT broker model.
Evaluate ConnectMQ for Your Enterprise
The quickest way to start an evaluation is hands-on. Create a free Serverless broker at app.connectmq.com (no credit card) and connect a gateway, a subscriber and the portal tools. Then talk to ConnectMQ about Dedicated, BYOC or Self Managed Enterprise for production, with your requirements checklist in hand.
Frequently Asked Questions
What makes an MQTT broker enterprise-ready?
Isolation that matches your policies, control over where it runs, strong authentication and TLS, operational visibility, and support terms you can rely on. The protocol itself is the same as any standard broker.
What is the difference between Dedicated and BYOC?
Dedicated runs an isolated cluster in the provider's infrastructure. BYOC runs the broker in your own cloud account while the provider still operates it.
Is there a built-in rule engine or database connector?
No. Integrations are built with your own MQTT clients such as Node-RED, Telegraf or custom services that subscribe and write to your systems.
Can ConnectMQ handle Sparkplug B from industrial gateways?
Yes. It decodes Sparkplug B in Protobuf or JSON and can republish it into ISA-95 structured topics for a Unified Namespace.
