MQTT TLS Authentication: Secure Brokers and Clients

MQTT TLS authentication involves two distinct concepts. TLS encrypts the connection and authenticates the broker itself. Authentication of clients connecting to the broker, either by username/password or by client certificate (mutual TLS) authenticates who is connecting. TLS by itself does not authenticate your devices. In production you should use TLS 1.3 whenever your stack supports it, validate the broker certificate on each client, and assign unique identity to each device.

Topics include differences between the methods, example working broker and client set-up, certificate life-cycle, port 8883, troubleshooting and production controls we recommend for sensors, controllers and telemetry on critical sites.

TL;DR

TLS secures the channel, it does not perform login. It provides confidentiality and broker authentication. Clients must still provide credentials or certificates.

• Mutual TLS (mTLS) is the strongest practical option available. Each device has a private key and a certificate and the broker denies anyone that does not have one.
• Port 8883 is just convention, not control. Security is enforced through broker config and certificate validation, not port.
• Troubleshoot in layers. Verify TLS handshake with openssl s_client, then verify the MQTT session.
• Renew your plans from day one. Expired or incomplete certificate chains are one of the most common reasons we see fleet-wide outages.

Table of Contents

What MQTT TLS authentication actually protects

MQTT outsources security to the implementer. The security section of the MQTT v5.0 specification notes that "The choice of authentication and authorisation technology is up to the implementer. For example, TLS certificates may be used to authenticate a client to server, and vice versa." MQTT v5.0 security notes. MQTT provides the hooks. You provide the hammer.

There are four layers to keep apart:

TLS: confidentiality and broker identity

RFC 9431, which defines the MQTT-over-TLS profile, says that TLS delivers confidentiality of MQTT messaging, and authentication of the broker. RFC 9431. The reality is that the whole connection is encrypted, headers, topic names, payloads. Red Hat Product Security guidance . That's important because topic names can inadvertently disclose details. A topic like site12/generator2/fuel_level advertises your property layout.

Teams always miss broker authentication. If your client speaks TLS but doesn't check that the broker certificate is signed by a trusted CA and that it matches the expected hostname, it can be convinced to connect to a fake. Encrypting to the wrong entity is still a compromise.

Username and password: useful, but not enough alone

Username and password are options in the MQTT CONNECT packet. They authenticate a client only if the broker requires and checks them. Used alone they do not authenticate the broker or encrypt traffic or prevent credentials from being sniffed, therefore encryption is needed on the network. MQTT v5.0 security notes. Without encryption, the username and password will be sent in cleartext. Red Hat Product Security guidance.

Passwords transmitted over TLS are only fine for low-risk situations like dashboards or person operated tools. For automated device fleets they suffer from a practical problem: shared passwords end up written into firmware images, spreadsheets and support tickets.

Mutual TLS: the device proves itself

With mTLS, the broker requires the client to present a certificate during handshake. The device must have a private key, which remains confidential, a device certificate, and a trusted root CA certificate to authenticate the broker. Sierra Wireless reference. The broker will deny the connection even before any MQTT packet is sent or received if the certificate is invalid, expired or not signed by a trusted CA.

RFC 9431 also lists other alternatives for client authentication over TLS, specifically raw public keys and preshared keys. This is noted alongside the client also authenticating the broker. RFC 9431. Options such as raw public keys and preshared keys may be considered for constrained devices, but by far the most common method is still using X.509 certificates.

Choosing an authentication model

Pick by asking what a stolen credential would cost you.

• Dashboards, engineering laptops, test tools: TLS plus individual username and password credentials, with permissions at the topic level.
• Fixed devices (sensors, gateways, controllers): mTLS using one certificate per device. Revoking one device will not affect other devices.
• For a mixed fleet during migration: run separate listeners, one requiring client certs and one with passwords. Retire the second on schedule. Client verification can be made optional on a single listener, however there are plenty of warnings from the TESAIoT project about how this severely compromises a fail-closed posture. TESAIoT TLS and mTLS notes . Separate listeners allow you to keep the hardened path hardened.

Examples in the Mosquitto configuration reference make clear how these two mechanisms coexist together: a client certificate can be required to be presented as the client identity, while username and password continue to be an additional or alternative mechanism of authentication and authorization. See the mosquitto.conf manual.

Configuring the broker

Same story across all brokers: server certificate and key for the broker itself, CA that signs client certs if you're doing mTLS. The Azure IoT Operations tutorial breaks it down the same way: broker has its own server cert and trusts client CA, clients trust broker CA and supply their own cert and key. Microsoft Learn tutorial .

