TLS 1.2 post-quantum key exchange: is it supported?

No standard defines post-quantum key exchange for TLS 1.2. The IETF has frozen TLS 1.2 (RFC 5246) and specifies hybrid ML-KEM key agreement only for TLS 1.3 (RFC 8446). For OT and critical infrastructure, this means web HMIs, embedded web servers and engineering interfaces that stop at TLS 1.2 have to be protected from outside the device.

The issue is “harvest now, decrypt later”. Traffic recorded today could be decrypted once a cryptographically relevant quantum computer exists. OT assets often stay in service for decades, and process data, network layouts and credentials can stay sensitive for just as long. The sections below cover the standards position, the US federal timeline, and the practical choices for devices that will never get a TLS 1.3 firmware update.

Does TLS 1.2 support hybrid ML-KEM key exchange?

No, and it never will through the IETF. RFC 9851, “TLS 1.2 is in Feature Freeze”, is a Proposed Standard published in July 2026, and it closes the door on new TLS 1.2 key exchange algorithms.

The authors put it bluntly. Rich Salz and Nimrod Aviram wrote that “post-quantum cryptography for TLS 1.2 WILL NOT be supported (see Section 4) at any time and anyone wishing to deploy post-quantum cryptography should expect to be using TLS 1.3.” The working group’s position was summed up at IETF 118: TLS 1.2 won’t change or get better, although bugs might be fixed if they are found.

Research builds have combined post-quantum algorithms with TLS 1.2, but none of them have registry codepoints, so they won’t interoperate with standard clients. For an operator, “TLS 1.2 with ML-KEM” is not something to buy or enable.

Why are hybrid post-quantum groups only defined for TLS 1.3?

TLS 1.3’s key exchange is built so that a new hybrid group needs only a new codepoint. In TLS 1.2, key exchange is tied to cipher suites the IETF no longer extends. NIST describes TLS 1.3 as a practical near-term path to quantum-resistant key establishment, including through hybrid key-exchange mechanisms that combine ML-KEM with classical algorithms.

The structural difference

In TLS 1.2 (RFC 5246), the key exchange method is part of the cipher suite name, for example ECDHE_RSA. The server sends its parameters in a separate ServerKeyExchange message. TLS 1.2 also still allows static RSA key transport, which has no forward secrecy. In TLS 1.3 (RFC 8446), the client sends ready-made key shares for named groups in its first message, and forward secrecy is mandatory. A hybrid group simply carries two shares, one classical and one post-quantum, in that existing slot.

That is the mechanism RFC 10024 uses. It 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. ML-KEM itself is standardised in FIPS 203.

Why the size matters for embedded stacks

Post-quantum key shares are far larger than classical ones:

• For X25519MLKEM768, the client share is 1216 bytes (1184 bytes for the ML-KEM part and 32 bytes for X25519), and the server share is 1120 bytes (1088 bytes for the ML-KEM part and 32 bytes for X25519).

A ClientHello of that size usually spans more than one TCP segment. Embedded TLS stacks with small receive buffers, and middleboxes that expect the whole ClientHello in one packet, can fail on it. So moving an OT device to TLS 1.3 doesn’t guarantee it can negotiate a hybrid group. Test that separately.

What is the deadline for TLS 1.3 support under US federal policy?

Federal agencies must support TLS 1.3 no later than January 2, 2030. According to NIST, agencies are required by Executive Order 14306 and OMB Memorandum M-26-15 to support TLS version 1.3 no later than January 2, 2030.

That deadline sits on top of earlier and later milestones:

Executive Order 14306 was issued on June 6, 2025. OMB M-26-15, Execution of the Migration to Post-Quantum Cryptography, is dated June 24, 2026. NIST explains why TLS gets early attention: it protects data in transit for nearly every federal system and service, making it a primary target for “harvest now, decrypt later” collection. SP 800-52 itself is being revised. Guidance on hybrid key exchange in TLS will be reflected in the next revision of SP 800-52.

These rules bind federal agencies, not private utilities or manufacturers. Still, they shape vendor roadmaps and procurement criteria across critical infrastructure. CISA’s Acting Director Madhu Gottumukkala said that “to stay ahead of these emerging risks, organizations must prioritize the procurement of PQC-capable technologies.”

