MQTT Security Considerations — The Little Publish/Subscribe Protocol That Could (Also Betray You)

"MQTT: lightweight, ubiquitous, and quietly judging your security posture." — Probably me, 3 cups of coffee in.

---

You already know the layout: we covered IoT/ICS/SCADA architecture and then dug into embedded device attack surfaces. Now we zoom in on the messaging backbone many devices use to gossip with the cloud and operators: MQTT. If embedded devices are the nervous system and cloud is the brain, MQTT is the synapse — and a misfiring synapse can cause a very messy seizure.

This guide assumes you know: device constraints (CPU, RAM, storage), network segmentation in OT environments, and cloud/shared-responsibility basics from our previous module on container/Kubernetes/serverless hardening. We'll apply those principles to MQTT security because of course nothing in security exists in isolation.

---

What is MQTT (quick refresher)

• MQTT = Message Queuing Telemetry Transport. A tiny, publish/subscribe protocol designed for constrained devices and unreliable networks.
• Key players: broker (server), clients (publishers/subscribers), topics (string paths), QoS levels (0, 1, 2), Last Will and Testament (LWT), and retained messages.

Why it matters for OT: it's low-overhead, simple to implement (good for embedded stacks), and therefore widely used in industrial telemetry, sensor networks, and cloud bridges. That convenience also makes it a juicy target.

---

The Threat Model — where MQTT gets messy

• Unauthenticated brokers: Open brokers leak telemetry and allow command injection.
• Weak auth: Plain username/password over plaintext TCP = eavesdrop + replay = bad times.
• Overprivileged topics: One client can publish to control topics because ACLs are missing.
• Misconfigured retained messages & LWT: An attacker can inject persistent 'state' that tricks systems into thinking a device is online/offline or in a dangerous state.
• Bridge/Multitenancy flaws: Brokers bridging environments can leak segmentation boundaries.
• QoS/Session abuse: Persistent sessions and QoS 1/2 can be used to flood brokers or replay messages.

Think of MQTT as a tiny, fast Talking Stick for devices — if you hand it to every app in the room without rules, chaos ensues.

---

Core Security Controls (and the OT-flavored why)

1. Use TLS everywhere

   • Why: Prevents passive eavesdropping and man-in-the-middle (MITM).
   • OT nuance: Legacy PLCs may not support TLS — if they can’t, put a gateway that does TLS on their behalf.

2. Strong authentication and identity

   • Client certificates > token > username/password.
   • Map identities to device identities (not generic accounts). Tie certs to inventory and revoke when devices retire.

3. Least-privilege topic authorization (ACLs)

   • Enforce topic-level permissions. Avoid wildcard-heavy grants like # unless intentional.

4. Broker hardening & isolation

   • Run brokers in isolated hosts/containers, with resource limits, process sandboxing, and logging.
   • If using managed brokers (cloud): remember shared responsibility — cloud manages infra, you configure auth/ACLs/cert policies.

5. Network-level controls

   • Segment MQTT traffic, use firewalls/VLANs, and require VPNs or private links for cross-site brokers.

6. Rate-limiting & quotas

   • Protect against accidental or malicious floods.

7. Monitor, log, and alert

   • Log connect/disconnect, authentication failures, publish rates, and ACL denies. Integrate into SIEM.

8. Safe defaults for retained messages & LWT

   • Avoid sensitive retained messages. Validate LWT content and restrict who can set it.

---

MQTT v3.1.1 vs MQTT 5.0 — quick comparison

Feature	MQTT 3.1.1	MQTT 5.0 (security win)
Reason codes for failures	No	Yes — clearer failure handling
Enhanced auth exchange	No	Yes — pluggable auth mechanisms
Topic alias and properties	Limited	Richer metadata (can help or hurt security)

Bottom line: MQTT 5.0 gives you better hooks for secure, observable behavior — but it's only useful if your stack supports it.

---

Practical pentest checklist — how to assess an MQTT deployment

• Can you connect anonymously? (Try mosquitto_sub without creds.)
• Are endpoints using TLS? Check certificate validity and name matching.
• Enumerate topics and retained messages: search for # and retained flags.
• Test authentication bypasses and weak creds.
• Try LWT abuse: can you publish a fake LWT to alter operator state?
• Verify ACLs: can a client publish to control topics?
• Stress test QoS & session persistence behaviors to surface DoS.

Toolbox: mosquitto_pub/sub, nmap NSE scripts (mqtt*), mqtt-explorer, custom scripts.

---

Config snippets & patterns

Example mosquitto.conf (TLS + ACL file):

listener 8883
cafile /etc/mosquitto/ca.crt
certfile /etc/mosquitto/server.crt
keyfile /etc/mosquitto/server.key
require_certificate true
use_identity_as_username true

acl_file /etc/mosquitto/acl

# ACL example lines:
# user device-thermostat-001
# topic write devices/thermostat/001/set
# topic read devices/thermostat/001/state

Note: If running this in a container, apply container hardening from our previous module: minimal base image, read-only FS where possible, resource limits, non-root user.

---

Cloud-managed MQTT: don’t outsource responsibility

Managed brokers (AWS IoT Core, Azure IoT Hub) handle patching and uptime, but you still must:

• Configure TLS and cert rotation
• Manage device identity & provisioning
• Define and enforce access policies
• Monitor logs and telemetry

Translate the shared responsibility concept: cloud = plumbing; you = who gets keys and who publishes what.

---

Red flags and gotchas (that will bite you later)

• Default installations with anonymous access enabled.
• Brokers bridged to different trust zones without ACLs.
• Excessive use of wildcards in topic permissions.
• Storing sensitive commands as retained messages.
• Using plaintext MQTT across WAN connections.

---

Closing — TL;DR & action plan

• Do not run MQTT like an open chatroom. Use TLS, strong identity (certs), and fine-grained ACLs. Harden brokers the same way you’d harden a container or server in the cloud.
• Treat MQTT as a critical service in OT: segment it, monitor it, and apply least privilege. If devices are too limited, use secure gateways.

Final thought: MQTT makes device-to-cloud simple — and attackers love simple. Make the path guarded with authentication, encryption, and boundaries. Think of brokers as the bouncers at the club: no ID, no access; bad behavior gets kicked out; logs record everything. Be the bouncer the network deserves.

---

Ready for a lab? Next up: we'll exploit a deliberately misconfigured broker (safe lab), show retained message and LWT abuse, then re-lock it using cert-based auth and ACLs. Bring popcorn.