MQTT security: why the spec only says 'should,' and what happens when vendors skip it

No. MQTT 5.0, the current OASIS Standard (approved 7 March 2019), devotes its Section 5 to security but frames every control as a recommendation, not a requirement: "MQTT Client and Server implementations SHOULD offer Authentication, Authorization and secure communication options... Applications concerned with critical infrastructure, personally identifiable information, or other personal or sensitive information are strongly advised to use these security capabilities." SHOULD, in the IETF/OASIS sense, means an implementer can skip it and still claim protocol compliance. The CONNECT packet carries native Username and Password fields, but the spec itself does not encrypt or hash them — confidentiality depends entirely on whether the connection also runs over TLS, which is likewise optional. MQTT's earlier 3.1.1 text is explicit that the protocol is not even trust-symmetrical: "The MQTT protocol is not trust symmetrical: it provides no mechanism for the Client to authenticate the Server." MQTT is maintained by the OASIS MQTT Technical Committee and described on the project's own site as "an extremely lightweight publish/subscribe messaging transport" built for a small code footprint — a design goal that, in practice, has repeatedly meant security was left for someone downstream to add.

Documented as a real, recurring problem, though exact current counts vary by source and methodology, so treat any single round number with caution. The most-cited peer-reviewed-adjacent research is Trend Micro's December 2018 study with EURECOM and Politecnico di Milano, "The Fragility of Industrial IoT's Data Backbone," which collected roughly 209.9 million MQTT messages from 78,549 distinct brokers over about four months of internet scanning, many configured with no access control at all. Independent academic exposure counts since then (for example an IS&T Electronic Imaging paper reporting over 100,000 unauthenticated MQTT devices via Shodan) point the same direction, and more recent vendor blog posts citing Shodan queries report broker counts in the hundreds of thousands to over a million on the default port — those later figures are self-reported search-engine counts rather than peer-reviewed research, so this guide cites the 2018 Trend Micro study as its anchor and flags the newer numbers as directionally consistent but unverified. The pattern across all of them is the same: a protocol that makes authentication optional produces a long tail of brokers where the option was never turned on.

A consistent pattern of implementation failures, not a break of any cryptography MQTT provides. CISA's ICSA-26-162-01 (Yarbo robotic mower app and cloud) found hard-coded MQTT broker credentials — "the Yarbo Android and iOS applications contain hard-coded MQTT broker credentials that are identical for all users and all devices" (CVE-2026-10557, CVSS v3.1 9.8) — plus missing per-device authorization letting any client subscribe to another owner's robot telemetry and commands by serial number alone (CVE-2026-7368). ICSA-26-013-03 (YoSmart YoLink smart hub) found the ecosystem's devices "leverage unencrypted MQTT to communicate over the internet" with no broker-side authorization, enabling cross-account device control via predictable identifiers (CVE-2025-59448/59449/59451/59452). ICSA-25-294-05 (CloudEdge cameras) found the app "does not sanitize the MQTT topic input, which could allow an attacker to leverage the MQTT wildcard to receive all the messages that should be delivered to other users" (CVE-2025-11757). ICSA-25-030-02 (New Rock Technologies IP-PBX and gateway products) found a cloud MQTT service that "supports wildcard topic subscription which could allow an attacker to obtain sensitive information from tapping the service communications" (CVE-2025-0681), alongside a separate critical flaw (CVE-2025-0680, CVSS v3.1 9.8) in the same product line. ICSA-24-025-01 (MachineSense FeverWarn thermal-screening devices) found the product line simply "use[s] unauthenticated MQTT messaging to monitor devices and remote viewing of sensor data by users" (CVE-2023-49115). Every one of these is an implementer choice — shared credentials, missing authorization, or unencrypted transport — not a flaw in the MQTT protocol's own design.

Inventory every broker, client and topic namespace your product or deployment uses, and confirm — rather than assume — that TLS is actually enabled on the broker listener, since MQTT's default unencrypted port (1883) and its TLS port (8883) commonly run side by side and a client falling back to the open port is invisible without checking broker logs or a network capture. Never hard-code or share broker credentials across devices or customers; each of the 2024-2026 advisories above traces back to exactly this shortcut. Configure the broker's access-control list (ACL) so each client can only publish and subscribe to the topics it actually needs — wildcard subscriptions (`#` and `+`) should be scoped per client, not granted globally, since three of the five advisories above are a direct consequence of a client (or an attacker posing as one) being able to subscribe to other users' topics. If the deployment is industrial rather than consumer IoT and uses Sparkplug B for SCADA/IIoT interoperability, remember that Sparkplug adds topic-namespace and payload conventions on top of MQTT, not a separate security layer — any MQTT broker that meets the Sparkplug Compliant bar still inherits whatever authentication and TLS configuration (or lack of it) the underlying broker was given.