On 13 August 2024, the U.S. National Institute of Standards and Technology published its first finalized post-quantum cryptography standards: FIPS 203, FIPS 204, and FIPS 205. The announcement marks the end of an eight-year standardization process and the beginning of a much longer one — the migration of the world’s cryptographic infrastructure to algorithms believed to resist attack by a sufficiently large quantum computer. For organizations running workloads in the cloud, the standards are not an immediate operational emergency, but they are a clear signal to begin planning a transition that will take years and that, for some data, should arguably have started already.

Why Post-Quantum Cryptography Matters

The cryptography that secures most of today’s internet and cloud communications — the key-exchange and digital-signature algorithms underpinning TLS, SSH, code signing, and much else — relies for its security on mathematical problems that classical computers cannot solve efficiently: integer factorization and discrete logarithms. A sufficiently large, fault-tolerant quantum computer running Shor’s algorithm could solve those problems efficiently, breaking the public-key cryptography that the security of the internet currently rests on.

No such quantum computer exists today, and credible estimates of when one might place it years away at minimum. So why act now? Two reasons make the timeline more urgent than the absence of a quantum threat today would suggest.

The first is “harvest now, decrypt later.” An adversary can record encrypted data today and store it, decrypting it once a capable quantum computer becomes available. For data with a long confidentiality lifetime — state secrets, health records, intellectual property, anything that must stay secret for a decade or more — the relevant question is not “is there a quantum computer today” but “will there be one within the data’s required confidentiality lifetime.” For such data, the threat is effectively already present, because the harvesting can happen now.

The second is migration is slow. Replacing cryptographic algorithms across an organization’s entire estate — every protocol, every library, every embedded device, every certificate — is the work of years, not months. Cryptographic transitions historically take a long time, and they cannot be rushed at the end. Starting the planning when the standards are finalized, rather than when the threat materializes, is the only way to be ready in time.

What the Three Standards Are

The finalized standards cover the two functions that the public-key cryptography in question performs.

  • FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism), derived from the algorithm previously known as CRYSTALS-Kyber. This is the standard for key establishment — the function that lets two parties agree on a shared secret over an insecure channel, which is what TLS key exchange does. ML-KEM is the workhorse standard for protecting communications, and it is the one most cloud workloads will encounter first.
  • FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm), derived from CRYSTALS-Dilithium. This is the primary standard for digital signatures — authenticating identities and verifying integrity, as in certificates and code signing.
  • FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm), derived from SPHINCS+. This is a second signature standard based on a different mathematical foundation (hash functions rather than lattices), providing diversity: if a weakness were found in the lattice-based approach, a hash-based alternative is already standardized.

The choice of multiple algorithms and multiple mathematical foundations is deliberate. Standardizing on a single approach would create a systemic risk if that approach were later weakened; the portfolio provides resilience through diversity.

A Practical Migration Timeline

For an organization running cloud workloads, the transition can be approached in phases. The timeline below is a forward-looking planning framework, not a prediction of fixed dates.

Phase one — inventory and assessment (begin now). You cannot migrate cryptography you have not located. The first step is a cryptographic inventory: where is public-key cryptography used across your systems, in which protocols and libraries, protecting what data, with what confidentiality lifetime. This “crypto-agility” assessment is the foundation for everything that follows, and it has value independent of the quantum question, because it tells you how hard any future cryptographic change will be.

Phase two — prioritize by data lifetime. Not all data is equally exposed. Rank workloads by the confidentiality lifetime of the data they protect. Data that must stay secret for many years is the harvest-now-decrypt-later target and should migrate first. Short-lived data — session tokens, ephemeral state — is far less exposed and can wait.

Phase three — adopt hybrid approaches as they become available. The expected near-term deployment pattern is hybrid key exchange: combining a classical algorithm with a post-quantum one so that the connection is secure as long as either holds. Hybrid deployment hedges against both the quantum threat and the possibility of an undiscovered weakness in the new algorithms while they are young. Cloud providers and TLS libraries are expected to offer hybrid options, and adopting them as they appear is the low-risk way to begin real migration.

Phase four — full transition and classical retirement. Over the longer term, as the post-quantum algorithms mature and confidence in them grows, the classical algorithms will be deprecated and eventually retired. This is the multi-year tail of the migration, and its pacing will be set by standards bodies, providers, and accumulated deployment experience.

The Cloud Dimension

Most organizations will not implement these algorithms themselves. They will inherit them from the cloud providers, TLS libraries, and managed services they depend on. That has two practical consequences.

First, much of the migration will arrive as updates to the platforms and libraries you already use, rather than as a project you drive end to end. Cloud providers will roll out post-quantum and hybrid options in their load balancers, key-management services, and TLS termination over the coming period. Staying current with those offerings is a meaningful part of the migration for most organizations.

Second, the parts you do own — your own code-signing, your own use of cryptographic libraries, your embedded or specialized systems, your long-lived data at rest — are where your direct migration work lies. The inventory in phase one is what tells you where those are.

The Crypto-Agility Lesson

The deeper lesson of this transition, and the one worth internalizing regardless of the quantum timeline, is the value of crypto-agility — designing systems so that the cryptographic algorithms they use can be changed without re-architecting the system. Many systems in production today hard-code cryptographic choices in ways that make changing them difficult, which is precisely why cryptographic transitions take years. Organizations that emerge from this migration with crypto-agile architectures will find the next transition — and there will be one — far less painful.

Post-quantum migration is not an emergency to be handled this quarter. But it is a multi-year program whose first phase — knowing where your cryptography is and how long your data must stay secret — should begin now that the standards are final. The organizations that start planning while the threat is still over the horizon are the ones that will not be scrambling when it arrives.

Further Reading

Back to Blog