MQTT is the protocol behind most IoT device telemetry. It is lightweight, easy to implement, and deployed across industrial automation, smart energy, building management, and consumer IoT environments at a scale that few other protocols match. That ubiquity is also what makes MQTT security testing important.
A protocol present in tens of millions of devices across critical infrastructure and consumer environments represents a very large attack surface. Vulnerabilities in MQTT broker and client implementations have been found and disclosed consistently over the past several years, and the finding rate shows no sign of declining. Most of those vulnerabilities were found in implementations that had been tested for conformance and interoperability, and not tested for security.
This guide explains the MQTT attack surface, the vulnerability classes that security testing finds, and what a thorough MQTT security assessment involves.
In This Guide
MQTT in Industrial and IoT Environments
MQTT, Message Queuing Telemetry Transport, was designed for constrained devices communicating over unreliable networks with minimal bandwidth. Its publish-subscribe model, where devices publish data to a broker and other systems subscribe to receive it, made it a natural fit for sensor telemetry, device monitoring, and command delivery in IoT and industrial environments.
The protocol is implemented in smart electricity meters, industrial sensors, building automation controllers, vehicle tracking devices, SCADA data concentrators, and a wide range of connected devices that form the operational layer of modern infrastructure. MQTT version 5, published in 2019, added features including enhanced error reporting, message expiry, and user properties that expanded the protocol’s applicability in enterprise and industrial contexts.
The security context for MQTT has changed significantly as deployment has scaled. Early IoT deployments frequently used MQTT without TLS, without authentication, and with default or empty credentials on broker configurations. That practice has improved in recent years, but it has left a large installed base of poorly secured deployments, and even well-configured deployments can contain implementation vulnerabilities that neither authentication nor encryption address.
The MQTT Attack Surface
The MQTT attack surface differs between broker implementations and client implementations. Both are relevant for security testing, and in many product categories both are present in the same system.
The broker is the central component of an MQTT deployment. It accepts connections from publishing clients, receives published messages, and delivers them to subscribing clients. The broker’s attack surface includes the connection handling layer, which processes CONNECT packets from clients, the packet parsing layer, which processes all incoming MQTT control packets, the topic handling layer, which manages subscriptions and routes messages, and the authentication and access control layer where implemented.
The CONNECT packet is the first point of contact between a client and a broker. It carries the client identifier, the optional username and password, the will message configuration, and the protocol version. Malformed CONNECT packets, packets with inconsistent field combinations, and packets that exploit edge cases in the connection handling logic are a consistent source of findings in broker implementations.
The PUBLISH packet carries the actual message content. It includes the topic name, the quality of service level, the payload, and in MQTT version 5 a set of properties. Variable-length encoding is used for packet length fields and string lengths throughout the protocol. Implementations that do not correctly handle variable-length encoding at boundary conditions are vulnerable to parsing failures triggered by malformed length values.
Client implementations have a distinct attack surface centred on how they handle incoming PUBLISH packets from the broker, SUBACK responses to subscription requests, and CONNACK responses to connection attempts. Clients that process broker responses without adequate validation of the response content are vulnerable to attacks that exploit a compromised or malicious broker.
Vulnerability Classes Found in MQTT Implementations
The vulnerability classes that MQTT security testing finds reflect the complexity of the protocol’s variable-length encoding and the breadth of the attack surface across both broker and client roles.
Variable-length encoding failures are among the most common findings in MQTT implementations. The protocol uses a variable-length encoding scheme for packet lengths where each byte contributes seven bits to the length value with the eighth bit indicating whether another byte follows. Implementations that do not correctly handle all valid and invalid combinations of this encoding are vulnerable to integer overflow, buffer overflow, or processing loop conditions triggered by specifically crafted length values.
CONNECT packet handling failures occur when the broker does not correctly validate all fields in an incoming CONNECT packet before processing it. A client identifier that exceeds the maximum length, a will topic that contains invalid characters, a username field with a zero length but a non-zero username flag, and protocol version values not supported by the broker are all inputs that security testing applies to the CONNECT handling code.
Topic string handling failures occur in both broker and client implementations. MQTT topic strings support wildcards and have defined rules about valid characters and structures. Implementations that do not correctly validate topic strings before processing subscriptions or routing messages can be vulnerable to buffer overflows from oversized topics, parsing failures from topics with invalid wildcard placement, and in some cases path traversal conditions in implementations that map topic strings to file system paths.
Authentication bypass conditions occur in broker implementations that do not correctly enforce their authentication requirements under all connection conditions. Malformed CONNECT packets, CONNECT packets that exploit edge cases in the authentication flow, and connection sequences that manipulate the timing of authentication checks are testing surfaces that have produced findings in broker implementations.
Denial of service conditions arise from inputs that cause the broker or client to consume excessive resources or become unavailable. For industrial and smart energy applications where MQTT availability directly affects operational visibility, these findings carry significant operational weight.
How MQTT Security Testing Works
MQTT security testing uses protocol-aware fuzz testing to generate test cases that exercise the implementation logic of broker and client targets. The protocol model encodes the MQTT packet structure, the variable-length encoding rules, the valid field types and ranges for each packet type, and the connection state machine.
For broker testing, test case generation covers CONNECT packet variations including field length boundary conditions, invalid field combinations, and unsupported protocol version values. PUBLISH packet testing covers payload length boundary conditions, topic string variations including wildcard edge cases and oversized topics, and QoS level field variations. SUBSCRIBE and UNSUBSCRIBE packet testing covers topic filter variations and packet identifier handling. PINGREQ and DISCONNECT packet testing covers the connection management edge cases.
For client testing, the test environment includes a controlled broker that sends crafted CONNACK, PUBLISH, SUBACK, and UNSUBACK packets to the client under test. Test cases cover malformed response packets, response packets with inconsistent field values, and response sequences that exploit edge cases in the client’s state machine.
The monitoring layer watches for crashes, connection failures, unexpected response content, and availability degradation. For MQTT implementations in embedded devices with limited resources, resource consumption monitoring tracks memory and processing usage under sustained malformed input conditions.
MQTT Security Testing and IEC 62443
For product vendors whose devices implement MQTT, IEC 62443 places specific testing obligations that MQTT security testing directly addresses.
IEC 62443-4-2 CR 3.5 requires input validation across all external interfaces. For a device with an MQTT client or broker interface, this means correctly validating all incoming MQTT packets before processing them. Demonstrating CR 3.5 compliance requires test evidence showing that the MQTT implementation handles malformed packets safely across the full range of inputs the interface can receive.
IEC 62443-4-2 CR 7.1 requires denial-of-service protection. For devices where MQTT availability is operationally critical, demonstrating this requires testing under the input conditions that can cause availability failures.
IEC 62443-4-1 Practice 5 requires vulnerability testing as part of the secure development lifecycle. For devices with MQTT interfaces, this means systematic vulnerability testing with documented scope, methodology, findings, and remediation.
Note: a draft amendment to IEC 62443-4-1 is in development, targeted for late 2026. CyTAL is tracking it.
- IEC 62443 compliance hub → https://cytal.co.uk/iec-62443/
How ProtoCrawler Tests MQTT Implementations
ProtoCrawler supports MQTT security testing through a formal MQTT protocol model covering both broker and client testing scenarios. The model encodes the MQTT packet structure, variable-length encoding rules, valid field ranges for each packet type, and the connection state machine for both MQTT version 3.1.1 and version 5.
Test case generation covers all control packet types relevant to the target role. For broker testing this includes CONNECT, PUBLISH, SUBSCRIBE, UNSUBSCRIBE, PINGREQ, and DISCONNECT. For client testing it includes the server-sent packets: CONNACK, PUBLISH, SUBACK, UNSUBACK, PINGRESP, and in version 5 the AUTH packet.
The output maps to IEC 62443-4-2 compliance evidence requirements with findings traced to CR 3.5 and CR 7.1 where applicable. The report structure provides the scope, methodology, findings, and coverage documentation that certification assessments require.
For the full list of protocols supported, see the protocol models page.
- MQTT → https://cytal.co.uk/protocols/mqtt-client/
- protocol models page → https://cytal.co.uk/protocols/
Common Questions
Does using TLS with MQTT eliminate the need for protocol security testing?
No. TLS protects the confidentiality and integrity of MQTT traffic in transit. It does not protect against implementation vulnerabilities in the MQTT parsing and handling code. A broker that correctly implements TLS can still contain a buffer overflow in its CONNECT packet handler or a denial-of-service condition in its topic routing logic. Transport security and protocol implementation robustness address different security properties and both are needed.
Should MQTT security testing cover both the broker and the client?
Yes where both are present in the product or system under test. In many IoT and industrial products, the device acts as an MQTT client that connects to an external broker. In those cases, client-side testing covers how the device handles malformed responses from a broker, including responses from a compromised or malicious broker. In deployments where the product includes a broker component, broker testing is the higher priority because the broker is the more exposed attack surface.
How does MQTT security testing differ between version 3.1.1 and version 5?
The core packet structure and vulnerability classes are consistent across both versions. MQTT version 5 introduces additional packet types, property fields, and connection options that expand the attack surface relative to version 3.1.1. Products that support both versions need to be tested against both, as version-specific code paths may have distinct vulnerabilities. The property handling code introduced in version 5 is a particularly relevant additional testing surface.
Which MQTT implementations are most commonly found to have security vulnerabilities?
Vulnerabilities have been found across broker and client implementations from multiple vendors, including widely deployed open-source brokers and embedded client libraries used in IoT devices. The vulnerability classes are consistent regardless of implementation: variable-length encoding failures, CONNECT packet handling issues, and topic string vulnerabilities appear across the implementation landscape. No category of MQTT implementation is inherently exempt from these findings.
Ready to test your MQTT implementation against the inputs that functional testing will never send? Book a demo to see how ProtoCrawler generates protocol-aware MQTT security test cases for broker and client implementations.