The NIST Post-Quantum Standards Explained: FIPS 203, 204, 205 and 206

In August 2024, NIST finalized the world's first post-quantum cryptographic standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). A fourth standard, FIPS 206 (FN-DSA), remains in draft. Together these define the algorithms that will replace today's RSA and elliptic-curve cryptography before a large-scale quantum computer can break it.

If you are responsible for security at your organization, these four documents are the foundation of every credible migration plan written for the next decade. This guide explains what each standard is, when to use it, and how to begin moving.

A brief history of the NIST PQC competition

The story starts in 2016. NIST opened a public, competition-style process to find cryptographic algorithms that could withstand attack by both classical and quantum computers. Quantum machines threaten public-key cryptography specifically: Shor's algorithm, once run on a sufficiently large fault-tolerant quantum computer, would break the integer-factorization and discrete-logarithm problems that RSA, Diffie-Hellman, and elliptic-curve cryptography depend on.

Over roughly eight years, the process moved through several rounds. Cryptographers worldwide submitted dozens of candidate algorithms, then spent years publicly attacking, analyzing, and benchmarking them. Some well-known submissions were broken outright during the process — a feature, not a bug, of doing the vetting in the open.

In July 2022, NIST announced its first selections for standardization. Draft standards followed, and in August 2024 the first three were finalized as Federal Information Processing Standards. The competition deliberately chose algorithms built on different mathematical foundations — structured lattices and hash functions — so that a future break in one family would not collapse the whole portfolio.

The standards at a glance

Note the split. Only FIPS 203 handles key exchange — the part of TLS and VPNs that protects data in transit and is most exposed to "harvest now, decrypt later" attacks. The other three are all digital signatures, used for authentication, code signing, certificates, and document integrity. For a deeper walkthrough of the underlying threat model, see our post-quantum cryptography guide.

FIPS 203 — ML-KEM (CRYSTALS-Kyber)

What it does: ML-KEM, short for Module-Lattice-Based Key-Encapsulation Mechanism, is the standardized version of CRYSTALS-Kyber. It lets two parties establish a shared secret key over an untrusted network without an attacker being able to recover that key — even one armed with a future quantum computer. This is the post-quantum replacement for the key-exchange step in protocols like TLS 1.3.

ML-KEM ships in three parameter sets — ML-KEM-512, ML-KEM-768, and ML-KEM-1024 — offering increasing security margins. ML-KEM-768 is the common default for general-purpose use, balancing strong security with practical key and ciphertext sizes.

When to use it: Anywhere you currently rely on RSA or elliptic-curve Diffie-Hellman to negotiate session keys — HTTPS/TLS termination, VPN tunnels, encrypted messaging, and secure API connections. Because intercepted ciphertext today could be stored and decrypted years from now, key exchange is the first thing most organizations should migrate. At Secuur we deploy it as a hybrid X25519 + ML-KEM-768 construction, so a connection is safe as long as either the classical or the post-quantum component holds.

FIPS 204 — ML-DSA (CRYSTALS-Dilithium)

What it does: ML-DSA (Module-Lattice-Based Digital Signature Algorithm), the standardized form of CRYSTALS-Dilithium, produces digital signatures that prove authenticity and integrity. It is NIST's primary recommended signature scheme for most applications.

When to use it: Make ML-DSA your default choice for new signature work — TLS certificates, software and firmware signing, authentication tokens, and signed documents. It offers a strong balance of signing speed, verification speed, and signature size, and rests on the same well-studied lattice foundations as ML-KEM. Unless you have a specific constraint that points elsewhere, ML-DSA is the right starting point.

FIPS 205 — SLH-DSA (SPHINCS+)

What it does: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) is the standardized version of SPHINCS+. Crucially, its security relies only on the properties of cryptographic hash functions — not on lattice problems. That makes it a deliberate hedge: if a future cryptanalytic breakthrough ever weakened lattice-based schemes, hash-based signatures would still stand.

The trade-off is size and speed. SLH-DSA signatures are considerably larger and slower to generate than ML-DSA's, which makes it less suited to high-volume, latency-sensitive systems.

When to use it: Choose SLH-DSA where long-term assurance matters more than performance and where you sign relatively infrequently — firmware and boot signing, root certificate authorities, software-supply-chain attestation, and other high-value, low-volume roots of trust. Many organizations use ML-DSA broadly and reserve SLH-DSA for their most critical, long-lived keys.

FIPS 206 — FN-DSA (FALCON), still in draft