Here's a pared down Mosquitto listener configured for mutual TLS:

tls_version tlsv1.2
listener 1884
cafile /etc/my-ca.crt
certfile /etc/my-cert.crt
keyfile /etc/my-cert.key
require_certificate true

This assumes you've already created /etc/my-ca.crt, /etc/my-cert.crt and /etc/my-cert.key.

Option names can be found on the mosquitto.conf manpage.

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

What each line does:

1. cafile names the CA that signed the client certificates the broker will accept.
2. certfile/keyfile are the broker's own identity. The certificate must include the hostname clients will connect to.
3. require_certificate true turns one-way TLS into mutual TLS.
4. use_identity_as_username true will use the certificate's common name as the MQTT username. This allows you to key your access control lists off of the certificate identity instead of a password.

For single-factor TLS use the following approach instead: remove the last two lines and use a password file for client identity.

Set the TLS version deliberately

RFC 9431 recommends usage of TLS 1.3 for MQTT. Section 7.1. While the SSL protocol name lives on in tooling interfaces and port labels, make sure you're actually running TLS. Be sure to check what your constrained devices actually support before locking your broker to version 1.3 only, and specify a minimum version explicitly instead of relying on defaults.

Configuring the client

Every client library exposes the same three inputs:

• CA certificate: certificate of the CA that issued the broker certificate. Client needs this to verify the broker.
• Client certificate: the device's own certificate, mTLS only.
• Client private key: the matching key, mTLS only.

A somewhat frequent forum thread error is: "Where do I download the CA certificate for a public broker?" For your own broker it is the root or intermediate certificate for whichever CA signed the broker certificate. This may be your private CA. Do not disable verification to fix the problem. Options like insecure or skip verify turn off the check that is actually validating the broker's identity.

Same story on microcontrollers: wrap the network client, Ethernet or Wi-Fi, in a TLS client, load the broker's CA certificate, and tack on the client certificate and key pair for mTLS. Make sure the device clock is accurate, as certificate validity checks are time dependent.

Certificates: issue, trust, store, renew

The handshake is the easy part. Operating certificates for years is the real work.

Guideline. Only use your own private CA on devices you own. Use one certificate per device and give it a distinct common name. Do not use the same certificate on a group of items.

Trust. Only install the CA certs your device requires. Devices that trust all public CAs have a larger attack surface than devices that only trust your one issuer CA.

Store. Keep private keys in a hardware security module like a TPM2 whenever possible. Encrypt private keys using a mechanism such as a TPM2 where the operating platform will allow. EVerest security guidance advises hardware-backed generation and storage of private keys for production use. EVerest security best practices.

Renew. Configure certificate lifetimes you can keep up with, warn yourself long before expiration, and practice the renewal process on a test device. Devices unable to obtain a new certificate are orphaned when their current one expires.

Revoke. Determine how you will disconnect a lost or compromised device: using a revocation list on the broker, short-lived certificates, or deletion of the identity from the access control list.

Port 8883 and what it does not do

IANA lists MQTT as service 1883 and secure MQTT as service 8883. The registry also states that assignment of a port number does not imply endorsement of the traffic sent on that port nor that traffic destined to that port is necessarily the assigned service. Simplified: opening port 8883 does not magically make it secure. If you have a listener on 8883 with TLS checks disabled, or even a plaintext listener that someone forgot is running on that port, it's not secure.

Audit what is actually listening:

• Block port 1883 from anything exposed to a network you do not have complete control over.
• Bind local-only listeners to loopback or a Unix domain socket.
• Ensure each exposed listener is actually enforcing TLS and authentication, do not assume from the port number alone.

Should you also need to decide on delivery guarantees for this same deployment, our guide to Mapping MQTT QoS to risk addresses that independent decision.

Troubleshooting MQTT TLS failures

Layer up from the network. Start testing MQTT TLS connections with a walkthrough recommending openssl s_client with broker hostname, SNI and hostname verification, then test the MQTT session after a successful handshake. testmqtt.com guide.

openssl s_client -connect broker.example.com:8883 -servername broker.example.com -verify_hostname broker.example.com -CAfile ca.crt

Look at the verification result and certificate chain output. According to the same page, common certificate errors indicate an untrusted or incomplete chain, expiration, or hostname mismatch.

Two tricks that save hours. Number one: separate your testing of the TLS handshake from MQTT so you know if it failed at the TLS layer or the MQTT layer. Number two: look at the broker log at the exact same time you attempt the connection. The broker will often tell you what the client didn't see.

Production hardening beyond TLS

TLS authentication is one control. For enterprise estates, add these:

