Post-Quantum Cryptography Standards: What Is Final and What Is Not

In August 2024, NIST published three finished federal standards. FIPS 203, FIPS 204 and FIPS 205 closed out a selection process that opened in 2016 with 82 submissions, of which NIST accepted 69 as complete and proper for the first round. Everything else that has happened since is either an addition to that set or a matter of implementation.

That distinction gets lost in most coverage, which still treats post-quantum standardization as breaking news. For the algorithms that carry ordinary production traffic, the choosing is done. What remains useful is an accurate map of the boundary between finished and unfinished work, because migration plans keep stalling on the belief that something important is still undecided.

This post sets out four groups: the standards that are final, the one that is drafted but not published, the algorithms still under evaluation, and the candidates that were eliminated. We teach this material to security architects and engineering leads at Quantum Academy, and the question we get most often isn’t which algorithm is best, it’s which ones an organization is allowed to deploy today, and the answer has been settled for over a year.

Why Public-Key Cryptography Had to Be Replaced

RSA, Diffie-Hellman and the elliptic-curve schemes all rest on two mathematical problems: factoring large integers, and computing discrete logarithms. Both are hard for classical computers at the key sizes in use. Peter Shor showed in 1994 that both are easy for a quantum computer of sufficient scale and reliability. The term of art for such a machine is a cryptographically relevant quantum computer, or CRQC, and no one has built one. When one exists, it recovers private keys from public keys directly, which ends the security of every protocol that depends on them.

Symmetric cryptography is in a different position. Grover’s algorithm speeds up brute-force key search quadratically, and doubling the key length compensates. AES-256 and SHA-384 were standardized years ago and remain appropriate. NIST’s assessment is that SHA-256 also holds up, because the quantum attacks that improve on collision search require quantum memory at a scale that makes them impractical. The urgent replacement work is confined to public-key encryption, key establishment and digital signatures.

The reason the work can’t wait for a CRQC to appear is harvest now, decrypt later. An adversary who records encrypted traffic today can store it and decrypt it whenever the capability arrives. Any data with a confidentiality requirement measured in years is already exposed by that arithmetic. Signatures are less affected, since a signature verified today can’t be retroactively forged, but the certificate and firmware chains that depend on them take years to rotate.

The Finished Standards

Four algorithms came out of the main NIST competition. Three are published as final federal standards. All four have generic names that replaced their submission names, and the generic names are what appear in standards, libraries and procurement documents.

ML-KEM in FIPS 203

ML-KEM (formerly CRYSTALS-Kyber), short for Module-Lattice-Based Key-Encapsulation Mechanism, is the default replacement for Diffie-Hellman, ECDH and RSA key transport.

A key-encapsulation mechanism, or KEM, works differently from a Diffie-Hellman exchange even though it fills the same slot. One party holds a public key. The other generates a fresh shared secret, encapsulates it under that public key, and sends the encapsulation. The holder of the private key decapsulates and recovers the same secret. Both sides end up with a shared symmetric key, which is what the rest of the protocol needs.

Its security rests on lattice problems, specifically a structured form of Learning With Errors. In plain terms, the scheme hides a secret inside a system of linear equations that has been deliberately corrupted with small random errors. Recovering the secret means solving those equations despite the noise, and no efficient algorithm for that is known, classical or quantum.

FIPS 203 defines three parameter sets. ML-KEM-512 targets security category 1, ML-KEM-768 targets category 3, and ML-KEM-1024 targets category 5. ML-KEM-768 is the general-purpose choice for most systems, and the NSA’s Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) requires ML-KEM-1024 for national security systems. Public keys run from 800 to 1,568 bytes and encapsulations from 768 to 1,568 bytes, which is larger than an ECDH exchange and smaller than most people expect. Decapsulation is fast, considerably faster than an RSA private-key operation, so servers terminating many connections generally see their CPU cost go down rather than up.

ML-DSA in FIPS 204

ML-DSA, the Module-Lattice-Based Digital Signature Algorithm, was submitted as CRYSTALS-Dilithium. It shares mathematical foundations with ML-KEM and is the default replacement for RSA-PSS, ECDSA and Ed25519.

FIPS 204 defines ML-DSA-44, ML-DSA-65 and ML-DSA-87, targeting categories 2, 3 and 5. The parameter numbers refer to the dimensions of the matrix at the heart of the scheme, not to security bits, which trips people up on first reading. ML-DSA-65 is the common general-purpose selection and CNSA 2.0 requires ML-DSA-87.

The trade is size. An ML-DSA-44 signature is 2,420 bytes against roughly 64 bytes for an ECDSA P-256 signature, and the public key is 1,312 bytes against 33 bytes compressed. A certificate chain carrying three of these gains several kilobytes. Verification, on the other hand, is quick, which suits the asymmetry of most deployments where a signature is produced once and checked many times.

