Post-quantum MQTT TLS: how to use hybrid ML-KEM

Post-quantum MQTT TLS means running the MQTT protocol over TLS 1.3 with a hybrid key exchange, where a classical elliptic-curve exchange and the post-quantum ML-KEM mechanism from FIPS 203 combine into one session secret. Telemetry recorded today cannot then be decrypted later by a quantum computer that breaks only the elliptic-curve part.

For OT and critical infrastructure operators this matters because MQTT often carries process values, alarms and setpoints over the public internet or shared carrier links between substations, plants and a central broker. This article explains what works today, how to configure a broker you run yourself, what it costs on edge hardware, and what to do with devices that will never get a firmware update.

Can MQTT over TLS use hybrid ML-KEM key exchange?

Yes. MQTT does not define its own cryptography, so any MQTT 5.0 or 3.1.1 connection over TLS 1.3 can negotiate a hybrid ML-KEM group if both the broker’s and the client’s TLS stacks support it.

OASIS MQTT 5.0 leaves transport security to the layer below. The IETF ACE profile for MQTT states it plainly: the protocol relies on TLS for communication security between entities. The key exchange itself is the standard TLS 1.3 handshake from RFC 8446, extended with new supported groups.

Those groups are now standardised. RFC 10024 defines three hybrid key agreement mechanisms for TLS 1.3 (X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024) that combine the post-quantum ML-KEM with an ECDHE exchange. The design goal is to provide security against both classical and quantum adversaries while maintaining compatibility with existing infrastructure and protocols.

One technical detail is relevant for audits. For SecP256r1MLKEM768, the IETF specification sets the combined secret at:

• 80 bytes: 48 bytes for the ECDH part and 32 bytes for the ML-KEM part (IETF draft-ietf-tls-ecdhe-mlkem-05, 2026).

Because both parts feed the TLS key schedule, the session stays confidential as long as either component holds.

How do I configure an MQTT broker in my own data centre for X25519MLKEM768 or SecP256r1MLKEM768?

Configuration happens in the TLS layer of the broker, not in MQTT settings: enforce TLS 1.3, list the hybrid groups first in the supported-groups preference, and verify the negotiated group on the wire.

Step 1: Confirm library support on both ends

Check that the TLS library linked into the broker, and into each client firmware or gateway, implements the RFC 10024 codepoints rather than an earlier draft. Pre-standard implementations used different identifiers, and a mismatch silently results in a classical-only handshake. The registered value to look for is X25519MLKEM768 Value: 4588 (0x11EC).

Step 2: Set protocol version and group order

Hybrid groups exist only in TLS 1.3, so set the minimum protocol version on the MQTTS listener (typically port 8883) to 1.3. Then set the groups list in preference order, for example X25519MLKEM768, then SecP256r1MLKEM768, then a classical fallback such as X25519 for clients you have not migrated yet. Choose SecP256r1MLKEM768 first where your policy requires a NIST curve for the classical half, since any of the hybrid groups specified in this document may be implemented in a FIPS-approved way.

Step 3: Verify, then tighten

Capture a handshake and confirm that the ServerHello key_share carries the hybrid group, not the fallback. Log the negotiated group per client ID so you can see which field devices are still classical. Once the inventory shows no classical clients on a listener, remove the fallback from that listener.

Do post-quantum TLS handshakes slow down MQTT reconnects on constrained edge devices?

On capable edge hardware the extra compute is negligible. The real cost on constrained devices is bandwidth and packet count, because the ML-KEM key share makes the ClientHello and ServerHello noticeably larger.

Compute is rarely the bottleneck. The IETF UTA working group notes that ML-KEM requires less CPU than X25519. A 2026 layered measurement found these handshake latencies:

The authors concluded that the effect is practically negligible once measured against normal variance.

Constrained links behave differently. The IETF guidance warns that larger post-quantum artefacts pose challenges for constrained environments (e.g., IoT) and increasing handshake times in high-latency or lossy networks. On cellular, satellite or low-power radio backhaul, a ClientHello that no longer fits in one segment adds round trips, and each extra packet raises the chance of a retransmission.

Practical mitigations for MQTT clients:

