MQTT Security for Constrained Devices: Best Practices

MQTT has no security of its own. A broker on an open port with anonymous access takes a message from anyone and hands it to anyone. On a device with small flash, a battery and a SIM card, each protection costs resources, so you choose which layers the device carries and which move to the server.

This post lists the practices we use in three product lines: the FlowID smart water filter on ESP32, the HomeSmart metering system with a LoRa mesh and GSM gateways, and the Micare GPS trackers. GSM devices have their own limits on top of these; our modem comparison covers that side.

Pick the protection level your hardware can carry

You have three building blocks:

• TLS with certificates. The strongest model: the device verifies the broker, and each device can hold its own identity. It needs a certificate store, a chain, a reliable clock and a renewal plan for devices that stay in the field for years.
• TLS-PSK. The link stays encrypted and the certificate chain goes away. Broker and device share a key and an identity string. The handshake is simpler and needs no clock. Plan how each device receives its key at flashing time.
• Credentials and an ACL. A username, a password and per-topic permissions stop strangers from using your broker. Combine them with an encrypted link.

Our rule: encrypt the link, authenticate every device, and limit each device to its own topics.

Encrypt the link on the device

FlowID devices connect to a Mosquitto broker over TLS-PSK. The firmware sets a pre-shared key and identity on the secure client of the ESP32 networking stack and runs the standard PubSubClient library over it. The board has 4 MB of flash and runs at 80 MHz, so we keep the message buffer small at 400 bytes and leave room for the application and over-the-air updates.

Give every device its own identity and access list

On the Micare platform every device has its own credentials on the broker and an access list built from the client identifier. A device reads and writes only its own topics, so a compromised tracker cannot touch another tracker’s data. Do not share one account across a fleet. When your key management allows it, use a different PSK per device.

Design topics for the long run

Devices in the field update slowly or never, so the topic layout has to outlive the first firmware.

• Use per-device topics so permissions can follow the device.
• Add a version prefix. HomeSmart devices publish telemetry to a topic of the form v1/telemetry/serial/channel and receive configuration on v1/config/serial/channel. New firmware can move to a new version while the server accepts both.
• Keep telemetry and configuration on separate branches so they can carry different permissions.

Keep business logic and browsers off the broker

The broker is transport. In FlowID a separate device-state service subscribes to the status messages and processes them. In HomeSmart the web front end never connects to the broker: the backend turns device messages into events, the page reads them from the API once a minute, and no broker credentials ever reach a browser. Events now persist as a bonus.

Provision over a controlled channel

Hand network credentials to a device over BLE. The FlowID firmware receives the network details over BLE, tries to join for up to thirty seconds, saves them only after a successful join and reports the result back over BLE. A device never stores credentials it cannot use.

Run the broker with care

• Choose a lightweight broker such as Mosquitto for small deployments.
• Switch persistence on so retained messages survive a restart.
• Watch broker memory from the first week in production.
• Turn off anonymous access.

Checklist

1. Turn off anonymous access on every broker, with no exceptions.
2. Encrypt the link. Use PSK when certificates are too heavy, and a different key per device if you can manage the keys.
3. Give each device an ACL that limits it to its own topics.
4. Keep browsers and apps away from the broker. Route them through the backend.
5. Version your topics from the first release.
6. Enable broker persistence if you rely on retained messages.
7. Deliver network credentials over a controlled channel and store them only after a successful connection.
8. Monitor broker memory.

These practices come from our projects. Your own system still needs its own security review.

Plan the security of your device fleet

If you are choosing between PSK, certificates and ACL-only for a fleet, talk to us. See our IoT development services, or read how the FlowID filter, the Micare tracker and the HomeSmart platform were built. Contact us, tell us about your hardware limits, and we will tell you which option fits.

Frequently Asked Questions

Is TLS-PSK secure enough for MQTT on a microcontroller?

It encrypts the link with a shared key and needs no certificate chain, which suits a small device. The key is the part to protect: give each device its own where key management allows, and add broker credentials and topic permissions on top.

Why not use full TLS with certificates on every device?

Certificates cost flash and RAM for the parser, the chain and the handshake, and they need a renewal plan for devices that sit in the field for years. On our ESP32 products we chose TLS-PSK for these reasons.

What does an MQTT ACL do?

An access control list restricts which topics each client may publish to and subscribe to. A device that can touch only its own topics cannot read or overwrite another device's data. Encryption does not give you this, so we use both.

Should a browser connect to the MQTT broker directly?

No. In HomeSmart the web front end has no broker connection. The backend consumes the messages and the browser reads events from the API, so no broker credentials ever reach the client.