If a large enough quantum computer can one day run Shor’s algorithm against today’s public-key cryptography, the practical question is simple: what should replace the old locks? The answer is not a single product, a vendor bundle, or a secret government design. In August 2024, the United States National Institute of Standards and Technology, usually called NIST, published the first three finished post-quantum cryptography standards after an eight-year public selection process. They are Federal Information Processing Standard 203 for ML-KEM, Federal Information Processing Standard 204 for ML-DSA, and Federal Information Processing Standard 205 for SLH-DSA.

Why NIST chose in public

Good cryptography is not trusted because its designers sound confident. It is trusted because many skilled people have tried to break it and failed. That is why NIST began an open post-quantum cryptography process in 2016 instead of simply naming a preferred algorithm behind closed doors.

Researchers and teams from around the world submitted candidate algorithms. Over the following years, cryptographers studied the designs, implemented them, measured them, attacked them, and published what they found. Some candidates that once looked promising were broken or weakened. That was not a failure of the process. It was the process doing its job.

This matters for buyers and architects because a standard is not the same thing as a product. The algorithms are public specifications. Vendors may implement them in libraries, hardware security modules, browsers, operating systems, cloud services, identity systems, and network appliances, but the underlying designs are open for anyone to inspect.

📌
Not a product category. Post-quantum standards are public algorithms; products are the implementations and services that use them.

Three standards, two jobs

The first finished NIST standards cover the two main public-key jobs that matter for most systems: agreeing on secrets and proving signatures.

Federal Information Processing Standard 203 defines ML-KEM, the Module-Lattice-Based Key-Encapsulation Mechanism. Its job is key establishment: helping two parties derive a shared secret even though their conversation crosses an untrusted network.

Federal Information Processing Standard 204 defines ML-DSA, the Module-Lattice-Based Digital Signature Algorithm. Its job is digital signatures: proving that a certificate, software update, document, token, or message was signed by the holder of a private signing key.

Federal Information Processing Standard 205 defines SLH-DSA, the Stateless Hash-Based Digital Signature Algorithm. It is also a digital signature standard, but it is built on a very different foundation from ML-DSA.

  • ML-KEM protects confidentiality by helping create shared secrets for encryption.
  • ML-DSA protects authenticity by providing efficient post-quantum digital signatures.
  • SLH-DSA also protects authenticity, but with a hash-based design that gives mathematical diversity.
NIST's first standards cover key establishment and two signature schemes.Three StandardsNIST PQCML-KEMFIPS 203, key exchangeML-DSAFIPS 204, signaturesSLH-DSAFIPS 205, hash-based
NIST's first standards cover key establishment and two signature schemes.

Why ML-KEM is the most urgent

ML-KEM addresses the part of public-key cryptography most exposed to harvest-now-decrypt-later risk. In that attack, an adversary records encrypted traffic today, stores it, and waits for a future quantum computer that can recover the old session secrets.

This is why key establishment comes first in many migration plans. If the protected data must remain confidential for many years, the damage can begin before a quantum computer exists. The attacker does not need to decrypt the traffic today. They only need to capture it today.

ML-KEM is not a drop-in copy of Diffie-Hellman. Diffie-Hellman and Elliptic-Curve Diffie-Hellman, abbreviated ECDH, let two parties interactively agree on a shared secret. ML-KEM is a key-encapsulation mechanism: one side produces a public key, the other encapsulates a fresh secret to that public key, and the holder of the private key decapsulates it. Protocols such as Transport Layer Security, abbreviated TLS, can use that result to derive encryption keys.

In practice, many deployments will use hybrid key establishment during the transition, combining a classical method such as ECDH with ML-KEM. The goal is to avoid betting everything on either the old algorithm or the new one while implementations, certification, interoperability, and operational experience mature.

