The cryptography underpinning nearly every secure connection on the internet is on a schedule to retire, and the schedule, while still a proposal, is specific enough that organizations can no longer treat it as a distant problem. NIST finalized ML-KEM in FIPS 203 on August 13, 2024, alongside two signature standards, FIPS 204 and FIPS 205. A draft timeline, NIST IR 8547, would push RSA and elliptic-curve cryptography into deprecated status after 2030 and disallow them after 2035. That draft dates from November 2024, has not been finalized since, and should be read as a planning signal rather than a settled deadline.
What Is Final and What Is Still a Draft
The distinction matters more than it might seem. FIPS 203, 204 and 205 are finished, published standards that organizations can implement today. ML-KEM comes in three parameter sets - ML-KEM-512, ML-KEM-768 and ML-KEM-1024 - and current migration guidance points toward the larger two for most serious use. NIST IR 8547, by contrast, remains an initial public draft. Treating its 2030 and 2035 dates as binding rules overstates what NIST has actually committed to. A second algorithm, HQC, is meant to serve as a backup built on different mathematical foundations, but it is not expected to become a final standard until 2027. It complements ML-KEM; it does not replace it.
Standards work beyond NIST is moving, too, though unevenly. RFC 9935, published in March 2026, gives certificates a way to carry ML-KEM keys. Other efforts - covering TLS, IKEv2, JOSE and the CMS message format - remain drafts under review. Software libraries have outpaced the paperwork: ML-KEM is already deployable through OpenSSL 3.5 and later, Go 1.24 and later, BoringSSL and rustls, which means the technical capability to adopt post-quantum key exchange already exists well ahead of any formal mandate.
Why Key Exchange Cannot Wait
The urgency around key exchange specifically, rather than signatures, comes down to a simple asymmetry. An adversary who records encrypted traffic today can attempt to decrypt it years later once quantum computing matures - a strategy often described as harvest-now-decrypt-later. A forged signature, by comparison, only has value while it can be used in real time. That difference is why migration plans across the industry prioritize key establishment first, even though RSA and elliptic-curve cryptography remain unbroken by any existing machine.
RSA and ECC are not failing today. The concern is entirely about the future value of data intercepted now. That framing also explains why legacy RSA key-exchange modes, already fading from TLS for unrelated reasons, are drawing fresh scrutiny. A JOSE draft updated in October 2026 proposes deprecating the older RSA1_5 algorithm for new deployments, separate from any quantum consideration - a reminder that classical cryptography is being squeezed from more than one direction at once.
Three Paths, No Single Answer
Organizations currently face three distinct rollout strategies rather than one obvious choice.
- Hybrid key exchange pairs ML-KEM with a classical algorithm such as X25519. The combination X25519MLKEM768 is the most widely discussed pattern, and an attacker must break both halves to succeed. It fits into existing TLS 1.3 handshakes and is already appearing as a default in some cloud infrastructure, reportedly including Google Cloud load balancers from October 2026. The cost is larger handshake messages and the continued maintenance of two algorithms.
- Pure ML-KEM drops the classical component entirely, relying solely on the lattice-based assumption behind FIPS 203. An IETF draft defining pure ML-KEM TLS groups entered last call in mid-2026 but has not been published as a finished RFC. Supporters favor its simplicity; critics point out that ML-KEM is young compared with decades-old elliptic-curve cryptography, and that NIST's own guidance still recommends pairing it with a classical mechanism in many deployments.
- Composite ML-KEM attaches a lattice-based key to existing classical primitives - RSA-OAEP, ECDH, X25519 or X448 - inside certificate and message formats, preserving a classical anchor while adding quantum resistance. This path suits environments where certificate infrastructure is harder to change quickly.
Each path trades simplicity against caution differently, and none is officially mandated over the others.
A Caution Against Overconfidence
Recent events argue for patience rather than haste. HAWK, a lattice-based signature candidate once under consideration, was withdrawn in July 2026 after a flaw surfaced. NIST was clear that the issue does not touch ML-KEM or ML-DSA, which rest on different mathematical structures, but the episode illustrates that even vetted lattice designs can fail unexpectedly. Separately, researchers reportedly traced the random seeds behind standard elliptic-curve parameters to ordinary 1990s-era generation methods - a transparency finding, not evidence of a backdoor, but another argument for retiring classical curves on a measured schedule rather than all at once.
For now, the practical answer for most organizations is to begin with hybrid key exchange, where tooling is mature and fallback protects against both classical and quantum failure modes, while tracking the composite and pure-ML-KEM drafts as they move through IETF review. The 2030 and 2035 dates in NIST IR 8547 may yet shift, but the underlying math problem they describe will not.