Where to terminate post-quantum TLS in a data centre

Choosing where to terminate post-quantum TLS in a data centre means deciding where a hybrid TLS 1.3 session from an edge device, negotiated with a key exchange such as X25519MLKEM768, gets decrypted. Past that point, data is only protected by whatever the next hop negotiates. So the termination point decides how far quantum-safe protection actually reaches.

For organisations that run OT and critical infrastructure, this is a practical design question. Edge devices in substations, pumping stations or factory cells send telemetry and control data that can stay sensitive for decades. Upgrading the internet-facing load balancer is the easy part. The hard part is everything behind it.

Where should hybrid post-quantum TLS from edge devices be terminated in a private data centre?

Terminate it as close to the application as you can manage. If you terminate earlier, at a load balancer or reverse proxy, every onward hop has to negotiate its own hybrid key exchange or travel inside another quantum-safe layer.

The key exchange is defined in the IETF work draft-ietf-tls-ecdhe-mlkem, which 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 draft has since been ultimately published as RFC 10024. The post-quantum half, ML-KEM, is specified in FIPS 203.

Statistic: NIST released FIPS 203, the Module-Lattice-Based Key-Encapsulation Mechanism Standard, on 13 August 2024 (NIST, 2024).

Comparing termination patterns

The last pattern separates the two problems. One example is a virtual Quantum Network Quantum Gateway running in the organisation’s own data centre on a supported Linux platform. It encrypts at Layer 3 with a hybrid key agreement that combines a classical part with ML-KEM, so the TLS sessions inside, whether classical or hybrid, travel within a post-quantum protected layer. Nothing has to be installed on the servers behind it.

Is traffic behind a TLS-terminating load balancer still exposed to harvest now, decrypt later?

Yes, if the load balancer re-encrypts to backends with a purely classical key exchange. Anyone who can record that internal leg (a mirrored switch port, a compromised hypervisor, a shared colocation link) gets ciphertext that a future quantum computer could open.

The joint factsheet from CISA, NSA and NIST for critical infrastructure states that cyber threat actors could be targeting data today that would still require protection in the future, and names this a “harvest now, decrypt later” operation. Nothing about the threat says it stops at the perimeter. A load balancer to backend leg that negotiates plain ECDHE is exactly as recordable as an internet link, and often less monitored.

Do internal connections between a reverse proxy and backend servers also need ML-KEM?

They do whenever the traffic is long-lived and confidential and the leg crosses infrastructure where recording is possible. The exception is a leg that already runs inside another quantum-safe layer.

NIST’s guidance is broad: organizations must identify where vulnerable algorithms are used and plan to replace or update them. An internal TLS hop using X25519 or P-256 ECDHE is one of those places. In OT environments the backend is often a historian, SCADA server or MQTT broker running an older TLS library, so check this per system.

What the backend stack needs

• TLS 1.3. The hybrid groups are TLS 1.3 key shares under RFC 8446. A TLS 1.2-only backend cannot take part.
• The Key Share and Supported Groups extensions. NIST SP 800-52r2 already requires TLS 1.3 servers to support this extension as described in Section 4.2.7 of RFC 8446, but the library must also recognise the new group codepoints.
• A validated ML-KEM implementation where FIPS applies. The IETF text notes that for X25519MLKEM768, the ML-KEM implementation must be certified.

Statistic: NIST SP 800-52r2 required federal agencies to support TLS 1.3 by January 1, 2024 (NIST, 2019). Backends that still lack TLS 1.3 were already behind that baseline before post-quantum requirements came into play.

What breaks when only the front-end load balancer supports X25519MLKEM768?

Mostly nothing visible, which is the problem. Edge devices connect, dashboards show hybrid handshakes at the front, and the internal legs quietly keep negotiating classical groups. Several concrete failure modes come with that.

False assurance in reporting

Front-end logs record the negotiated group for the client side only. Compliance dashboards built on those logs report full coverage while backend legs run classical ECDHE. Audits that sample only the external endpoint will not catch this.

Larger handshakes on the backend path

Once you do enable hybrid groups internally, the ClientHello grows a lot.