⚠️
Confidentiality has a long shadow. If data must stay secret for ten or twenty years, waiting for 2035 may already be too late.
One side publishes a key, the other encapsulates a secret, and the owner decapsulates it.KEM HandshakeSend public keyEncapsulate secretDecapsulate secret
One side publishes a key, the other encapsulates a secret, and the owner decapsulates it.

Why there are two signature standards

Digital signatures solve a different problem from encryption. They do not hide a message. They help others verify who signed it and whether it changed after signing. Public-key infrastructure, abbreviated PKI, depends on signatures for certificates. Software distribution depends on signatures for updates and packages. Identity systems depend on signatures for tokens, assertions, and device credentials.

ML-DSA is the everyday post-quantum signature workhorse in the first NIST set. Like ML-KEM, it is based on structured lattices, a family of mathematical problems that currently offers good performance and practical key and signature sizes compared with many alternatives.

SLH-DSA exists for a different reason. It is hash-based. Hash functions are among the most studied building blocks in modern cryptography, and SLH-DSA does not rely on the same lattice assumptions as ML-DSA. The trade-off is cost: SLH-DSA signatures are much larger and signing can be slower, so it is not usually the first choice for every high-volume use case.

That second signature standard is deliberate risk management. If a surprising weakness were ever found in structured lattice assumptions, a hash-based signature scheme would not fail for the same reason. This is called cryptographic diversity: avoiding a single mathematical point of failure.

ML-DSA is the fast lattice workhorse; SLH-DSA is a conservative hash-based alternative.Two SignaturesML-DSASLH-DSALattice basedHash basedFast and smallVery conservativeEveryday useLong-lived trust
ML-DSA is the fast lattice workhorse; SLH-DSA is a conservative hash-based alternative.

The names are confusing, but manageable

Many documents written before standardization use the competition names rather than the final NIST names. CRYSTALS-Kyber became ML-KEM. CRYSTALS-Dilithium became ML-DSA. SPHINCS+ became SLH-DSA. In most planning conversations, those pairs refer to the same families of algorithms, with the standardized names now preferred for formal use.

The standards also define parameter sets. A parameter set is a specific size and strength choice within an algorithm family. For example, ML-KEM has ML-KEM-512, ML-KEM-768, and ML-KEM-1024. Larger parameter sets are designed for higher security strength, but they also tend to require more bandwidth, memory, or processing.

This means quantum-safe migration is not only a yes-or-no decision. Architects must choose algorithm families, parameter sets, protocol profiles, library versions, validation requirements, and fallback behavior. A system can claim post-quantum support and still be unsuitable if it uses the wrong mode, lacks interoperability, or cannot be operated safely at scale.

  • Old name CRYSTALS-Kyber maps to final name ML-KEM in Federal Information Processing Standard 203.
  • Old name CRYSTALS-Dilithium maps to final name ML-DSA in Federal Information Processing Standard 204.
  • Old name SPHINCS+ maps to final name SLH-DSA in Federal Information Processing Standard 205.
  • Parameter sets such as ML-KEM-768 and ML-DSA-65 are strength and performance choices, not separate product brands.

The migration clock has already started

NIST also published draft Internal Report 8547, a transition plan for moving federal systems away from vulnerable public-key algorithms. The headline direction is clear: algorithms such as Rivest-Shamir-Adleman, abbreviated RSA, finite-field Diffie-Hellman, ECDH, and the Elliptic Curve Digital Signature Algorithm, abbreviated ECDSA, are expected to be deprecated around 2030 and disallowed after 2035 for federal use.

Deprecated does not mean broken on that date. It means discouraged and allowed only with justification. Disallowed is stronger: it means the algorithm should no longer be used for the covered purpose in covered systems.

Those dates should not be read as a comfortable finish line. A large organization may need years to discover where cryptography is used, upgrade protocols, replace certificates, test suppliers, update hardware, handle embedded systems, and change policy. The real deadline depends on the lifetime of the data plus the time needed to migrate.