SLH-DSA in FIPS 205

SLH-DSA, the Stateless Hash-Based Digital Signature Algorithm, was submitted as SPHINCS+. It shares no mathematics with the other two.

A hash-based signature builds everything out of hash functions and Merkle trees, with no number theory underneath. The security argument reduces to a single claim: SHA-2 or SHAKE resists preimage and collision attacks. That’s an unusually conservative assumption, because hash functions have been studied for decades and quantum computers offer only modest speedups against them. NIST standardized SLH-DSA specifically so that the signature portfolio wouldn’t depend entirely on lattices.

The cost is severe. The smallest parameter set produces signatures of 7,856 bytes, and the larger sets run into the tens of kilobytes. Signing requires thousands of hash computations and is slow enough that high-volume signing is out of the question. The public key is only 32 bytes, which helps in a narrow set of cases.

SLH-DSA belongs where assurance dominates and volume is low. Root certificate authorities that sign a handful of times per year, long-lived archival signatures, and any trust anchor that has to remain valid past the useful life of current cryptanalysis are all reasonable homes for it. We’d caution against reaching for it as a general-purpose signature, and NIST doesn’t recommend that either.

FN-DSA and the Missing FIPS 206

The fourth selection was FALCON, to be standardized as FN-DSA, the FFT over NTRU-Lattice-Based Digital Signature Algorithm, in FIPS 206. As of this writing that standard has not been published in final form.

FN-DSA earns its place on size. A FALCON-512 signature runs to roughly 666 bytes with an 897-byte public key, which is a quarter the size of the equivalent ML-DSA output and within range of what current protocols were designed to carry. That is genuinely useful for DNSSEC, for constrained radio links, and for certificate chains where every kilobyte multiplies.

The difficulty is implementation. FN-DSA samples from a discrete Gaussian distribution over a lattice, and doing so correctly requires floating-point arithmetic or carefully emulated fixed-point equivalents. Small deviations in how that sampling behaves can leak information about the private key through a side channel, meaning an attacker learns secrets by measuring timing or power draw rather than by attacking the mathematics. That makes FN-DSA the most demanding of the four selections to implement safely. Until FIPS 206 exists and vetted libraries follow it, treat FN-DSA as a planned option rather than a current one.

How NIST Rates Strength

Every candidate in the process was slotted into one of five security categories, and the numbers appear throughout the standards and vendor documentation.

Categories 1, 3 and 5 are pegged to the difficulty of brute-forcing a symmetric key of 128, 192 and 256 bits, which corresponds roughly to AES-128, AES-192 and AES-256. Categories 2 and 4 are pegged instead to the difficulty of finding a hash collision at the 128-bit and 192-bit levels. That second scale exists because attacks on signature schemes are often bounded by collision resistance rather than key search, and NIST wanted both cases covered. The ordering runs 1 through 5 from weakest to strongest.

For a rough sense of scale against what you already run: category 1 is comparable to RSA-3072 or the P-256 curve, category 3 to RSA-7680 or P-384, and category 5 to RSA-15360 or P-521. Those comparisons describe classical difficulty only. Against a CRQC, the RSA and elliptic-curve figures collapse entirely, which is the whole point of the exercise.

Still in Progress

Two threads of NIST work continue, and neither should hold up a migration.

HQC, the Second Key-Establishment Algorithm

NIST ran a fourth round after the main selection to find a key-establishment algorithm built on different mathematics from ML-KEM. Three code-based candidates went forward: HQC, BIKE and Classic McEliece.

Code-based cryptography derives its hardness from error-correcting codes. The private key is a code with a structure that permits efficient decoding; the public key is the same code presented so that its structure is hidden, leaving an attacker with the general problem of decoding a random linear code. That problem has resisted attack since Robert McEliece proposed the approach in 1978.

In March 2025, NIST selected HQC for standardization. Its fourth-round status report, NIST IR 8545, sets out the reasoning. HQC’s security analysis was more straightforward than BIKE’s and its operations are faster, at the price of larger keys and ciphertexts. Public keys run to roughly 2.2 KB and ciphertexts to roughly 4.4 KB at the lowest parameter set, several times the equivalent ML-KEM figures. NIST has indicated a draft standard around 2026 and a final one around 2027.

HQC is a backup, not a replacement. NIST’s guidance is that ML-KEM stays the primary choice, with HQC available for organizations that want a second algorithm resting on unrelated mathematics. Nobody should defer a key-establishment migration waiting for it.

The Signature On-Ramp