• Minimize exposure. EVerest guidance recommends isolating the primary broker from network interfaces and utilizing Unix domain sockets for local traffic. Additionally, it suggests running a distinct broker instance for exposed APIs and connecting only the necessary topics. EVerest security best practices .
• Authorise per identity. Allow each device publish only to its own topics, and subscribe only to what it requires.
• Encrypt sensitive payloads. Red Hat Product Security states optimal confidentiality and integrity requires both transport encryption as well as payload-level encryption. Link to Red Hat Product Security guidance. Doing so ensures encrypted payloads at the broker level, past where TLS ends.
• Fail closed. By default, drop connections that have not authenticated. Disable optional client verification on production listeners.
• Monitor. Keep an eye on failed handshakes, expiring certificates and unexpected client identities. Failures will likely increase before an outage occurs.

At programme level, see our wider industrial IoT security roadmap whitepaper and identity-first controls for secure remote monitoring factsheet. On projects, where brokers and sensors sit on makeshift networks on jobsites, the same question needs to be posed to every software supplier in the supply chain, as this list of security demands for SaaS vendors explains. See our article on IoT for construction safety to understand how interconnected sites use all these connections day in day out.

Our perspective

The trend is clear. Someone enables TLS. They see the padlock-equivalent turn on their client and consider the task complete. Months down the road no one knows which device has which credentials. Certificates are expiring and the broker can be reached from locations it shouldn't.

We treat identity as a facet of the design, not a setting. Sensors and controllers each have their own identity. Authorisation cascades from there. Certificate expiry is monitored alongside every other important operational metric, think temperature, power, and so on. We build our monitoring platform and sensor integrations with those assumptions in place, and migrate teams' existing plaintext deployments onto them without tearing down monitoring.

If there is only one thing you remember from this guide: determine how you will renew and revoke certificates before issuing the very first certificate.

Harry

Secure telemetry from the first sensor

PODTECH engineers specialise in building software that runs mission critical infrastructure. We have experience with datacenter telemetry, building monitoring, legacy modernisation and enterprise automation. Whether you are migrating a plaintext MQTT estate to use authenticated TLS, or building a telemetry pipeline from scratch, our engineers can partner with your team on both architecture and implementation alongside your existing BMS, PMS and NMS. Our services run against a 99.9% uptime SLA, and we have successfully completed over 250 projects.

Visit our datacenter telemetry and integration services page or contact us about custom enterprise automation software.

FAQ

Is TLS enough to authenticate MQTT clients?

No. One-way TLS can be used to authenticate the broker to the client and encrypt traffic. It does not identify who the client is. You must use username and password credentials or tokens or, more securely, client certificates via mutual TLS.

Which is safer, TLS or SSL?

TLS. SSL was the older deprecated protocol family and most recent MQTT guidance refers to TLS. Even RFC 9431 calls out TLS 1.3 support for its MQTT profile. RFC 9431. Many tools colloquially refer to "SSL" out of legacy inertia. Verify what version of the protocol your broker actually negotiates.

Is MQTT port 1883 TCP or UDP?

IANA has MQTT assigned to port 1883 and secure MQTT to port 8883 for both TCP and UDP traffic. IANA registry . Real world implementations use MQTT over TCP. Accept 1883 as plaintext, accept 8883 as the normal TLS port, and check that it's actually listening.

How do I make MQTT secure?

Enable TLS on all connections and validate the broker's certificate with every client. Authenticate each client, ideally using its own certificate. Limit each identity to the topics that it needs access to, disable plaintext listeners on exposed networks, safeguard your private keys, and keep track of certificate expiration dates.

Do I need a client certificate if I already use a password?

Not necessarily, provided the link itself is TLS wrapped, and you have unique passwords that are properly maintained. Client certificates are preferable for unattended devices though, as the private key never has to traverse the network, and you can revoke one device without affecting the rest.

Sources

• RFC 9431: MQTT and Transport Layer Security (TLS) profile
• MQTT v5.0 security notes
• Red Hat Product Security: MQTT security guidance
• mosquitto.conf manual
• Microsoft Learn: Azure IoT Operations MQTT broker TLS and X.509 tutorial
• Sierra Wireless: MQTT security reference
• IANA service name and port number registry
• testmqtt.com: test an MQTT TLS connection
• EVerest security best practices
• TESAIoT TLS and mTLS notes
• Construction SaaS security: what to demand from every vendor

Recommended

• BACnet Secure Connect: an integrator's implementation briefing
• 6 Identity First Controls to Secure Remote Monitoring for IT and OT