An MQTT broker RFP checklist keeps a vendor evaluation focused on what will matter in production instead of on whoever has the longest feature page. This article gives you a ready-to-use list of questions grouped by area, explains why each one matters and what a strong answer looks like, and shows how ConnectMQ answers them as a worked example, including the capabilities it does not offer.
How to Use This MQTT Broker RFP Checklist
Copy the questions into your RFP or evaluation spreadsheet and ask every vendor to answer in writing. The "Example answer" column shows how ConnectMQ responds, so you can see what a specific, verifiable answer looks like. Three habits make the answers comparable:
- Ask for specifics, not adjectives. "Highly scalable" is not an answer; "up to N connections per plan, with quota errors returned as MQTT 5 reason codes" is.
- Ask what is not supported. Honest vendors will tell you. Silence or vague wording on a question usually means no.
- Verify the important claims hands-on. Most managed brokers offer a free tier or trial. Connect a real device, break things and see what the errors look like.
Before writing requirements, it helps to know how to choose an IoT MQTT broker at a high level and which deployment model you want. The cloud MQTT broker guide explains serverless, dedicated and bring-your-own-cloud options.
1. Protocol Support
| Question | Why it matters | Example answer |
|---|---|---|
| Which MQTT versions are supported? | MQTT 5 adds reason codes, expiry and shared subscriptions; older devices may only speak 3.1.1 | MQTT 3.1.1 and 5.0 |
| Which transports and ports? | Browsers need WebSockets; strict networks may only allow 443-style TLS traffic | TCP 1883, TLS 8883, WebSocket 8083, Secure WebSocket 8084 (path /mqtt) |
| Which QoS levels per plan? | Some workloads need QoS 2 exactly-once delivery | QoS up to 1 on Serverless Free; QoS 2 on Serverless Paid and above |
| Maximum message size? | Firmware chunks or images can exceed small limits | 256 KB on Serverless Free, 1 MB on Serverless Paid |
| Which MQTT 5 features? | Shared subscriptions enable load-balanced consumers | Shared subscriptions, retained messages, session expiry, topic alias, message expiry, response topic, reason codes |
| How are quota violations signalled? | Clients need to distinguish quota errors from outages | MQTT 5 reason codes, for example 0x97 quota exceeded |
2. Security and Access Control
| Question | Why it matters | Example answer |
|---|---|---|
| Is TLS available on every transport, with a publicly trusted certificate? | Self-signed certificates complicate every device | TLS and secure WebSocket with a Let's Encrypt certificate |
| How are credentials issued and rotated? | Manual credential handling does not scale | Username, password and client ID generated in the portal |
| Are client IDs bound to credentials? | Prevents one device impersonating another's session | Yes, client IDs are bound to issued credentials |
| Is there brute-force protection? | Exposed brokers are scanned constantly | IP blocking after repeated failed logins, plus flood protection |
| Are per-topic ACLs available? | Needed when untrusted parties share one broker | Not offered; isolate by separate brokers or credentials and design topic ownership in the application |
| Which compliance certifications are held? | Regulated industries may require them | No certifications are claimed; assess against your own requirements |
Do not treat a "no" as automatically disqualifying. Per-topic ACLs matter a great deal for a multi-party platform and very little for a single team's fleet. Our MQTT security best practices help you decide which controls you truly need.
3. Isolation and Tenancy
| Question | Why it matters | Example answer |
|---|---|---|
| Is my traffic isolated from other customers? | Noisy or malicious neighbours on shared clusters | Multi-tenant isolation with per-plan quotas on Serverless |
| Is a dedicated or single-tenant option available? | Predictable performance and stricter isolation | Dedicated plan with an isolated cluster |
| Can the broker run in my own cloud account? | Data residency and existing cloud commitments | BYOC: runs in your cloud account, managed by ConnectMQ |
| Can I run it fully on my own infrastructure? | Air-gapped or on-premises sites | Self Managed Enterprise |
Ask every vendor the same four questions. Answers differ widely across the market, and the right one depends on your regulatory and network constraints rather than on any single best option. Shared clusters are cost-efficient; dedicated ones trade cost for predictability.
4. Reliability and Operations
| Question | Why it matters | Example answer |
|---|---|---|
| Is there a contractual SLA, and what does it cover? | Defines your recourse during outages | No SLA figures are published; discuss requirements directly |
| Does the broker cluster or replicate? | Determines behaviour when a node fails | Clustering and replication are not offered as features |
| Are sessions and retained messages persisted across restarts? | Affects what clients must re-establish | Not guaranteed; clients should re-subscribe and republish state on reconnect |
| How do I see whether a client is connected? | Basic troubleshooting | $SYS/broker/connection/{clientId}/state and the portal |
| How are planned upgrades communicated? | Avoids surprise downtime | Ask every vendor for their notice process |
Reliability answers deserve the most scrutiny. Regardless of vendor, design clients that tolerate a broker restart; our guide to surviving an MQTT broker outage shows how, and MQTT broker SLA explains how to read SLA terms.
5. Tooling and Observability
| Question | Why it matters | Example answer |
|---|---|---|
| Is there a web console? | Fast debugging without installing tools | Portal with dashboard and in-browser MQTT client |
| Can I browse live topics? | Finds naming and payload bugs | Live topic explorer |
| Are there built-in alerts? | Early warning without extra infrastructure | Threshold alert rules and an alerts log |
| Desktop and IDE tooling? | Developer productivity | ConnectMQ VS Code extension and ConnectMQ Desktop MQTT explorer |
| Which UI languages? | Usability for local operators | English and Turkish |
| Is there a free tier for evaluation? | Lets you test before you buy | Serverless Free plan, no credit card |
6. Industrial and Data Integration
| Question | Why it matters | Example answer |
|---|---|---|
| Is Sparkplug B understood? | Protobuf payloads are opaque in generic tools | Decodes Sparkplug B (Protobuf and JSON) |
| Is there Unified Namespace support? | ISA-95 structure is common in manufacturing | Detects ISA-95 and UNS topics; devices view by ISA-95 level |
| Can Sparkplug data be republished as readable topics? | Lets non-Sparkplug consumers use the data | Republishes into ISA-95 topics, e.g. spBv1.0/factory1/DDATA/line1/cnc1 to connectmq/factory1/production/line1/cnc1/telemetry |
| Is there a rule engine or webhooks? | In-broker routing and transformation | Not offered |
| Are there native bridges to Kafka, databases or cloud services? | Reduces integration code | Not offered; use Node-RED, Telegraf or a small subscriber service that connects as an MQTT client |
The integration rows are where vendors differ most. A broker with a built-in rule engine saves code but couples your data pipeline to that vendor. A plain broker plus external tools keeps the pipeline portable. Neither is universally better; decide which you prefer before scoring. If your plant uses Sparkplug B, test decoding with your real payloads during the proof of concept.
7. Commercial and Support
Ask every vendor:
- How is the service priced: by connections, messages, traffic, session time or dedicated capacity? (See our explainer on MQTT broker pricing.)
- What happens when a quota is exceeded: throttling, rejection or overage billing?
- Can I move between plans without changing endpoints or client code?
- Which support channels and response times apply to each tier?
- How do I export my configuration and leave? Standard MQTT clients are the best protection against lock-in.
Scoring the Responses
Weight each area by its importance to your project, score answers from 0 to 3, and multiply. A simple sheet keeps the decision traceable:
Area Weight Vendor A Vendor B Vendor C
Protocol support 3 . . .
Security and access 3 . . .
Isolation and tenancy 2 . . .
Reliability and ops 3 . . .
Tooling 1 . . .
Industrial integration 2 . . .
Commercial and support 2 . . .
Weighted total
Finish with a hands-on proof of concept for the top two vendors, using your real devices, payloads and topic structure.
Evaluate ConnectMQ Hands-On
The fastest way to verify the ConnectMQ column is to try it. Create a free broker at app.connectmq.com on the Serverless plan, no credit card required, and test protocol support, error codes and tooling with your own clients. You can also point a device at the public MQTT test broker first. Learn more about ConnectMQ as a hosted MQTT broker.
Frequently Asked Questions
What is the most important section of an MQTT broker RFP?
Usually reliability and security, because they are hardest to fix after launch. Protocol support is often a quick pass or fail, while tooling and integration affect day-to-day productivity.
Should I require a rule engine in my MQTT broker?
Only if you want routing and transformation inside the broker. Many teams prefer a plain broker with external tools such as Node-RED or a subscriber service, which keeps the data pipeline portable between vendors.
How long should a broker proof of concept take?
A focused proof of concept with real devices typically takes days rather than weeks. Test connection limits, reconnect behaviour, error codes and the tools your team will use daily.
Why does the checklist include things ConnectMQ does not support?
Because an honest RFP must cover every requirement that matters to you. Listing the gaps lets you judge whether they matter for your project and how you would fill them with external tools.