Statistic: With X25519MLKEM768, the size of the client share is 1216 bytes (1184 bytes for the ML-KEM part and 32 bytes for X25519) (IETF draft-ietf-tls-ecdhe-mlkem-05, May 2026).

Statistic: The size of the server share is 1120 bytes (1088 bytes for the ML-KEM part and 32 bytes for X25519) (IETF draft-kwiatkowski-tls-ecdhe-mlkem-03, 2024).

A ClientHello of this size can span more than one TCP segment. Internal inspection devices, older IDS rules or OT protocol gateways that expect the whole ClientHello in a single packet may mis-parse it or drop it. Test with your real internal path MTU, including any tunnels or VLAN overlays.

Extra round trips and silent downgrades

If the load balancer’s backend client sends a classical key share by default and offers the hybrid group only in its supported list, a hybrid-capable backend may answer with a HelloRetryRequest, which adds a round trip. The opposite case is worse. A backend that does not recognise the hybrid group just picks a classical one, the handshake succeeds, and no alarm goes off.

Fragmented crypto ownership

The network team owns the load balancer, application teams own backend TLS libraries, and OT vendors own the embedded stacks. Without one inventory, nobody can say which hops are quantum-safe. This is the gap the CISA, NSA and NIST factsheet points at when it asks organisations to build inventories as part of a quantum-readiness roadmap.

How do you verify end-to-end quantum-safe encryption from edge device to application?

Verify each hop on its own. For every TLS hop, prove that the hybrid group was actually negotiated. For every non-TLS hop, prove that the traffic travels inside another quantum-safe layer.

A hop-by-hop verification method

1. Draw the real path. List every point where TLS is terminated or re-originated: edge device, any site proxy, internet load balancer, WAF, service mesh sidecar, application server. Each termination starts a new key exchange.
2. Capture handshakes per segment. On each segment, capture the ServerHello and check the key_share group. X25519MLKEM768 uses codepoint 0x11EC (4588). Anything else, such as x25519 or secp256r1 on their own, marks a classical hop.
3. Probe with a hybrid-only client. From inside the data centre, connect to each backend with a TLS 1.3 test client restricted to the hybrid group. A failed handshake proves the backend cannot negotiate it, which is clearer than a successful mixed-group test.
4. Log the negotiated group on servers. Configure backend servers to write the negotiated group to their access logs. Alert on any classical group from internal clients that should be hybrid.
5. Check non-TLS legs. Health checks, replication, syslog and OT protocols such as Modbus/TCP often bypass TLS completely. Either move them into TLS 1.3 with hybrid groups or carry them inside a quantum-safe network-layer tunnel.
6. Re-test after every change. Library updates, load balancer firmware and new backend pools can reset group preferences without anyone noticing.

How do NIST timelines affect the termination decision?

The timelines make internal legs a planned migration item, not an optional extra. Under NIST IR 8547, NIST will deprecate and ultimately remove quantum-vulnerable algorithms from its standards by 2035, with high-risk systems transitioning much earlier.

Statistic: NIST IR 8547 proposes that quantum-vulnerable public-key algorithms at 112-bit security strength are deprecated after 2030 and disallowed after 2035 (NIST, 2025).

The TLS configuration baseline is also changing. NIST has announced that it expects to revise SP 800-52 Rev. 2 to align it with recent Internet Engineering Task Force (IETF) drafts on TLS 1.3. If you design termination now around TLS 1.3 everywhere, with hybrid groups on every hop, you avoid redoing the backend architecture when that revision arrives.

Prioritising which legs to fix first

Not every internal leg carries the same risk. Rank them by two factors: how long the data must stay confidential, and how exposed the physical path is. Control commands and real-time sensor values often lose sensitivity quickly. Engineering drawings, network topology exports, credentials in configuration pushes and historian archives do not. Legs that cross sites, providers or shared fibre should come before legs inside a single cage.

Where a backend cannot be upgraded for years, which is common with certified OT systems, putting the leg inside a network-layer quantum-safe tunnel is a realistic stopgap. For example, a Quantum Network gateway at each end of the path renews its classical and ML-KEM handshakes every two minutes and protects data in transit without changing the system behind it. It does not replace firewall inspection or protect the endpoints themselves, so it goes alongside, not instead of, the existing security architecture.