By the end of the main competition, the surviving signature schemes were two lattice designs and one hash-based design. NIST considered that too narrow and issued a fresh call in 2022 for signature schemes, explicitly asking for submissions that were not lattice-based or that offered substantially better performance. Forty submissions met the requirements. In October 2024, NIST advanced 14 of them to a second round and documented the first-round reasoning in NIST IR 8528.

The second-round set spans several families. There are code-based signatures such as CROSS and LESS. There is SQIsign, built on isogenies between elliptic curves, notable for producing signatures of a few hundred bytes. There are multivariate schemes including MAYO, QR-UOV and SNOVA, which solve systems of quadratic equations over finite fields. There are proof-based designs such as FAEST and Mirath, which construct a signature from a zero-knowledge proof and depend only on symmetric primitives. And HAWK represents a lattice design attempting to beat the incumbents on efficiency.

No winner has been declared, and NIST has said that anything emerging from this process will be an additional option rather than a replacement for ML-DSA. Expect several more years and at least one more round.

The Algorithms That Did Not Survive

The eliminations are as instructive as the selections, and they are the reason crypto-agility appears in every serious migration methodology. Crypto-agility means designing systems so that an algorithm can be swapped without redesigning the protocol, the certificate format or the hardware around it.

In July 2022, within weeks of NIST advancing SIKE to the fourth round, Wouter Castryck and Thomas Decru published a classical attack that recovered a SIKE private key at the lowest parameter set in about an hour on a single core. SIKE had been studied for years and was admired for its very small keys. It was removed from the process immediately, and no isogeny-based key-establishment scheme is currently viable.

Rainbow, a multivariate signature scheme, had reached the third round as a finalist before Ward Beullens published a practical break in 2022.

Two survivors were passed over rather than broken. BIKE lost to HQC on performance grounds despite smaller transmitted data. Classic McEliece, widely regarded as the most conservative design in the entire competition, was not selected because its public keys range from roughly 261 KB to over a megabyte depending on parameters. NIST noted that it doesn’t expect broad deployment at those sizes and left the door open to standardizing it later for specialized use. Ciphertexts, in fairness, are tiny.

Two of these algorithms fell to classical attacks discovered by academic cryptographers during a public evaluation, which is the process working as designed. The lesson for architects is that any single algorithm can fail, and a system that can only be re-keyed by a firmware respin has a problem no standard can solve.

Sizes and Speeds

The table below gives published figures for the standardized parameter sets alongside their classical predecessors.

Algorithm	Purpose	Public key	Ciphertext or signature	NIST category
ML-KEM-512	Key establishment	800 B	768 B	1
ML-KEM-768	Key establishment	1,184 B	1,088 B	3
ML-KEM-1024	Key establishment	1,568 B	1,568 B	5
ML-DSA-44	Signature	1,312 B	2,420 B	2
ML-DSA-65	Signature	1,952 B	3,293 B	3
ML-DSA-87	Signature	2,592 B	4,595 B	5
SLH-DSA-SHA2-128s	Signature	32 B	7,856 B	1
FN-DSA-512 (draft)	Signature	897 B	~666 B	1
RSA-2048	Both	256 B	256 B	quantum-vulnerable
ECDSA P-256	Signature	33 B	64 B	quantum-vulnerable

Two patterns run through those numbers. Post-quantum keys and outputs are larger, typically by a factor of five to fifty, and the increases are measured in kilobytes rather than megabytes. Computation, by contrast, is rarely the constraint. Lattice operations are arithmetic on small polynomials and vectorize well, and on most hardware ML-KEM decapsulation and ML-DSA verification are faster than the classical operations they replace.

Published protocol trials by Cloudflare, Google and Amazon have found the added handshake latency small under good network conditions. The size increase is the part that causes trouble, and it does so in specific places rather than uniformly. DNSSEC responses have UDP size limits that a multi-kilobyte signature exceeds. Embedded devices with fixed message buffers can fail on a larger certificate. Code that assumes a signature field never exceeds 1,024 bytes will break on ML-DSA output. Those failures show up during integration testing, not during algorithm selection, which is why we push learners toward protocol-level testing early.

Mapping Old Algorithms to New Ones

The substitutions are straightforward once the standards are in hand.

RSA key transport and RSA-OAEP become ML-KEM. Anywhere a symmetric key is encrypted under an RSA public key, a KEM does the same job with a different message flow.

Diffie-Hellman and ECDH become ML-KEM. In TLS 1.3 the KEM slots into the existing key-share negotiation, with the client sending an encapsulation instead of a group element.

RSA-PSS, ECDSA and EdDSA signatures become ML-DSA in the general case, FN-DSA where size dominates and the standard is available, and SLH-DSA where assurance dominates and volume is low.

