The math that protects nearly every encrypted connection online today has a known weakness, and the fix is already finalized. NIST locked in ML-KEM, the first widely adopted post-quantum key-encapsulation standard, as FIPS 203 on August 13, 2024. A companion draft, NIST IR 8547, proposes phasing out RSA and elliptic-curve cryptography after 2030 and disallowing them entirely after 2035. That draft is not settled policy, but the decision facing engineering teams is no longer whether to adopt quantum-resistant encryption - it is which of three rollout paths to take first.
What Is Final, and What Is Still a Proposal
Three NIST standards are done and citable: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA) and FIPS 205 (SLH-DSA), all published August 13, 2024. ML-KEM comes in three strengths - ML-KEM-512, ML-KEM-768 and ML-KEM-1024 - and current migration guidance points organizations toward the 768 or 1024 variants. The IETF has moved too: RFC 9935, from March 2026, lets X.509 certificates carry ML-KEM keys, giving public-key infrastructure a path to adopt the new math.
Much else remains in draft. NIST IR 8547's 2030/2035 timeline has not been finalized since its November 2024 draft. HQC, the backup algorithm meant to rest on different mathematical ground than ML-KEM, is not expected to become a final standard until 2027. Several IETF drafts covering TLS, IKEv2, JOSE and CMS integration are still in review. Treat headlines that state RSA will be banned in 2035 as reporting on a proposal, not a rule already in force.
Why Key Exchange Cannot Wait, Even Though RSA Still Works
No quantum computer today can break RSA or elliptic-curve cryptography. The urgency comes from a different threat: encrypted traffic captured now can be stored and decrypted later, once a sufficiently powerful quantum machine exists capable of running Shor's algorithm against the factoring and discrete-logarithm problems both schemes depend on. That makes key exchange - the part of a connection that establishes a shared secret - the priority, since a recorded session decrypted years from now is a permanent loss. A forged signature, by contrast, only matters while it can be used live, which is why signature algorithms are moving on a slower track.
Classical cryptography is also under separate, unrelated pressure. Researchers this year reportedly traced the random seeds behind NIST's elliptic-curve parameters to ordinary pseudorandom generation from the late 1990s - a transparency finding, not evidence of a backdoor, and not a break of commonly deployed curves. It adds to the case for an orderly transition rather than a sudden one.
Three Paths: Hybrid, Pure, and Composite
Hybrid key exchange runs a classical and a post-quantum algorithm together, commonly pairing X25519 with ML-KEM-768. If either algorithm is ever broken, the other still protects the session. This is the path most organizations are taking first, since it fits into existing TLS 1.3 handshakes and falls back gracefully for clients that do not yet support it. Cloud providers are reportedly beginning to enable hybrid groups by default, which means many services will adopt this path without any configuration change at all. The tradeoff is overhead: larger handshake messages, two code paths to maintain, and a reliance on X25519 that is not actually removed.
Pure ML-KEM drops the classical half entirely, resting confidentiality solely on the lattice problem behind FIPS 203. An IETF draft defining ML-KEM-only TLS groups entered last call in mid-2026 but remains unpublished as a final RFC. The appeal is simplicity for constrained devices or environments that want one approved algorithm. The risk is that ML-KEM is young compared with decades-old elliptic-curve cryptanalysis, and NIST's own guidance still recommends pairing it with an established classical mechanism in many deployments. A related lattice-based signature candidate, HAWK, was withdrawn from consideration in mid-2026 after a flaw was found - a reminder that newer schemes can still fail, even though NIST says the issue does not touch ML-KEM or ML-DSA.
Composite ML-KEM takes a middle route, attaching a lattice key to RSA-OAEP, ECDH, X25519 or X448 inside existing certificate and message formats. It keeps a classical anchor for systems like signed email or Kerberos that cannot easily be rebuilt around a new handshake shape, at the cost of carrying both algorithms indefinitely in formats not designed for them.
What Teams Should Weigh Before Choosing
No single path suits every system. Public-facing web servers can often absorb hybrid's larger handshakes with little friction. Constrained hardware may struggle with the overhead of carrying two algorithms. Legacy formats such as signed messaging or smart-card authentication may only have room for a composite approach that preserves backward compatibility.
- Hybrid (X25519 + ML-KEM-768): best for TLS where compatibility and fallback matter most
- Pure ML-KEM: suited to constrained devices and single-algorithm policy environments, but still awaiting finalized IETF standards
- Composite ML-KEM: fits certificate- and message-based systems that cannot abandon their classical format
What unites all three paths is the calendar behind them. Even as a proposal, NIST IR 8547 has already shaped procurement and migration planning across the industry. Whether the 2030 and 2035 dates survive final review or shift, the underlying math problem - that today's encrypted data may not stay confidential forever - does not wait for a published rule to become true.
