Post-Quantum TLS in 2026: How to Test, Evidence and Govern Hybrid Key Exchange

Why key exchange is the first post-quantum control

An adversary can record TLS traffic today and decrypt it once a quantum computer can break the elliptic-curve key exchange that protected it. That harvest-now, decrypt-later risk, covered for boards in this Security Solution Consultants briefing, applies to every session negotiated with classical key exchange, including sessions that use forward secrecy.

Hybrid key exchange in TLS 1.3 closes it. Client and server run a classical exchange (X25519 or a NIST curve) and ML-KEM, the lattice-based mechanism NIST standardised as FIPS 203, then combine both secrets. An attacker has to break both. Nothing about the key exchange needs a new certificate or public key infrastructure, which is why it can be deployed years before post-quantum signatures.

Standards status in September 2026

The UK NCSC wrote in March 2025 that hybrid mechanisms were not yet standardised and that IETF standards were likely around 2027. They arrived a year early. Any internal policy that still says "wait for the standards" is out of date.

It is a key exchange group, not a cipher suite

People often search for post-quantum TLS cipher suites. In TLS 1.3 there are none to add. The post-quantum element is negotiated as a key exchange group, offered in the supported_groups and key_share extensions of the ClientHello. The cipher suite, for example TLS_AES_256_GCM_SHA384, does not change. That matters for policy wording and for configuration: editing cipher suite lists achieves nothing, and the groups list is where the work is.

It also makes post-quantum TLS a TLS 1.3 feature. There is no standard hybrid ML-KEM path for TLS 1.2, so endpoints still limited to TLS 1.2 cannot be made quantum-safe by configuration. They belong in the exceptions register with a replacement date.

The size change is real but manageable. An X25519MLKEM768 client key share is 1,216 bytes against 32 bytes for X25519 alone, which pushes the ClientHello beyond a single packet. When Chrome turned hybrid key exchange on for desktop users in 2024, it measured a 4% increase in median handshake latency.

Where adoption stands, component by component

The pattern is consistent: the client side is largely done, and the server side is opt-in or depends on your software versions. Cloudflare found that only about 10% of customer origin servers supported X25519MLKEM768 in February 2026, up from under 1% a year earlier. For most organisations, that origin gap is the whole problem.

How to run a post-quantum TLS test

Test what is negotiated, not only what is supported. Four methods cover most estates.

1. OpenSSL 3.5 or later, strict test. Offer only the hybrid group, so the handshake fails if the server does not support it. The output reports the negotiated group, which should read X25519MLKEM768; the exact wording varies by OpenSSL version.

openssl s_client -connect www.example.com:443 -tls1_3 \
  -groups X25519MLKEM768 </dev/null 2>&1 | grep -i group

Run it again without -groups to see what the server chooses from OpenSSL's default list, which is closer to what real clients experience.

2. macOS Tahoe 26. Apple's nscurl reports the negotiated key exchange group:

nscurl --tls-diagnostics https://www.example.com

3. Cloudflare Radar. Since February 2026 the Radar post-quantum page tests whether a hostname negotiates post-quantum key exchange, with an API for bulk checks.

4. Browser developer tools. In Chrome or Edge, the Security panel shows the key exchange group for the current connection.

For evidence at scale, use logs rather than spot tests. AWS Application Load Balancer connection logs and Network Load Balancer access logs record whether classical or post-quantum key exchange was used for each connection. CDN analytics and packet captures (group 0x11EC in the ServerHello key_share) fill the gaps. Record the result per service per month, because a capability scan tells you what a server can do, not what your clients actually get.

Do not forget SSH. OpenSSH 10.1 and later clients warn when a server does not negotiate post-quantum key agreement, which makes legacy bastions and appliances easy to find.

Eight ways post-quantum TLS fails quietly