What it does: FN-DSA (FFT over NTRU-Lattice-Based Digital Signature Algorithm) is the planned standardization of FALCON. Its headline feature is compactness — FALCON produces signatures and public keys notably smaller than ML-DSA's, which is valuable when bandwidth or storage is tight.

Status: FIPS 206 is not yet finalized. As of this writing it remains in draft, in part because FALCON's signing procedure involves floating-point arithmetic that is comparatively difficult to implement correctly and to protect against side-channel attacks. Until FIPS 206 is published as a final standard, treat FN-DSA as forthcoming rather than ready for production reliance.

When to use it (eventually): Constrained environments — IoT devices, smart cards, and protocols sensitive to certificate size — where small signatures justify the more demanding implementation. For now, plan for it but build on the three finalized standards.

What these standards mean for your business

The practical takeaway is that the waiting phase is over. There is now a stable, government-vetted target to migrate toward, which removes the most common excuse for inaction. Three forces make this urgent:

• Harvest now, decrypt later. Adversaries can capture encrypted traffic today and decrypt it once quantum hardware matures. Any data that must stay confidential for years is already at risk.
• Long replacement cycles. Cryptography is embedded deep in firmware, hardware, certificates, and vendor products. Migrations of this scale take years, so starting late is the real danger.
• Compliance pressure. Federal guidance and industry frameworks increasingly reference these standards. Regulated sectors should expect post-quantum readiness to become an audit expectation.

How to start migrating:

1. Inventory your cryptography. You cannot protect what you have not found. Catalog where RSA and ECC are used across applications, certificates, VPNs, and third-party services.
2. Prioritize key exchange first. Because of harvest-now-decrypt-later, migrating TLS and VPN key exchange to ML-KEM (FIPS 203) delivers the most immediate protection.
3. Adopt hybrid modes. Pair a classical algorithm with a post-quantum one — for example X25519 + ML-KEM-768 — so you stay protected even if either component is later questioned.
4. Plan signature migration. Move toward ML-DSA (FIPS 204) for general signing and SLH-DSA (FIPS 205) for long-lived roots of trust.
5. Measure your readiness. Establish a baseline so you can track progress and prove it to auditors.

Secuur, a product of Triple Seven Solutions LLC, exists to make this practical. Our free A–F Readiness Scan grades your organization's current exposure and gives you a prioritized starting point — run a free quantum-risk scan. When you are ready to deploy, our hybrid X25519 + ML-KEM-768 migration brings FIPS 203 protection to your traffic without ripping out your existing cryptography. For the full breakdown of each standard, read our full NIST standards explainer, and when you are ready to plan the rollout, see the migration overview.

Frequently Asked Questions

When did NIST finalize the post-quantum standards?

NIST finalized the first three post-quantum cryptographic standards in August 2024: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). These followed an eight-year public selection process that began in 2016. A fourth standard, FIPS 206 (FN-DSA / FALCON), remains in draft and has not yet been finalized.

What is the difference between ML-KEM and ML-DSA?

They solve different problems. ML-KEM (FIPS 203) is a key-encapsulation mechanism — it lets two parties agree on a shared secret over an untrusted network, replacing RSA and elliptic-curve key exchange. ML-DSA (FIPS 204) is a digital signature algorithm — it proves authenticity and integrity, replacing RSA and ECDSA signatures. In short: ML-KEM protects data in transit, while ML-DSA proves who signed something.

Is FALCON / FIPS 206 final yet?

No. FIPS 206 (FN-DSA), the standardization of FALCON, is still in draft and not yet a finalized standard. FALCON produces unusually compact signatures, but its reliance on floating-point arithmetic makes it harder to implement safely, which has contributed to the longer timeline. Until FIPS 206 is published as final, build production systems on the three finalized standards — FIPS 203, 204, and 205.

Which standard should I migrate to first?

For most organizations, key exchange comes first — migrate TLS and VPN key negotiation to ML-KEM (FIPS 203), ideally in a hybrid mode such as X25519 + ML-KEM-768. This is because of "harvest now, decrypt later" attacks: data captured today can be decrypted once quantum computers mature, so protecting traffic in transit is the most time-sensitive step. Signature migration to ML-DSA and SLH-DSA can follow.

Do these standards replace AES and SHA?

No. The NIST post-quantum standards target public-key cryptography — key exchange and digital signatures — because that is what quantum computers most directly threaten via Shor's algorithm. Symmetric algorithms like AES and hash functions like SHA-2 and SHA-3 are far more resistant; the main recommendation there is to use sufficient key and output sizes (for example, AES-256). Your symmetric cryptography does not need to be swapped out the way RSA and ECC do.