RFC 10024 Finalizes Hybrid Post-Quantum TLS — The Standard the Internet Was Already Running

10 Aug 2026 – The Internet Engineering Task Force published RFC 10024 in August 2026, defining three hybrid key agreement mechanisms for TLS 1.3 that pair ML-KEM with classical elliptic curve Diffie–Hellman.

The three mechanisms are X25519MLKEM768, which combines X25519 with ML-KEM-768; SecP256r1MLKEM768, which combines the NIST P-256 curve with ML-KEM-768; and SecP384r1MLKEM1024, which combines P-384 with ML-KEM-1024. The RFC is a Proposed Standard on the IETF standards track.

The IANA TLS Supported Groups registry entries read as follows:

Only X25519MLKEM768 is Recommended Y – the group browsers and CDNs already negotiate by default. The two NIST-curve hybrids are Recommended N, reflecting insufficient IETF consensus for general recommendation, not a cryptographic flaw. The NIST-curve code points exist for environments whose compliance frameworks require named NIST curves rather than X25519.

The authors are Kris Kwiatkowski of PQShield, Panos Kampanakis of AWS, Bas Westerbaan of Cloudflare, and Douglas Stebila of the University of Waterloo. The nine-page RFC evolved from draft-ietf-tls-ecdhe-mlkem. Stebila also co-authored RFC 9954 (July 2026), the Informational RFC that defines the general hybrid key exchange construction RFC 10024 instantiates.

RFC 10024 obsoletes the experimental code points that browsers and CDNs had been using in production. IANA relabeled X25519Kyber768Draft00 (0x6399 / 25497) and SecP256r1Kyber768Draft00 (0x639A / 25498) with the comment “Pre-standards version of Kyber768. Obsoleted by RFC 10024” and set both to Recommended D (discouraged). Clients running older builds may still offer the discouraged code points; the RFC states that servers SHOULD prefer the standardized groups.

The RFC references NIST FIPS 203 (ML-KEM, finalized August 2024) for the post-quantum component and RFC 9846 (the updated TLS 1.3 specification, July 2026) for the protocol framework.

My Analysis

X25519MLKEM768 has been the default key exchange in Chrome since version 131 (November 2024) and in Firefox since version 132 (October 29, 2024 – Firefox shipped it days before Chrome). Its pre-standard predecessor, X25519Kyber768Draft00, ran in Chrome from April 2024 and on Cloudflare’s edge from late 2022. Apple added X25519MLKEM768 across iOS 26 and macOS Tahoe. By October 2025, Cloudflare reported that the majority of human-initiated TLS traffic to its network was negotiating a hybrid post-quantum key exchange. By April 2026, that figure exceeded two-thirds.

RFC 10024 adds no bytes to those connections – it supplies the standards-track citation that compliance processes required before approving the hybrid.

RFC 10024 Closes the Standards Gap

Security teams that evaluated hybrid post-quantum TLS over the past two years heard the same objection: “it’s still a draft.” The hybrid code points were experimental. The IETF had not published a final standard. Teams whose risk process would not accept an experimental code point had a procedural basis for delay, even as Chrome, Firefox, and Cloudflare ran the protocol on billions of connections daily.

That basis is gone. RFC 10024 is a Proposed Standard on the IETF standards track. X25519MLKEM768 is Recommended Y in the IANA registry. The pre-standard Kyber768 code points are formally discouraged. For any organization whose PQC migration was stalled on a standards-gap rationale, the gap closed in August.

Deploy First, Standardize Later

The deployment timeline for hybrid PQC key exchange inverted the usual standards sequence. Cloudflare supported hybrid KEMs on its edge from 2022, first with X25519Kyber768Draft00, then replaced it with X25519MLKEM768 after BoringSSL and AWS-LC adopted the final ML-KEM algorithm from FIPS 203. Google shipped the hybrid in Chrome before the IETF had even adopted the draft as a working group document. The standard followed the deployment.

That inversion was deliberate, and the threat model justified it. The harvest-now-decrypt-later (HNDL) threat makes key exchange uniquely time-sensitive: every month of classical-only key exchange on data with a long confidentiality requirement extends the window an adversary can exploit once a CRQC arrives. The hybrid construction preserved classical security guarantees while adding post-quantum protection – an attacker must break both components to recover the session key, and the marginal cost was roughly a kilobyte of additional handshake data. Waiting two more years for the IETF’s publication process would have added two more years of exposed traffic to the archive.

The origin-side picture is catching up. Cloudflare’s Automatic Key Exchange feature, announced September 8, 2026, probes origin servers to detect their key agreement support and selects X25519MLKEM768 where the origin can negotiate it. Before the feature, the scanned cohort averaged roughly 25 billion daily hybrid connections at the origin layer; afterward, roughly 45 billion. About 33 percent of scanned domains were assigned an X25519MLKEM768 preference; over 12 percent of individual origins support post-quantum key exchange. Of the post-quantum origin TLS 1.3 connections in that cohort, 99.2 percent now complete without a HelloRetryRequest – up from zero before the feature launched. These are origin-side numbers; browser-to-CDN adoption is higher and driven by browser defaults. QUIC inherits TLS 1.3’s key exchange mechanics, so HTTP/3 connections gain the same post-quantum protection.