Other guidance points in the same direction. The National Security Agency, abbreviated NSA, has its Commercial National Security Algorithm Suite 2.0, often called CNSA 2.0, for national-security systems. It selects strong post-quantum and symmetric cryptography choices, including Advanced Encryption Standard 256-bit keys, abbreviated AES-256, and Secure Hash Algorithm 384-bit output, abbreviated SHA-384, alongside post-quantum algorithms.

⚠️
2035 is not the planning date. For long-lived confidential data, the practical migration deadline can be years earlier than the formal disallow date.
Vulnerable algorithms move from in use to deprecated around 2030 and disallowed after 2035.Migration ClockIn usetodayDeprecatedaround 2030Disallowedafter 2035Now2035+
Vulnerable algorithms move from in use to deprecated around 2030 and disallowed after 2035.

What leaders and practitioners must decide

The standards answer the algorithm question, but they do not automatically migrate an enterprise. A chief information security officer, platform owner, network engineer, identity architect, or product team still has to decide where to act first and how to reduce risk without breaking systems.

The first practical move is cryptographic discovery. Organizations need an inventory of where RSA, ECDSA, ECDH, and Diffie-Hellman appear: certificates, TLS configurations, virtual private networks, secure shell, code-signing pipelines, mobile applications, firmware updates, databases, backups, message queues, hardware devices, and partner connections.

The second move is classification. Not every system has the same urgency. A public marketing site and a database containing medical records with a twenty-year confidentiality requirement do not face the same harvest-now-decrypt-later risk. Likewise, a code-signing root key used to trust software for a decade deserves different treatment from a short-lived test certificate.

The third move is crypto-agility. Systems should be able to change algorithms, parameter sets, certificates, and libraries without a full redesign. Post-quantum migration will involve standards, certification programs, protocol updates, and vendor implementations that mature over time. Agility is the engineering discipline that keeps that change manageable.

  1. Inventory cryptography before buying replacements.
  2. Prioritize systems with long confidentiality lifetimes or high signing trust.
  3. Test hybrid key establishment where supported by protocols and vendors.
  4. Plan certificate, key-management, hardware, and compliance impacts together.
  5. Require suppliers to state which NIST standards, parameter sets, and validation paths they support.

Key takeaways

  • NIST published the first three finished post-quantum cryptography standards in August 2024 after an eight-year public process.
  • Federal Information Processing Standard 203 defines ML-KEM for key establishment and confidentiality.
  • Federal Information Processing Standards 204 and 205 define ML-DSA and SLH-DSA for digital signatures and authenticity.
  • SLH-DSA is slower and larger than ML-DSA, but it provides hash-based cryptographic diversity.
  • Draft NIST Internal Report 8547 points toward deprecating vulnerable public-key algorithms around 2030 and disallowing them after 2035 for federal systems.
  • The practical deadline depends on data lifetime and migration time, so discovery and planning should start now.

Glossary

NIST
The United States National Institute of Standards and Technology, the standards body that ran the post-quantum cryptography selection process.
PQC
Post-quantum cryptography, meaning cryptographic algorithms designed to resist attacks by both classical and quantum computers.
FIPS
Federal Information Processing Standard, a formal United States government standard for information processing and security requirements.
ML-KEM
The Module-Lattice-Based Key-Encapsulation Mechanism standardized in FIPS 203 for post-quantum key establishment.
ML-DSA
The Module-Lattice-Based Digital Signature Algorithm standardized in FIPS 204 for post-quantum digital signatures.
SLH-DSA
The Stateless Hash-Based Digital Signature Algorithm standardized in FIPS 205 as a hash-based post-quantum signature scheme.
RSA
Rivest-Shamir-Adleman, a widely used classical public-key algorithm vulnerable to a large enough quantum computer running Shor’s algorithm.
ECDH
Elliptic-Curve Diffie-Hellman, a classical key-agreement method used in many modern protocols and targeted for replacement in post-quantum migration.
ECDSA
Elliptic Curve Digital Signature Algorithm, a classical signature scheme used in certificates and software signing that is targeted for replacement.