Skip to main content
Cybersecurity · Cloud & DevOps · TLS 1.3

Post-Quantum TLS:
Deploy Hybrid ML-KEM Without Outages

Published: 12 September 2026·Zaid Aljbour, Managing Director·12 min read

Post-quantum TLS protects the key agreement of a TLS 1.3 connection against future quantum attacks. A hybrid mechanism is currently the lower-risk way to deploy it: X25519MLKEM768 combines traditional X25519 with NIST-standardised ML-KEM.

The difficult part is not the algorithm name but the complete connection path. A browser or API client, CDN or load balancer, service mesh, and origin can use different TLS stacks and defaults. Enforcing the hybrid group too early can block the exact connections the change is meant to protect.

Short answer: Roll out hybrid post-quantum TLS in stages. Inventory every TLS termination, update the cryptographic libraries, prefer X25519MLKEM768 with a traditional fallback at first, measure negotiation and failures by client and origin class, and enforce the hybrid group only in segments proven compatible.

What the new post-quantum TLS standard defines

IETF RFC 10024, published in August 2026, defines three hybrid key agreement groups for TLS 1.3: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024. Each combines ML-KEM with an ephemeral Elliptic Curve Diffie-Hellman exchange. Under the construction’s security model, the combined exchange remains protected while at least one component remains unbroken.

ML-KEM is a key encapsulation mechanism: it lets two parties establish a shared secret over a public channel. NIST FIPS 203 standardises the ML-KEM-512, -768, and -1024 parameter sets. The number identifies a parameter set; it is not a symmetric key length or a TLS version.

On 3 September 2026, the IETF also approved the description of standalone ML-KEM in TLS 1.3 as an Informational RFC. The IESG notice makes an important qualification: standalone ML-KEM is not recommended for general use, while the hybrid X25519MLKEM768 group is the default in many TLS implementations. Migration plans need to distinguish “implemented” from “recommended for general use.”

Key agreement and certificates are separate migrations

TLS functionCurrent migration pathWhat remains unresolved
Session-key confidentialityHybrid agreement such as X25519MLKEM768Authenticity of the server and certificate chain
Server authenticationUsually traditional certificate signatures today; ML-DSA integration is evolvingBroad compatibility across browsers, certificate authorities, and PKI
End-to-end protectionAssess every TLS leg separatelyProtection behind a terminating edge or proxy
Cryptographic agilityVersioned policy, replaceable libraries, and telemetryAutomatic evidence that every peer negotiated the modern group

Hybrid key agreement addresses “harvest now, decrypt later”: an attacker records encrypted traffic now and hopes to break the traditional exchange later. It does not make a traditional certificate chain post-quantum secure. The Chromium roadmap dated 27 February 2026 therefore treats post-quantum authentication as a separate, multi-stage transition involving browsers, certificate authorities, and servers.

On 10 September 2026, the IETF also approved the use of ML-DSA for TLS 1.3 authentication for publication. That adds a protocol building block; it is not an instruction to disable the traditional Web PKI immediately. A practical programme tracks key agreement, certificates, trust anchors, and application protocols as separate migration streams.

The origin path determines protection and availability

With a CDN, the client connection terminates at the edge. Uncached content creates a second TLS connection from the edge system to the origin. Post-quantum protection in the browser therefore does not prove that the origin leg is hybrid too. The same boundary appears at API gateways, ingress controllers, service-mesh sidecars, and outbound service calls.

Cloudflare reported a new automatic selection mechanism for origin key agreement on 8 September 2026. In the provider’s currently scanned origin cohort, the measured HelloRetryRequest rate fell from about 52% to 3.7%; 99.2% of post-quantum-capable TLS 1.3 connections then completed in one round trip. This provider measurement is not a universal benchmark for other networks. It does, however, expose the operational job: discover capabilities, offer the right group, and observe the result.

Availability risk: If policy allows only X25519MLKEM768 but the origin does not support that group, the peers have no common algorithm and the TLS 1.3 connection fails. Enforce “post-quantum only” only after positive compatibility evidence.

A decision matrix for safe ML-KEM migration

Operating contextSensible policyRelease criterion
Unknown external clientsPrefer hybrid; allow a traditional fallbackNegotiation and failures visible by client class
Controlled service-to-service legEnable hybrid on both sides; enforce laterEvery instance, failover path, and rollback tested
CDN to owned originVerify origin support, then prefer hybridNo increase in TLS failures or origin latency
Legacy devices or embedded clientsSeparate segment and transition periodNamed owner for upgrade, gateway, or retirement plan
Binding cryptographic requirementEnforce only approved groupsCompatibility evidence plus documented exception and emergency policy

This matrix is technical guidance, not a certification or legal determination. Whether a hybrid mechanism satisfies a specific requirement can depend on the approved cryptographic module, parameter choice, operating mode, and assessment scope.

Seven steps for a measurable post-quantum TLS pilot

  1. Inventory TLS terminations. Record client, edge, load balancer, ingress, mesh, origin, and outbound API legs separately, with an owner, TLS library, and version.
  2. Prioritise data by lifetime. Start with information that must remain confidential for years. A defined retention period is more useful than a speculative Q-Day forecast.
  3. Verify libraries and peers. Capture the groups actually offered and negotiated in a test environment. A product name or licence is not evidence of runtime behaviour.
  4. Prefer hybrid first. Enable X25519MLKEM768 with a controlled traditional fallback. Version the configuration and record the path back.
  5. Separate telemetry. Measure negotiated group, TLS version, HelloRetryRequest, handshake failure, and latency by client, region, and origin class. Do not log secrets or full payloads.
  6. Exercise failure modes. Test old clients, stale origins, failover targets, certificate rotation, restarts, and network devices that may mishandle larger handshake messages.
  7. Tighten by segment. Enforce hybrid operation only on controlled paths. Define thresholds for automatic or manual rollback and rehearse the fallback regularly.

The pilot belongs in a Cloud and DevOps operating model with observable releases. The cryptographic inventory, threat model, and exception process belong in the cybersecurity design. For heterogeneous providers, the multicloud security control model adds a way to prove equivalent outcomes across different products.

Frequently asked questions about post-quantum TLS

What is hybrid post-quantum TLS?

It combines a traditional algorithm such as X25519 with ML-KEM in one TLS 1.3 key exchange. The shared key remains protected as long as at least one component remains secure.

Does X25519MLKEM768 replace the TLS certificate?

No. The group protects key agreement. Server authentication and the certificate chain are separate TLS functions and may still use traditional signatures.

Should post-quantum TLS be enforced immediately?

Only when every relevant peer is proven compatible and a binding policy requires traditional algorithms to be excluded. Otherwise, preferring hybrid negotiation with a traditional fallback is the safer migration path.

Which metrics belong in a pilot?

At minimum, collect the negotiated group, TLS version, handshake failures, HelloRetryRequest rate, handshake latency, client and origin class, and successful fallbacks. Keep application and infrastructure metrics separable.

Sources and methodology

This article separates published standards and provider statements from ATMAN’s recommendation for a staged pilot. Cloudflare figures are provider-specific observations and were not independently reproduced. Sources accessed 12 September 2026.