AES and SHA-2 stay, with longer parameters. AES-256 and SHA-384 are the standard guidance, and CNSA 2.0 requires both for national security systems. No new symmetric primitive is needed.

Hybrid Deployment

A hybrid construction runs a classical method and a post-quantum method together and derives the session key from both, so the result is secure if either component holds. This is how post-quantum key establishment has actually reached production. Browsers and major CDNs deployed hybrid X25519 with ML-KEM-768 rather than ML-KEM alone, and Germany’s Federal Office for Information Security (BSI) and France’s national cybersecurity agency (ANSSI) have both recommended hybrid constructions during the transition period.

Hybrid costs bandwidth and complexity, and it isn’t permanent. CNSA 2.0 does not require it. The argument for hybrid rests on the age of the post-quantum algorithms rather than on any known weakness, and it will fade as confidence accumulates. The argument for hybrid signatures is weaker than for key establishment, since doubling every signature in a certificate chain doubles a cost that was already the main obstacle.

Standards Work Outside NIST

NIST chose the algorithms. Making them usable falls to a wider set of organizations, and this is where most of the remaining work sits.

The Internet Engineering Task Force (IETF) is defining how the algorithms appear in protocols. Hybrid key exchange in TLS 1.3, ML-KEM and ML-DSA identifiers in X.509 certificates, and post-quantum support in HPKE, SSH and IKEv2 are all in progress or recently published. Without these, two conforming implementations can use the same algorithm and still fail to interoperate.

CNSA 2.0 sets requirements for U.S. national security systems, specifying ML-KEM-1024 and ML-DSA-87 alongside AES-256 and SHA-384, and pointing to the stateful hash-based signatures of NIST SP 800-208 for firmware and software signing. Its stated target is exclusive use of the suite across national security systems by 2035.

In Europe, no separate algorithm competition has run. The European Union Agency for Cybersecurity (ENISA), the European Telecommunications Standards Institute (ETSI), BSI and ANSSI have all published migration guidance built on NIST’s selections, and the EU has set out a coordinated roadmap with milestones for beginning migration and for completing it in high-risk sectors. ISO/IEC JTC 1/SC 27 is expected to issue international standards mirroring the NIST algorithms, which matters for organizations whose procurement rules cite ISO rather than FIPS.

China is running a separate process. In February 2025 the Institute of Commercial Cryptography Standards issued a call for post-quantum algorithms covering public-key encryption, signatures, hash functions and block ciphers, a broader scope than NIST’s. China has historically maintained its own suite, including SM2, SM3 and SM4, and the same pattern is likely here. Organizations operating in both markets should plan for two algorithm sets in the same products, which is an argument for building the swap capability regardless of which algorithm wins where.

Deadlines Already on the Calendar

Urgency in this field comes from regulation and contracts, not from predictions about when a quantum computer will arrive.

The initial public draft of NIST IR 8547 proposes deprecating classical public-key algorithms at the 112-bit security level, which includes RSA-2048 and the P-256 curve, after 2030, and disallowing them after 2035. For a federal supplier, that is a hard date attached to a specific key size. U.S. federal agencies are already required to maintain inventories of their cryptographic assets, and the government’s stated migration target for vulnerable systems is 2035. CNSA 2.0 sets its own schedule for national security systems.

Those dates look distant until you count backwards through the work. A cryptographic inventory across a large estate takes a year or more. Certificate authorities have to issue new certificate types. Hardware security modules need firmware supporting the new algorithms, and HSM support has lagged software support throughout. Embedded devices in the field may never be updated at all and will have to be replaced on their normal refresh cycle, which for industrial equipment can run past 2035 on its own.

What Is Left to Do

The state of standardization, stated plainly: ML-KEM, ML-DSA and SLH-DSA are final and approved for use now. FN-DSA is selected but not published. HQC is selected and will follow as a second key-establishment option. The 14 second-round signature candidates are competing for a place as additional alternatives, on a timescale of years. Nothing in the unfinished column should delay work in the finished column.

The unfinished work that should concern practitioners sits elsewhere. Most organizations cannot yet answer where their public-key cryptography is used, which systems hold data with a confidentiality requirement past 2035, and which of their vendors have published a migration schedule. Those questions have nothing to do with algorithm selection and everything to do with the next decade of engineering effort. The methodology for working through them is set out at pqcframework.org, and deeper technical treatment of the algorithms lives at PostQuantum.com.

Quantum Academy’s post-quantum cryptography program is built for the people who have to execute this rather than describe it. Learners work through algorithm selection against real constraints, cryptographic inventory, protocol-level testing, and the sequencing of a migration across systems that can’t all be changed at once. Assessment is against applied scenarios rather than recall of parameter tables. You can review the program and its prerequisites at quantumacademy.com/.