IETF Publishes Hybrid ML-KEM Key Agreement for TLS 1.3
RFC 10024 specifies three combinations of ML-KEM and elliptic-curve key agreement at Proposed Standard maturity.

A common specification for connections
Implementers of TLS 1.3 have a common specification for combining ML-KEM with existing elliptic-curve key agreement. RFC 10024 gives interoperability and migration work a shared target. IETF history records publication on August 10. The Standards Track RFC has Proposed Standard maturity.[1]
The specification defines three combinations: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024.[1]
Proposed Standard describes the specification's maturity, not the extent of adoption. Publication does not mean every browser, server or certificate system has migrated.[1]
Implementations still need interoperability testing and measured rollout. These changes concern key agreement; migrating signatures is separate work that operators need to distinguish from this update.[1]
October 15 update: guidance for deployment
The UK's NCSC now recommends configurations for both hybrid and pure post-quantum key exchange in TLS. Its October 15 guidance treats hybrid schemes as an interim migration measure and says TLS 1.3 is the version to move to: earlier TLS versions will not gain PQC support. Enabling TLS 1.3 alone does not establish which key exchange a connection negotiated.[2][3]
The guidance also separates key exchange from authentication. Work on post-quantum authentication in TLS and the public certificate ecosystem is still progressing. For readers, the useful question is therefore specific: did an upgrade protect the session's shared secret, its authentication, or both? A general claim of quantum safety should identify that boundary.[3]