The National Institute of Standards and Technology (NIST) has been leading the global effort to standardize post-quantum cryptographic algorithms since 2016. As of early 2026, three standards have been finalized and a fourth is in draft, marking the most significant shift in public-key cryptography since the introduction of RSA in 1977. This article provides a detailed technical overview of each standard, their deployment status, and what organizations should be doing right now.
A Brief History of the NIST PQC Process
In 2016, NIST issued a call for proposals for quantum-resistant cryptographic algorithms. The response was substantial: 82 initial submissions from research teams around the world. Over six years and four evaluation rounds, NIST narrowed the field based on security proofs, performance benchmarks, implementation maturity, and resistance to side-channel attacks.
The evaluation process was unusually public and rigorous. Every submission was subject to open cryptanalysis by the global research community. Several promising candidates were eliminated when vulnerabilities were discovered -- most notably SIKE, an isogeny-based scheme that was broken in 2022 by a classical attack using a novel mathematical technique. This underscored the importance of algorithmic diversity and the value of a multi-year evaluation process.
By 2024, NIST had finalized three standards and advanced a fourth to draft status. These four algorithms now form the foundation of the global post-quantum cryptographic transition.
The Finalized Standards
FIPS 203: ML-KEM (Module Lattice Key Encapsulation Mechanism)
ML-KEM, formerly known as CRYSTALS-Kyber, is the primary standard for quantum-resistant key exchange. It replaces classical key agreement protocols like ECDH and RSA key transport. ML-KEM is a key encapsulation mechanism (KEM), meaning it generates a shared secret between two parties without directly exchanging keys -- a subtle but important distinction from traditional key exchange.
ML-KEM comes in three parameter sets:
| Parameter Set | NIST Level | Classical Equivalent | Public Key Size | Ciphertext Size |
|---|---|---|---|---|
| ML-KEM-512 | Level 1 | AES-128 | 800 bytes | 768 bytes |
| ML-KEM-768 | Level 3 | AES-192 | 1,184 bytes | 1,088 bytes |
| ML-KEM-1024 | Level 5 | AES-256 | 1,568 bytes | 1,568 bytes |
ML-KEM is based on the Module Learning With Errors (MLWE) problem, a well-studied lattice problem believed to be resistant to both classical and quantum attacks. The module variant offers a good balance between security and performance compared to the standard or ring variants of LWE.
Deployment status in 2026: ML-KEM is the most widely deployed PQC algorithm. Chrome and Firefox have enabled hybrid X25519+ML-KEM-768 key exchange by default for TLS 1.3 connections. Cloudflare, AWS, and major CDN providers support it on their edge networks. OpenSSL 3.5 and BoringSSL include production-ready ML-KEM implementations. The IETF has published RFC 9370 specifying hybrid key exchange for TLS 1.3.
Recommended deployment: ML-KEM-768 in hybrid mode with X25519 is the recommended default for most organizations. This provides Level 3 (AES-192 equivalent) quantum security while maintaining classical security through X25519. For environments requiring the highest assurance, ML-KEM-1024 with P-384 ECDH provides Level 5 protection.
Here is an example of configuring hybrid key exchange in a modern web server (Nginx with OpenSSL 3.5+):
ssl_protocols TLSv1.3;
sslconfcommand Groups X25519MLKEM768:X25519:P-256;
sslpreferserver_ciphers on;FIPS 204: ML-DSA (Module Lattice Digital Signature Algorithm)
ML-DSA, formerly CRYSTALS-Dilithium, is the primary standard for quantum-resistant digital signatures. It replaces ECDSA, Ed25519, and RSA signatures across the full spectrum of signing use cases: TLS server authentication, code signing, document signing, and certificate issuance.
| Parameter Set | NIST Level | Public Key Size | Signature Size |
|---|---|---|---|
| ML-DSA-44 | Level 2 | 1,312 bytes | 2,420 bytes |
| ML-DSA-65 | Level 3 | 1,952 bytes | 3,309 bytes |
| ML-DSA-87 | Level 5 | 2,592 bytes | 4,627 bytes |
The most notable impact of ML-DSA is the increase in signature size. An Ed25519 signature is 64 bytes. An ML-DSA-65 signature is 3,309 bytes -- roughly 50 times larger. For a single signature operation this is negligible, but the impact compounds in protocols that transmit multiple signatures, such as TLS certificate chains (which typically include 2-3 certificates, each with a signature) and blockchain transactions.
Deployment status in 2026: ML-DSA deployment lags behind ML-KEM because signature migration is more complex. Key exchange can be upgraded unilaterally by deploying hybrid mode on servers, but signatures require coordination across the entire trust chain -- from root CAs to intermediate CAs to leaf certificates to relying parties. Several certificate authorities have begun issuing dual certificates (classical + PQC), and the CA/Browser Forum has approved ML-DSA for use in publicly trusted certificates.
Recommended deployment: Begin issuing ML-DSA-65 certificates alongside your existing ECDSA certificates for internal services. For public-facing TLS, wait for broader client support of ML-DSA certificate verification, but begin testing now. For code signing and document signing, ML-DSA-65 is ready for production use.
FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)
SLH-DSA, formerly SPHINCS+, provides an alternative signature scheme based solely on hash function security. This is a critically important property: while ML-KEM and ML-DSA derive their security from lattice problems (which are believed to be quantum-resistant but not proven), SLH-DSA derives its security from the collision resistance and preimage resistance of hash functions -- properties that have been studied for decades and are well understood.
SLH-DSA exists as a conservative fallback. If a breakthrough attack is discovered against lattice-based assumptions (analogous to the classical attack that broke SIKE), SLH-DSA provides an alternative that remains secure. This is the essence of cryptographic agility: maintaining the ability to switch algorithms without a complete infrastructure rebuild.
The trade-off is size. SLH-DSA comes in twelve parameter sets across three security levels and two performance profiles:
| Variant | Security Level | Signature Size | Signing Speed |
|---|---|---|---|
| SLH-DSA-128s | Level 1 | 7,856 bytes | Slow |
| SLH-DSA-128f | Level 1 | 17,088 bytes | Fast |
| SLH-DSA-192s | Level 3 | 16,224 bytes | Slow |
| SLH-DSA-192f | Level 3 | 35,664 bytes | Fast |
| SLH-DSA-256s | Level 5 | 29,792 bytes | Slow |
| SLH-DSA-256f | Level 5 | 49,856 bytes | Fast |
The "s" variants produce smaller signatures but take longer to sign. The "f" variants sign faster but produce larger signatures. Even the smallest SLH-DSA signature (7,856 bytes at Level 1) is more than three times the size of ML-DSA-44 (2,420 bytes at Level 2).
Recommended deployment: SLH-DSA is best suited for use cases where signature size is less critical than security conservatism: long-term document signing, firmware signing, and root certificate authority operations. It is not recommended for high-throughput protocols like TLS or real-time communication due to the signature size overhead.
The Draft Standard
FIPS 206: FN-DSA (FFT over NTRU Lattice Digital Signature Algorithm)
FN-DSA, formerly FALCON, is expected to be finalized in late 2026 or early 2027. It offers the most compact post-quantum signatures of any NIST standard, making it the most practical PQC signature scheme for bandwidth-constrained environments.
| Parameter Set | NIST Level | Public Key Size | Signature Size |
|---|---|---|---|
| FN-DSA-512 | Level 1 | 897 bytes | ~666 bytes |
| FN-DSA-1024 | Level 5 | 1,793 bytes | ~1,280 bytes |
An FN-DSA-512 signature at 666 bytes is less than one-third the size of ML-DSA-44 at 2,420 bytes. This makes FN-DSA particularly attractive for:
- IoT and embedded systems where every byte of bandwidth and storage matters.
- Blockchain and distributed ledger applications where transactions include signatures that are permanently stored.
- DNS and DNSSEC where response size directly impacts resolution latency.
- Certificate chains where multiple signatures compound the size overhead.
Recommended deployment: Wait for the final standard before deploying FN-DSA in production. Begin evaluating library support and testing in non-production environments. Plan to use FN-DSA for constrained environments once the standard is finalized and audited implementations are available.
What Comes Next
Additional Algorithm Diversity
NIST has initiated a new call for additional post-quantum signature schemes, specifically seeking algorithms based on different mathematical foundations than lattices. The goal is to ensure that if a breakthrough attack is found against lattice problems, the world is not left without viable alternatives. Categories under evaluation include:
- Code-based signatures built on error-correcting codes (e.g., LESS, CROSS).
- Multivariate polynomial signatures (e.g., UOV, MAYO).
- Isogeny-based schemes that have been redesigned since the SIKE break (e.g., SQIsign).
- Symmetric-key-based signatures (e.g., FAEST, AIMer).
CNSA 2.0 Timeline
The NSA's Commercial National Security Algorithm Suite 2.0 (CNSA 2.0) provides specific timelines for National Security Systems (NSS):
- 2025: Begin using ML-KEM-1024 for key establishment in new systems.
- 2026: Begin using ML-DSA-87 for software and firmware signing.
- 2030: All NSS must exclusively use CNSA 2.0 algorithms for key establishment.
- 2033: All NSS must exclusively use CNSA 2.0 algorithms for digital signatures.
- 2035: All NSS must exclusively use CNSA 2.0 algorithms. No legacy algorithms permitted.
Practical Guidance for 2026
If you are reading this and have not started your PQC migration, here is what to do now:
- Deploy hybrid ML-KEM key exchange on all TLS endpoints. This is the single highest-impact action. It protects data in transit against HNDL attacks immediately. Use X25519+ML-KEM-768 for TLS 1.3.
- Build a Cryptographic Bill of Materials. Inventory every algorithm, certificate, and key in your infrastructure. You cannot plan a migration without knowing your starting point. See our CBOM guide for details.
- Calculate your HNDL Score. Quantify your organization's exposure using the HNDL calculator. This gives you a baseline to track progress against.
- Begin ML-DSA certificate testing. Issue ML-DSA-65 certificates for internal services and test compatibility with your infrastructure. Do not wait for full browser support -- internal services are within your control.
- Plan for crypto-agility. Architect your systems so that cryptographic algorithms can be swapped without application-level changes. Use configuration-driven algorithm selection, abstract cryptographic operations behind clean interfaces, and avoid hardcoding algorithm identifiers.
- Engage your vendors. Ask your cloud providers, SaaS vendors, and technology partners about their PQC migration timelines. If they cannot provide one, that is a risk factor you need to account for.
