The Internet Engineering Task Force has converted an important part of post-quantum TLS from evolving implementation practice into a published technical specification. For security teams, that does not mean every TLS service is suddenly quantum-ready. It means inventories and migration plans can become much more precise.
RFC 10024, “Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3,” was published in August 2026. It defines three named TLS groups that combine ML-KEM with a traditional elliptic-curve mechanism: X25519MLKEM768, SecP256r1MLKEM768, and SecP384r1MLKEM1024.
The practical change is not merely that hybrid key agreement exists. The RFC gives implementations shared identifiers, wire formats, validation behavior, and security requirements. It also marks earlier experimental Kyber-based TLS groups as obsolete.
A standardized name improves inventory quality
Cryptographic inventories often record a connection as “TLS 1.3” or “PQC enabled.” Neither description is sufficiently specific for migration governance.
TLS 1.3 can negotiate traditional key agreement, a hybrid group, or—depending on future standards and implementations—another mechanism. A server can support several groups while an individual connection negotiates only one. A product may contain pre-standard experimental code while its current release supports the final standardized identifier.
RFC 10024 gives teams exact values to record. An observation can now distinguish X25519MLKEM768 from SecP256r1MLKEM768, rather than collapsing both into a generic “hybrid PQC” label.
That distinction matters in regulated environments. The RFC explains that the ordering of component secrets affects which implementation must be certified in certain FIPS-oriented uses. X25519MLKEM768 and the NIST-curve combinations do not have identical validation implications.
A useful inventory should therefore capture:
- The TLS version supported and negotiated
- The exact named group supported and negotiated
- The endpoint, client, proxy, gateway, or CDN involved
- The cryptographic library and version
- The implementation or module validation status where relevant
- The certificate and signature algorithms used for authentication
- The source and time of the observation
This turns an abstract readiness claim into evidence that can be evaluated and acted upon.
Draft-era identifiers need explicit retirement
RFC 10024 obsoletes two experimental supported groups based on a pre-standard version of Kyber. That is an operational migration issue hiding inside a standards update.
Organizations that participated in early trials may still have draft implementations in browsers, gateways, test environments, libraries, appliances, or custom configurations. Those deployments should not be assumed to disappear simply because a final RFC exists.
Teams should search configuration repositories, software inventories, packet observations, vendor documentation, and test environments for obsolete draft identifiers. The result should distinguish code that is merely present from a mechanism that is enabled or actually negotiated.
Removal also needs evidence. A configuration change may disable an obsolete group on one listener while leaving another termination point unchanged. A CDN or service mesh can conceal the actual TLS boundary from the application owner. Verification should observe representative traffic through the real path.
Larger handshakes are an engineering constraint
The hybrid groups defined by RFC 10024 exchange significantly larger key shares than traditional elliptic-curve mechanisms alone. For example, the X25519MLKEM768 client share is 1,216 bytes and its server share is 1,120 bytes.
Those sizes are not a reason to avoid migration, but they are a reason to test it. Network devices, middleboxes, constrained links, custom protocol parsers, and monitoring systems may behave differently when handshake messages grow.
A rollout plan should test latency, fragmentation, loss, retry behavior, connection establishment, observability, and failure handling. It should include older clients and unusual network paths, not only a current browser connected directly to a modern server.
The RFC also emphasizes input validation, failure behavior, random-number generation, and side-channel resistance. A named group is a specification, not proof that every implementation or deployment is secure.
Key agreement is only one part of TLS
RFC 10024 addresses hybrid key agreement. It does not make certificate signatures post-quantum, replace public-key infrastructure, or prove that every participating component is ready for migration.
A complete TLS record must keep key establishment separate from authentication. Otherwise, an organization may see ML-KEM in a connection and incorrectly conclude that the entire trust path is quantum-resistant.
The appropriate status may be: hybrid key agreement observed; classical certificate authentication remains; client coverage incomplete; interoperability testing ongoing.
That language is more accurate than a single readiness badge and gives owners a clear next action.
What teams should do now
First, update discovery and inventory schemas to represent the final RFC 10024 group names and the obsolete experimental identifiers. Second, identify where TLS terminates across servers, proxies, gateways, service meshes, and external providers. Third, compare capability with observed negotiation using representative clients.
Then test the larger handshakes and failure paths in realistic environments. Record certificate and signature state separately. Where validation requirements apply, connect the negotiated group to the exact cryptographic module and its evidence.
Finally, create accountable work for retiring experimental identifiers and verifying that the final configuration is observed in production.
How Vista Platform can help
Vista Platform is a self-hosted cryptographic system of record built around discovery, canonical inventory, evaluation, action, and proof.
Vista can reconcile evidence from connected discovery channels into durable records, evaluate cryptographic and PQC state, organize findings into accountable work, and generate scoped CBOM evidence. This helps teams keep the exact mechanism, affected asset, observation source, and migration decision connected.
Vista does not generate PQC keys or perform every migration. It is not a vulnerability scanner, and a discovery gap is not treated as proof that an obsolete or quantum-vulnerable mechanism is absent. More detail is available in Vista’s post-quantum overview.
RFC 10024 is a meaningful milestone because it gives engineering teams a stable vocabulary and interoperable target. The next challenge is operational: determine where the new groups are supported, where they are negotiated, where experimental predecessors remain, and what evidence proves the transition.
Sources
- RFC 10024: Post-Quantum Traditional (PQ/T) Hybrid Key Agreement Mechanisms for TLS 1.3, RFC Editor/IETF, August 2026.
- FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism Standard, NIST, August 2024.
- SP 800-227: Recommendations for Key-Encapsulation Mechanisms, NIST, September 2025.