How do you find OT devices still negotiating TLS 1.2 or older?

Start with passive observation of TLS handshakes on your OT network. Then confirm specific devices with careful, targeted probes. NIST says that systems that cannot support post-quantum cryptography should be identified and prioritized, and that starts with an accurate inventory.

Read the handshake correctly

A common mistake is to trust the version field in the ServerHello. Under RFC 8446, a TLS 1.3 server still puts the TLS 1.2 value (0x0303) in that legacy field. It signals TLS 1.3 only through the supported_versions extension. A sensor or parser that ignores that extension will report every TLS 1.3 session as TLS 1.2. For each session, record:

• the negotiated version, taken from supported_versions where present;
• the cipher suite, so you can flag static RSA key exchange separately (it is the weakest TLS 1.2 case);
• the negotiated key exchange group, which shows whether TLS 1.3 sessions use a hybrid group or a classical one;
• for TLS 1.2, the server certificate, which is sent unencrypted and shows key type, expiry and issuer without touching the device.

Probe sparingly

Passive capture only sees devices that are used during the capture window. Engineering interfaces may be opened only a few times a year. Fill the gaps by sending single handshakes, one per TLS version, to the web ports you already know about. Do this at a low rate, during a maintenance window, and only after checking the vendor’s guidance on scanning. Some embedded stacks handle repeated or malformed connections poorly. Check firmware release notes too: they often state whether a TLS 1.3 update exists.

Record what drives priority

For each TLS 1.2 endpoint, note four things: how long the data it carries stays sensitive, whether the traffic crosses an untrusted path (a WAN link, the internet, a cloud connection), whether the vendor offers a TLS 1.3 upgrade, and who owns the asset. An HMI that operators only reach over a local panel network is a different risk from one reached by remote engineers over the internet.

How do you protect web HMIs and embedded OT web servers that only support TLS 1.2 against harvest now, decrypt later?

You can’t make the device’s own TLS 1.2 handshake quantum-resistant. What you can do is make sure that handshake never crosses a path where someone can record it. Wrap or replace that part of the connection with post-quantum protection, and keep the remaining TLS 1.2 leg as short and as physically contained as possible.

A workable order of steps:

1. Upgrade where firmware allows. If the vendor offers TLS 1.3, test it, including whether the stack accepts a large hybrid ClientHello.
2. Harden what remains. Turn off static RSA key exchange and CBC suites wherever the device allows it. This removes classical weaknesses, but it doesn’t add quantum resistance.
3. Shorten the exposed path. Put a TLS 1.3 reverse proxy or a quantum-safe tunnel endpoint as close to the device as you can, so that only a short, trusted segment carries TLS 1.2.
4. Keep the device off untrusted paths. Remote access to the HMI should go through the protected path, not through port forwarding or a separate legacy VPN.

Is a TLS 1.3 reverse proxy or a quantum-safe tunnel the better fix for legacy OT web interfaces?

It depends on what crosses the untrusted path. A reverse proxy fits when browser users reach a few web interfaces. A network-layer tunnel fits when the link between sites, the cloud or remote users carries many protocols, not only HTTPS. Many operators end up using both.

A proxy is useful when the operators’ browsers support hybrid groups and the proxy can sit in the same cell or cabinet as the HMI. It becomes awkward when the device needs mutual TLS or uses thick-client components.

A tunnel is the better fit when the exposure is the link itself: a substation reporting to a control centre, a plant connecting to a cloud historian, or a remote engineer connecting to a site. One example is Quantum Network’s QPN gateway. It encrypts at Layer 3 with a hybrid key agreement that combines a classical part and ML-KEM (FIPS 203) into one session key, renews both handshakes every two minutes, and needs no software on the equipment behind it. Like any tunnel, it protects data in transit rather than the devices themselves, and it does not replace a central firewall.

What order should an OT team tackle this in?

First build the inventory. Then protect the paths that cross untrusted networks. Then work through device upgrades as vendors deliver TLS 1.3 with hybrid groups. Remote access and inter-site links usually come first, because that is where recording traffic is most practical and where data that stays sensitive for years travels.

Plan proxies and tunnels as long-lived infrastructure. With TLS 1.2 frozen, devices that can’t upgrade will rely on that outer protection until they are retired.