Read this first
RFC 10024, Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3, is now published on the IETF Standards Track. It defines three named groups: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024, combining ML-KEM (FIPS 203) with classical ECDHE so a session stays secure as long as either component holds. It supersedes the draft-ietf-tls-ecdhe-mlkem series and formalizes the concatenation-and-hash construction defined by RFC 9954, the same combiner Chrome and other major TLS stacks have already been shipping as a default since 2024.
An RFC number closed a gap this month that most TLS deployments had already been running ahead of for two years. Chrome negotiated a hybrid post-quantum key exchange by default starting in late 2024, well before the specification behind it had a document number anyone could cite in a procurement requirement or a compliance audit. RFC 10024 is that document. It takes the draft-ietf-tls-ecdhe-mlkem series through IESG approval and RFC Editor processing to a published standard, so "which spec does this claim to implement" now has an answer that does not start with the word draft.
What RFC 10024 locks in
The RFC defines three hybrid named groups for the TLS 1.3 handshake: X25519MLKEM768, pairing Curve25519 with ML-KEM-768; SecP256r1MLKEM768, pairing NIST P-256 with the same ML-KEM parameter set; and SecP384r1MLKEM1024, pairing P-384 with the larger ML-KEM-1024. Each combines its classical and post-quantum shared secrets through concatenation, fed into the ordinary TLS 1.3 key schedule that RFC 9954 already specifies, so the security of the combined result depends on that key schedule hashing the full handshake transcript rather than on any new combiner logic. The P-256 and P-384 variants order the ECDHE secret first, ahead of the ML-KEM secret, to keep the construction compatible with FIPS validation paths, a detail worth knowing if a conformance test ever compares byte-for-byte output against the X25519 variant.
This is deliberately conservative cryptographic engineering. RFC 10024 does not introduce a new combiner or a new proof; it standardizes the exact construction the TLS working group had already been iterating on in public since the first ecdhe-mlkem draft, and that quantakrypto has previously walked through in detail alongside the related but distinct X-Wing combiner. The value of the RFC is administrative as much as technical: a stable number, a Standards Track designation, and an end to pinning a moving draft revision in production configuration.
From default to standard
The sequence here is worth remembering because it is becoming the normal path for these transitions: ship a hybrid behind a draft, let deployment experience accumulate across browsers and libraries, then formalize the winning construction as an RFC once real-world use has stress-tested it. Browsers, OpenSSL, Go, and recent operating systems already default to X25519MLKEM768; RFC 10024 does not change that behavior, it gives the behavior a citable standard to point to. For anyone whose compliance or procurement language requires an RFC number rather than a draft reference, that is the practical unlock: X25519MLKEM768 moves from "what everyone is already running" to "what the standard says to run."
What this does not cover
RFC 10024 is scoped to key agreement in the TLS 1.3 handshake, and it is worth being precise about the edges of that scope. It says nothing about authentication: the certificate signatures that establish server and client identity are still classical RSA or ECDSA in almost every deployment, and post-quantum signatures there are a separate, slower-moving migration. It says nothing about anything past the TLS endpoint, so a hybrid handshake at the edge does not imply post-quantum protection for whatever happens to the data behind it. And because the constructions are hybrid rather than PQ-only, a session's confidentiality still depends on ECDHE holding as well as ML-KEM, which is the intended design, not a gap, but worth stating plainly.
The point
The point
RFC 10024 does not change what your TLS stack does today if it already defaults to X25519MLKEM768; it changes what you can cite when someone asks whether that default rests on a finished standard. The layers still waiting for the same treatment, certificate authentication and everything behind the handshake, are where the migration work actually remains.
If your own inventory cannot yet answer which of your TLS endpoints negotiate a hybrid group and which still fall back to classical-only key exchange, that gap is the more useful thing to close this week than reading the RFC text itself. A cryptographic inventory is what turns "the standard exists" into "we know where we stand against it."
References
- RFC 10024, Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3 (datatracker.ietf.org) - the published standard.
- RFC 9954, Hybrid Key Exchange in TLS 1.3 (rfc-editor.org) - the concatenation-and-key-schedule framework RFC 10024 instantiates.
- draft-ietf-tls-ecdhe-mlkem (datatracker.ietf.org) - the working-group draft series that became RFC 10024.
- NIST FIPS 203, ML-KEM (csrc.nist.gov) - the post-quantum half of every group RFC 10024 defines.
- quantakrypto: X-Wing and the TLS group - how the RFC 10024 combiner compares to the related X-Wing KEM.
- quantakrypto: how ML-KEM became the default in browsers - the deployment history RFC 10024 formalizes.