MQTT Security in IIoT: Authentication, TLS, and Broker Hardening

MQTT in Industrial Environments

Message Queuing Telemetry Transport (MQTT) is the dominant publish/subscribe messaging protocol for Industrial Internet of Things applications. Designed in the late 1990s for SCADA telemetry over satellite links where bandwidth and reliability were severely constrained, MQTT became the de facto standard for lightweight IoT messaging and is now embedded in:

Energy monitoring systems (smart meters, substation telemetry)
Building automation and HVAC control
Manufacturing execution systems and production line telemetry
Water utility sensor networks
Smart grid demand response platforms
Industrial edge gateways aggregating field device data

The protocol’s simplicity is its strength in constrained environments. MQTT brokers (the central message router) and clients can run on microcontrollers and low-power sensors. This same simplicity creates a significant security problem: the protocol’s original design included no authentication and no encryption requirements, and most broker implementations still ship with insecure defaults.

Protocol Architecture and Trust Model

MQTT operates on a broker/client model:

Publishers connect to the broker and publish messages to named channels called topics
Subscribers connect to the broker and receive messages from topics they’ve subscribed to
The broker (Mosquitto, EMQX, HiveMQ, VerneMQ, AWS IoT Core, Azure IoT Hub) routes messages between clients

Topics are hierarchical strings: factory/line1/conveyor3/temperature or building/floor2/hvac/setpoint. Wildcard subscriptions (factory/line1/#) allow a subscriber to receive all messages below a topic prefix.

The critical trust model implication: any client authenticated to the broker can (by default) publish to or subscribe to any topic. There is no per-topic ACL enforcement unless explicitly configured. In practice, most IIoT broker deployments have:

No authentication, or shared credentials across all clients
No TLS encryption
No per-topic access controls
Brokers exposed on the internet or OT network without firewall restrictions

Attack Surface

Unauthenticated Access

MQTT’s CONNECT packet includes optional username and password fields. Brokers configured without authentication accept CONNECT packets from any client. Tools like mqtt-client or mosquitto_pub/sub provide a trivial path to explore and interact with an exposed broker:

# Connect to a broker with no authentication
mosquitto_sub -h <broker-ip> -p 1883 -t '#' -v

# Subscribe to ALL topics with wildcard
# In an unauthenticated deployment, this receives everything:
# sensor readings, control commands, device states, operator messages

Shodan and Censys regularly index thousands of MQTT brokers on TCP port 1883 with no authentication. Many are industrial in nature — energy telemetry, factory data, building control systems.

Cleartext Protocol (Port 1883)

Standard MQTT runs on port 1883 with no encryption. All messages — including credentials in CONNECT packets, control commands, and sensor data — are transmitted in plaintext. An attacker with network access (via a compromised OT workstation, a bridged IT/OT network, or a rogue device on an industrial LAN) can passively capture all broker traffic.

MQTT over TLS (MQTTS) runs on port 8883. The same authentication problems apply unless certificate-based client authentication is also configured.

Command Injection via Topic Publish

In typical IIoT deployments, subscribers include not just monitoring applications but control systems that take action based on received messages. An attacker who can publish to a control topic can issue commands:

# If HVAC setpoint control is via MQTT:
mosquitto_pub -h <broker-ip> -p 1883 \
  -t 'building/floor3/hvac/setpoint' \
  -m '{"temperature": 5, "mode": "cooling"}'

# If energy control is via MQTT:
mosquitto_pub -h <broker-ip> -p 1883 \
  -t 'substation/breaker1/command' \
  -m 'open'

The impact depends entirely on what the subscribing application does with the message. In building automation systems, this can manipulate HVAC, lighting, and access control. In industrial settings, it can modify process setpoints or issue control commands to equipment.

Retained Messages and Persistent State

MQTT supports retained messages — a broker stores the last message published to each topic and delivers it immediately to new subscribers. In industrial environments, this is used so that new monitoring clients get the current state immediately on connection.

The security implication: an attacker who publishes a malicious retained message to a control or state topic has inserted persistent data that will be delivered to every future subscriber to that topic, potentially indefinitely.

Broker Vulnerabilities

The broker itself is a network-accessible service handling potentially complex message routing and protocol logic. Historical broker vulnerabilities include:

Mosquitto CVE-2021-28166: Broker crash via malformed SUBSCRIBE packet (DoS)
EMQX CVE-2023-43808: Authentication bypass in certain configurations
VerneMQ: Multiple CVEs related to plugin authentication bypasses

Brokers in industrial environments are often running old versions — updates are infrequent because the broker is embedded in an OT system that follows OT change management processes (lengthy, risk-averse, sometimes years between updates).

Hardening Measures

1. Enable TLS — Mandatory

# Mosquitto configuration (mosquitto.conf)
listener 8883
cafile /etc/mosquitto/ca.crt
certfile /etc/mosquitto/server.crt
keyfile /etc/mosquitto/server.key
tls_version tlsv1.2  # minimum; tlsv1.3 preferred
require_certificate false  # set to true for mTLS client cert requirement

# Disable plaintext listener
# Remove or comment out: listener 1883

Certificate management in IIoT can be challenging when devices have no clock sync or limited storage. For constrained devices, lightweight certificate solutions (Smallstep, AWS ACM Private CA, Azure IoT Hub device certificates) provide managed issuance without requiring a full enterprise PKI.

2. Mandatory Authentication

# Mosquitto: enable password file authentication
allow_anonymous false
password_file /etc/mosquitto/passwords

# Create credentials for each device/service
mosquitto_passwd -c /etc/mosquitto/passwords sensor-device-001
mosquitto_passwd /etc/mosquitto/passwords hvac-controller-01
mosquitto_passwd /etc/mosquitto/passwords monitoring-dashboard

Each device should have unique credentials. Shared credentials across device classes or all devices mean a single compromised device grants broker access across the entire deployment.

For mTLS (mutual TLS) — where each device presents a client certificate rather than username/password:

require_certificate true
use_identity_as_username true  # uses CN from certificate as MQTT username

mTLS is stronger than password authentication because private keys don’t traverse the network during authentication.

3. Per-Topic ACL Enforcement

# Mosquitto ACL file example (/etc/mosquitto/acl)

# Sensor device: can only publish to its own sensor topics
user sensor-device-001
topic write factory/line1/sensor001/#

# HVAC controller: can subscribe to setpoints, publish to status
user hvac-controller-01
topic read building/floor3/hvac/setpoint
topic write building/floor3/hvac/status

# Monitoring dashboard: read-only across all topics
user monitoring-dashboard
topic read #

# Default: deny everything not explicitly permitted
# (Mosquitto denies by default when ACL file is configured)

ACL design should follow least-privilege: each client can only read and write the topics its function requires. No client should have write access to topics that drive control actions in other systems unless that’s its explicit role.

4. Network Segmentation

MQTT brokers should not be directly internet-accessible. Placement:

Internal OT network or DMZ, accessible only from known field devices and control systems
Firewall rules limiting inbound connections to specific device IP ranges
No direct exposure on public-facing networks; cloud integration should flow through MQTT bridging (an MQTT-to-cloud gateway that relays specific topics, not through public broker exposure)

# Firewall: restrict MQTT to specific source subnets (Linux iptables example)
iptables -A INPUT -p tcp --dport 8883 -s 10.10.100.0/24 -j ACCEPT
iptables -A INPUT -p tcp --dport 8883 -j DROP

5. Broker Monitoring and Anomaly Detection

MQTT brokers expose built-in system topics that provide operational visibility:

$SYS/broker/clients/connected     — current client count
$SYS/broker/messages/received     — message volume
$SYS/broker/subscriptions/count   — active subscriptions

Monitoring anomalies in these metrics — a sudden increase in connected clients, an unusual volume of publications to a specific topic, subscriptions to wildcard topics from unexpected clients — provides early warning of reconnaissance or exploitation activity.

For industrial deployments, Claroty, Nozomi Networks, and Dragos all include MQTT traffic analysis in their OT monitoring platforms, providing behavioural baselining and alerting on anomalous MQTT activity alongside other OT protocols.

Prioritisation for Existing Deployments

Remediation should sequence as follows based on risk reduction impact:

Disable anonymous access immediately — this is a configuration change with no device-side impact and eliminates the largest attack surface
Firewall MQTT off the internet and restrict to known source IPs — network-layer control that doesn’t require touching devices
Enable TLS — requires device-side certificate deployment, which may require a device update cycle
Deploy per-topic ACLs — requires understanding what topics each device legitimately needs
Upgrade broker to a current, supported version — follow OT change management but treat this as a high-priority update

Deployments where MQTT carries control commands (not just telemetry) should treat items 1 and 2 as emergency changes rather than scheduled maintenance items.