Federal Deadlines Were Already Set

The significance of RFC 10024 extends beyond protocol engineering. Executive Order 14412 (June 22, 2026) requires federal civilian agencies to migrate high-value assets and high-impact systems to PQC key establishment by December 31, 2030 and to PQC digital signatures by December 31, 2031. The order directed a proposed FAR rule that would extend PQC requirements – broadly, compliance with NIST FIPS incorporating PQC algorithms – to covered federal contractors by 2030. OMB Memorandum M-26-15 identifies TLS 1.3 as the foundation for deploying PQC at the network level and sets a January 2, 2030 TLS 1.3 support deadline for all agencies.

For organizations building migration plans around TLS key exchange, RFC 10024 is the specification to cite – alongside evidence of the specific implementation, its validation status, and the applicable deployment policy. X25519MLKEM768 is what the browser-facing internet already negotiates, what the major TLS libraries ship, and what the IANA registry marks as Recommended. The RFC notes that the hybrid can be implemented in a FIPS-approved manner, with ML-KEM certification relevant to that construction.

CNSA 2.0 introduces a separate requirement. NSA’s suite specifies ML-KEM-1024 for national security systems and does not require a hybrid classical component as an end-state, though transitional CNSA guidance discusses hybrid configurations. That target is the use case draft-ietf-tls-mlkem addresses. I covered the three Working Group Last Calls and the sustained objections in my July analysis; since then, the IESG approved the draft on September 3 and it entered the RFC Editor queue on September 8, destined for publication as an Informational RFC. The IANA registry still signals the IETF’s position: hybrid is Recommended Y; standalone ML-KEM is Recommended N.

What RFC 10024 Does Not Fix

Hybrid key exchange for TLS 1.3 is now a published standard with internet-scale deployment, but post-quantum authentication for TLS 1.3 has no equivalent RFC, no browser default, and no root-CA infrastructure. RFC 10024 does not change that.

When a Chrome user loads a site over X25519MLKEM768, the session key is protected against recorded-traffic decryption by a future quantum computer. The server certificate that authenticated the handshake is still signed with ECDSA or RSA. No major browser negotiates ML-DSA for server certificates by default, and no public root CA has issued an ML-DSA root that the major trust stores accept. The CA/Browser Forum’s Server Certificate Working Group has an ML-DSA ballot in progress but no merged baseline requirement permitting ML-DSA in publicly trusted TLS certificates.

Authentication faces a different and less immediate quantum threat than key exchange. HNDL targets key exchange: traffic encrypted under a classical-only key exchange today stays decryptable forever once a CRQC exists. A quantum-capable adversary exploiting classical authentication would need to mount an active, real-time impersonation attack on a future connection – a different and harder threat to execute. So the current state, quantum-resistant key exchange with classical-only authentication, addresses the most immediate risk.

ML-DSA standardization for TLS advanced in September 2026, but certificate infrastructure has no comparable timeline. The IESG had held publication of draft-ietf-tls-mldsa following an appeal earlier this year, then approved it in September 2026 for publication as an Informational RFC. That clears the standards path, but the deployment work remains: certificate infrastructure moves slowly, hybrid cryptography for signatures is more contested than it was for key exchange, and root CAs and the CA/Browser Forum operate on their own schedule. Organizations that control both endpoints and their trust infrastructure – private PKI environments – can experiment now; rustls 0.23.44, released September 7, enables ML-DSA certificate verification by default for exactly that scenario. The public WebPKI is a longer wait.

The Bottom Line

RFC 10024 formalizes a deployment that browsers and CDNs completed while the standard was still a draft, because the HNDL risk was more immediate than the standardization risk.

For security teams, the actionable consequence is direct. If your organization’s TLS-terminating infrastructure does not yet negotiate X25519MLKEM768, it is running behind what every major browser offers by default. The server-side requirement is a current TLS library: OpenSSL 3.5 or later, BoringSSL, AWS-LC, Go 1.24, or rustls 0.23.27 or later all support the hybrid group. Test your endpoint:

openssl s_client -connect yourhost.example:443 -servername yourhost.example -tls1_3 -groups X25519MLKEM768

Verify the handshake completes and the negotiated group shows X25519MLKEM768. A failure may indicate a library version, a middlebox in the path, or an explicit curve-list configuration that excludes the hybrid – all fixable, none exotic.

If your PQC migration planning was waiting on a final standard for hybrid TLS key exchange, the wait ended in August. The standard now documents what the deployment built.