• Send the right key share first. If the client sends a classical share and the broker prefers a hybrid group, TLS 1.3 forces a HelloRetryRequest and a full extra round trip. Configure clients to send the hybrid share in the first ClientHello.
• Add jitter to reconnects. After a site-wide outage, hundreds of devices reconnecting at once multiply handshake load on the broker. Randomised backoff spreads that load.
• Use resumption carefully (see the next section) instead of full handshakes on every reconnect.
• Defer post-quantum certificates. Key exchange is what protects against recorded-traffic decryption. Larger ML-DSA chains can wait until signature migration.

How do persistent MQTT sessions affect harvest now, decrypt later risk for industrial telemetry?

An MQTT session and a TLS session are different things. Persistence at the MQTT level does not by itself increase exposure, but long-lived TLS connections and certain resumption modes stretch one key exchange over a large volume of telemetry.

The threat model is well documented. Europol puts it bluntly: “This threat does not require the attacker to have a quantum computer today.” NIST, in NIST IR 8547, adds that “Since sensitive data often retains its value for many years, starting the transition to post-quantum cryptography now is critical”. NIST also notes that harvest-now-decrypt-later needs to be considered when determining a migration timeline for the key-establishment scheme.

In MQTT 5.0, the Session Expiry Interval controls how long the broker keeps subscriptions and queued QoS 1 and 2 messages. When a Client connects with a long Session Expiry Interval, the Broker may need to maintain the Client’s MQTT session state after it disconnects for an extended period. That state lives on the broker. It is not carried in the TLS keys, so reconnecting with a fresh hybrid handshake fully re-protects the queued messages delivered afterwards.

The exposure sits in three places:

Timelines from regulators make this concrete. NIST’s proposed transition in NIST IR 8547 puts 112-bit quantum-vulnerable algorithms at deprecated after 2030, disallowed after 2035 (NIST, MPTS 2026). The EU coordinated roadmap sets the following target:

• By end of 2030: high-risk use case migrated: critical infrastructure (eg water, energy, health care, finance and transportation) (ENISA/European Commission, 2026).

Grid topology, process recipes and production volumes often stay sensitive well beyond 2030, so telemetry recorded today falls inside that window.

What should I do when field sensors cannot support post-quantum TLS?

Terminate the quantum-vulnerable leg as close to the sensor as possible, and carry the traffic across every untrusted network inside a hybrid post-quantum tunnel. Replacing the sensor can then follow its normal lifecycle.

Many PLCs, RTUs and wireless sensors use TLS stacks frozen in firmware, or MQTT without TLS at all. ENISA’s roadmap material acknowledges that devices deployed today remain in the field for decades. A workable pattern has four parts:

1. Inventory by negotiated group. Use the broker logs from the configuration step to list every client still negotiating classical groups. Record firmware version and vendor upgrade path.
2. Shorten the exposed segment. Let legacy sensors talk to a local broker or edge gateway on the same protected cell. Only that gateway talks to the central broker or cloud, and it does so with an RFC 10024 hybrid group.
3. Tunnel what cannot be re-terminated. Where re-terminating MQTT is not possible (because of certificate pinning or vendor support terms, for example), protect the network path instead. A Layer 3 gateway at each end encrypts everything above it, including legacy MQTT and the TLS inside it. Quantum Network’s QPN is one example of this approach: it combines a classical part and ML-KEM into one session key, renews both handshakes every two minutes, and installs no software on the equipment behind the gateway.
4. Plan replacement with crypto-agility as a requirement. When specifying new field devices, require that the algorithms can be replaced through updates. This matches the ENISA position that cryptographic routines and ciphers can be easily upgraded or replaced without having to completely replace the underlying application or device.

Where the line between “protected” and “exposed” falls

The test is simple: on every network segment that an outsider could tap (public internet, carrier MPLS, leased lines, radio backhaul), is the session key established with ML-KEM? Inside a physically controlled control cabinet, a classical session is a lower risk. On the WAN between a substation and the control centre, it is the traffic that harvest-now-decrypt-later collection targets.

NIST’s guidance sums up the direction: organizations must identify where vulnerable algorithms are used and plan to replace or update them. For MQTT, that means a broker that prefers hybrid groups, clients that send the hybrid share first, resumption that always runs a fresh key exchange, and a tunnel for any device that cannot do any of this.