What NIST Standardized — and Why
NIST's post-quantum cryptography standards are a set of encryption algorithms designed to resist attacks from both classical and quantum computers. On August 13, 2024, the U.S. National Institute of Standards and Technology finalized the first three as Federal Information Processing Standards: ML-KEM (FIPS 203) for key establishment, ML-DSA (FIPS 204) for digital signatures, and SLH-DSA (FIPS 205) as a hash-based signature alternative.
The reason is Shor's algorithm: a sufficiently large quantum computer running it would break RSA and elliptic-curve cryptography — the public-key algorithms that secure essentially all of today's internet traffic, digital signatures, and stored secrets. NIST ran an eight-year open competition (2016–2024), evaluating dozens of candidate algorithms under public cryptanalysis. The two lattice-based winners most organizations will deploy first are ML-KEM and ML-DSA, and they solve two different problems.
ML-KEM: Key Encapsulation Explained
ML-KEM — the Module-Lattice-based Key-Encapsulation Mechanism, standardized in FIPS 203 and derived from the CRYSTALS-Kyber submission — does one job: it lets two parties establish a shared secret key over an insecure channel. That is the post-quantum replacement for the key-exchange role RSA and Elliptic-Curve Diffie-Hellman play inside TLS, VPNs, and secure messaging today.
Its security rests on the Module Learning With Errors (Module-LWE) problem — the difficulty of recovering a secret from noisy linear equations over structured lattices. No known algorithm, classical or quantum, solves it efficiently. ML-KEM ships in three parameter sets, which trade key size and compute cost against security margin:
| Parameter set | NIST security category | Comparable to | Typical use |
|---|---|---|---|
| ML-KEM-512 | Category 1 | AES-128 | Constrained / performance-sensitive |
| ML-KEM-768 | Category 3 | AES-192 | General-purpose default |
| ML-KEM-1024 | Category 5 | AES-256 | High-assurance / long-lived secrets |
ML-KEM-768 has emerged as the common default — it is the level behind the hybrid X25519MLKEM768 key exchange already shipping in mainstream browsers and CDNs. Most teams deploy PQC key exchange in hybrid mode first, running a classical and a post-quantum algorithm together, so a weakness in either one alone does not compromise the connection.
ML-DSA: Digital Signatures Explained
ML-DSA — the Module-Lattice-based Digital Signature Algorithm, FIPS 204, derived from CRYSTALS-Dilithium — proves authenticity and integrity. It is the post-quantum replacement for the RSA and ECDSA signatures behind TLS certificates, code signing, firmware updates, and document signing.
Its hardness comes from two lattice problems — Module-LWE and Module-SIS (Short Integer Solution) — combined through a construction called Fiat-Shamir with Aborts. In plain terms, the signer generates a candidate signature and rejects-and-retries until it produces one that leaks no information about the private key (rejection sampling). ML-DSA also comes in three parameter sets:
| Parameter set | NIST security category | Comparable strength |
|---|---|---|
| ML-DSA-44 | Category 2 | ~AES-128 / SHA-256 |
| ML-DSA-65 | Category 3 | ~AES-192 |
| ML-DSA-87 | Category 5 | ~AES-256 |
The practical catch: post-quantum signatures are much larger than ECDSA — kilobytes rather than tens of bytes. That size matters for bandwidth-constrained protocols like certificate chains and DNSSEC, and it is one reason NIST also standardized the more conservative hash-based SLH-DSA as a backup, and is still evaluating additional signature schemes.
Why This Matters Now, Not Later
The threat that makes this urgent is “harvest now, decrypt later”: an adversary can capture encrypted traffic today and store it until a cryptographically relevant quantum computer exists to decrypt it. Any data whose confidentiality must outlast the arrival of that machine — state secrets, health records, financial data, long-lived credentials — is effectively already exposed.
Estimates for when such a computer arrives range from the early 2030s to much later, and the honest answer is that nobody knows precisely. But that uncertainty is not a reason to wait. A full cryptographic migration across a real organization — inventorying every place cryptography is used, building crypto-agility, testing, and deploying without breaking interoperability — takes years. The deadline that actually matters is not when quantum computers arrive; it is when you must start. That is exactly why regulators have set the deadlines below.
Migration Timelines by Sector
The regulatory picture is what turns an abstract quantum threat into a dated project plan. The headline deadlines already on the books:
- United States: National Security Memorandum 10 (NSM-10) directs federal agencies toward migration by 2035, with NSA's CNSA 2.0 suite setting earlier milestones for national-security systems through the late 2020s and early 2030s.
- European Union: the Coordinated Implementation Roadmap for the PQC transition (published 2025 by the NIS Cooperation Group) targets high-risk use cases by 2030 and medium-risk by 2035. DORA has already put crypto-agility and operational resilience under regulatory scrutiny for financial entities since January 2025.
- United Kingdom: the NCSC published a three-phase timeline — discovery and planning by 2028, migration of the highest-priority systems by 2031, and full migration by 2035.
- Australia: ASD guidance points toward phasing out today's public-key algorithms by 2030 for high-assurance systems.
These deadlines land hardest on public infrastructure with decades-long data-protection horizons, where the “harvest now” window is widest. That is the exact problem we work on in government PQC migration.
What This Means for Your Organization
Wherever your deadline sits, the first moves are the same:
- Build a cryptographic inventory. You cannot migrate what you cannot see — and in most real estates, cryptography is used in far more places than anyone has documented.
- Prioritize by data lifetime and criticality. Systems protecting long-lived secrets migrate first; ephemeral session data can wait.
- Adopt crypto-agility. Architect so algorithms can be swapped without re-engineering the system around them.
- Start with hybrid deployments where standards and libraries already support them, rather than waiting for an all-at-once cutover.
The hard part was never the algorithm. It is finding every place cryptography touches a real system and sequencing the migration without breaking what already works. That is the work we do in PQC migration consulting. If you are a research institution or want to go deeper on the underlying cryptography, you can propose a research collaboration or read our post-quantum cryptography research.