1. A large ClientHello breaks servers and middleboxes. Some implementations assume the ClientHello arrives in a single read and reset the connection instead of falling back. The tldr.fail project tracks affected products; firewalls, proxies and TLS passthrough ingress controllers have all appeared on it.
2. The origin gap. The CDN or load balancer is post-quantum, the back-end leg is not. Google Cloud's default covers only the client-to-load-balancer leg, and AWS policies are opt-in per listener.
3. TLS inspection and re-origination. Every proxy, web application firewall and inspection appliance runs its own handshake. One classical leg is enough to expose the traffic.
4. Pinned group lists. Applications that set their own groups, such as Java's jdk.tls.namedGroups or Go's CurvePreferences, do not pick up new defaults. OpenSSL fixed a 2026 bug (CVE-2026-2673) in which server group configuration using the DEFAULT keyword did not behave as intended.
5. Temporary opt-outs left in place. Chrome's enterprise policy for disabling post-quantum key agreement was meant as a short-term workaround. Audit browser and endpoint policies.
6. TLS 1.2-only endpoints. Legacy appliances, payment and OT gateways and older load balancers cannot negotiate hybrid groups at all.
7. Supported but not enforced. A server that accepts both hybrid and classical-only handshakes still gives old clients classical sessions, and an active attacker may be able to force a downgrade. The end state is to remove classical-only options where you can.
8. Parameter mismatches. FIPS environments need a certified ML-KEM implementation, and some government profiles favour ML-KEM-1024 (SecP384r1MLKEM1024) over ML-KEM-768. Australian government systems should check the current ISM cryptography guidelines.

Evidencing post-quantum TLS for auditors and regulators

No framework in the region names X25519MLKEM768 yet. They do require cryptography that is appropriate to the threat and reviewed as the threat changes, which is the argument for acting now. Map the control to what you already report against:

A complete evidence pack for the control holds seven items:

1. a policy statement naming the approved hybrid groups and fallbacks;
2. an inventory of every TLS termination point, with owner and vendor;
3. a monthly metric: the share of external handshakes negotiating X25519MLKEM768, per service, from load balancer or CDN logs;
4. dated scan results for every public hostname;
5. an exceptions register for TLS 1.2-only and non-upgradable endpoints, each with a retirement date;
6. vendor attestations and roadmap dates;
7. change records showing that default group lists were not overridden.

Crypto-agility as a control, not a slogan

US National Security Memorandum 10 defines crypto-agility as the ability to update cryptographic algorithms and standards without modifying or replacing the surrounding infrastructure. Post-quantum TLS has already tested it twice. Chrome replaced the draft Kyber exchange with ML-KEM in a single release in late 2024, and RFC 10024 has now made the draft codepoints obsolete. Organisations whose libraries picked up the change automatically passed the test; those with hard-coded group lists did not.

A crypto agility framework that holds up in audit has four parts, which the June 2026 US federal memo also sets out: pluggable libraries such as OpenSSL 3 providers or Java's JCA; algorithm choice held in configuration rather than code; protocol negotiation that can be restricted to acceptable algorithms; and key management (KMS and HSM) that supports classical and post-quantum keys side by side. For the cryptographic register, Mosca risk scoring and programme KRIs, see post-quantum readiness as a GRC programme.

Post-quantum TLS in GRCLens

GRCLens holds TLS termination points as assets linked to your cryptography control and mapped across the frameworks you report against. Scan results and log metrics are attached as dated evidence, TLS 1.2-only and non-upgradable endpoints sit in an exceptions register with owners and retirement dates, and vendor commitments are tracked against the dates they promised. The share of post-quantum handshakes becomes a KRI on the board dashboard instead of a number someone assembles once a year.

Frequently asked questions

How Security Solution Consultants can help

Security Solution Consultants runs post-quantum TLS assessments for banks, insurers, government agencies and critical infrastructure operators across Australia, New Zealand, Asia and the Gulf. We test every public hostname, trace each termination point back to the origin, and build the evidence pack and exceptions register your auditors will ask for. See our security compliance services and the board briefing on harvest now, decrypt later. GRCLens then keeps the register, metrics and evidence current. Request a demonstration.