Jan 1, 2026
Inside NIST’s Post-Quantum Cryptography Standards
Inside NIST’s Post-Quantum Cryptography Standards
If you search for “NIST post-quantum cryptography”, you are seldom looking for a lecture in number theory. You want to know what to deploy, what to buy, and how to plan. That is why NIST’s Post-Quantum Cryptography (PQC) programme has become the global reference point. It turns years of research into implementable, auditable baselines for governments, defence primes, critical infrastructure operators, and enterprise CISOs. On 13 August 2024 NIST finalised its first three PQC standards, and by 2025 it had charted the next steps for encryption and signatures.
This article explains what NIST has standardised, how those choices map onto real systems like TLS, VPNs, PKI, firmware signing and identity, and what technical leaders should do now.
1) Why PQC matters now
NIST’s PQC standards are designed to replace quantum-vulnerable public-key cryptography such as RSA and classical elliptic curves before large-scale quantum computers can run algorithms like Shor’s at scale. The risk is not theoretical only. Adversaries can harvest encrypted traffic today and decrypt it later once capability arrives - the store-now-decrypt-later threat. NIST’s programme materials set out the rationale and confirm that the new KEM and signature standards are ready for adoption.
2) The three finalised FIPS
\
FIPS 203 - ML-KEM. A module-lattice-based key encapsulation mechanism for establishing shared secrets over untrusted networks. It offers three parameter sets - ML-KEM-512, -768 and -1024 - trading performance against security strength. ML-KEM is believed secure even against quantum-capable adversaries.
FIPS 204 - ML-DSA. A module-lattice-based digital signature standard derived from CRYSTALS-Dilithium, designed for general-purpose signing and verification with strong performance and relatively compact keys.
FIPS 205 - SLH-DSA. A stateless hash-based signature standard derived from SPHINCS+, providing a mathematically distinct alternative to lattice-based signatures - useful for ecosystem diversity and risk reduction. NIST Computer Security Resource Center
NIST explicitly encourages organisations to put these standards into use now rather than wait for future publications. NIST Computer Security Resource Center
3) ML-KEM in practice - the workhorse for key establishment
When people say “post-quantum encryption” in the context of the web or VPNs, they usually mean ML-KEM. Precision matters. ML-KEM’s job is to establish a shared secret which then drives symmetric cryptography such as AES. That mirrors modern protocol design - public-key tools bootstrap keys, symmetric algorithms carry the bulk encryption and authentication. For many enterprise network scenarios, ML-KEM-768 has emerged as a pragmatic default, though threat models and performance constraints should guide the final choice
TLS is the first big landing zone. The IETF TLS working group has drafts that register ML-KEM as NamedGroups for TLS 1.3 and that define hybrid ECDHE-MLKEM handshakes. Hybrids combine classical ECDHE with ML-KEM so you retain today’s security while adding PQ resistance - a sensible bridge during transition.
At internet scale, it works. Chrome shipped support for the X25519-Kyber768 hybrid in 2023 to exercise the ecosystem, later aligning with the ML-KEM trajectory as standards matured. That real-world experiment demonstrated that PQ-ready handshakes can be deployed without breaking the internet.
4) ML-DSA - signatures for identity, code and trust chains
If ML-KEM establishes secrets, ML-DSA establishes trust. You will meet it everywhere signatures live - certificate authorities and PKI, software and firmware signing, secure boot, update systems, and document workflows. Because signatures often require verification years after issuance, migrating to PQ-safe signatures is a governance priority as much as a cryptographic one. ML-DSA is positioned by NIST as the main general-purpose PQ signature for broad adoption.
5) SLH-DSA - the diversity play
NIST deliberately did not standardise a single signature family. SLH-DSA is stateless hash-based and mathematically different from lattice-based schemes. That diversity reduces systemic risk. Should a class of attack weaken one family, implementers can pivot to another with minimal architectural upheaval - particularly valuable in high-assurance and regulated environments.
6) What’s coming next - HQC and FN-DSA
NIST’s programme continues to evolve. On 11 March 2025 it selected HQC as an additional key-establishment algorithm - a backup should ML-KEM ever be undermined. The decision is documented in NIST’s news release and in NIST IR 8545, the fourth-round status report.
On signatures, NIST is developing FIPS 206, defining FN-DSA based on FALCON. Presentations at the Sixth PQC Standardization Conference in September 2025 outline the design and implementation challenges - notably its use of floating-point arithmetic and highly compact signatures - and confirm standardisation work in progress.
Takeaway: do not pause. Start from the finalised FIPS now and build crypto-agility so you can add HQC or FN-DSA when they are finalised, without re-architecting your stack.
7) Transition is a programme, not a toggle
Standards are only half the story. NIST’s IR 8547 - Transition to Post-Quantum Cryptography Standards - frames migration as a multi-year programme: inventory, prioritisation, piloting, and staged roll-out. It maps quantum-vulnerable standards to their PQ replacements and helps procurement teams write requirements that suppliers can actually meet. Public comments in late 2024 and early 2025 underscore the breadth of stakeholders preparing for change.
8) Practical architecture patterns
Prefer hybrid while ecosystems are still moving. Where supported, use ECDHE-MLKEM hybrids in TLS 1.3 to preserve today’s security properties while adding PQ resistance. Track the IETF drafts that register ML-KEM NamedGroups and define hybrid handshakes, and test them in your edge proxies and service meshes.
Prioritise the high-burn paths first. Start where cryptography turns over most often or protects the widest surface: TLS termination, VPN and remote access, then PKI and certificate lifecycle management, then code and firmware signing, then identity flows. This sequence aligns with where ML-KEM and ML-DSA naturally fit and where operational feedback will be most valuable. (If you operate PKI, put issuance and OCSP/CRL endpoints on your early pilot list.)
Plan for operational realities. PQC changes message sizes and occasionally alters handshake behaviour. Some KEMs have tiny but non-zero failure probabilities that must be handled safely at the protocol level. Ensure your telemetry, rate limiting and retry logic cope, and rehearse failure drills before you touch production. The IETF hybrid design draft documents these considerations explicitly.
Engineer crypto-agility end-to-end. Decouple algorithm choices from business logic. Aim for policy-driven configuration so you can move from ML-KEM-768 to -1024, or add HQC, without code changes. In embedded and high-assurance settings, factor in side-channel hardening and constant-time implementations from day one. Industry workshops in 2025 show that vendors are already shipping FIPS-validated components and planning policy switches for ML-KEM in TLS 1.3.
Think across protocols, not just HTTPS. TLS will carry most traffic, but watch the broader protocol landscape - IPsec/IKEv2, QUIC, SSH and others have PQC work under way. The IETF’s PQUIP tracking shows active drafts for hybrid ML-KEM in IKEv2 and more. Your asset inventory should cover every control plane and data plane, not just browsers.
9) A 2026-ready action list for CISOs and architects
Set FIPS 203, 204 and 205 as your baseline. Mandate them in product roadmaps and third-party requirements.
Build a cryptographic inventory. Identify where RSA and ECC are used, where signatures are verified, and how certificate chains are managed.
Adopt crypto-agility. Use pluggable algorithm modules, upgradeable libraries, and policy-driven configuration.
Pilot TLS hybrids now. Run controlled experiments with ECDHE-MLKEM in front of representative workloads, measure handshake impact and failure modes, and tune operational guardrails.
Update procurement language. Require PQC support plans, timelines, validation evidence and explicit alignment to NIST and IETF artefacts.
Prepare for the next standards. Track HQC and FN-DSA so you can add or switch algorithms without architectural churn.
References and further reading
NIST FIPS 203 - Module-Lattice-Based Key-Encapsulation Mechanism (ML-KEM): https://csrc.nist.gov/pubs/fips/203/final
NIST FIPS 204 - Module-Lattice-Based Digital Signature (ML-DSA): https://csrc.nist.gov/pubs/fips/204/final
NIST FIPS 205 - Stateless Hash-Based Digital Signature (SLH-DSA): https://csrc.nist.gov/pubs/fips/205/final
NIST PQC project overview and status: https://csrc.nist.gov/projects/post-quantum-cryptography
NIST IR 8547 (ipd) - Transition to Post-Quantum Cryptography Standards: https://csrc.nist.gov/pubs/ir/8547/ipd
NIST IR 8545 - Status Report on the Fourth Round of the PQC Standardization Process: https://csrc.nist.gov/pubs/ir/8545/final
NIST News - NIST Selects HQC as Fifth Algorithm for Post-Quantum Encryption (11 March 2025): https://www.nist.gov/news-events/news/2025/03/nist-selects-hqc-fifth-algorithm-post-quantum-encryption
FIPS 206 - FN-DSA (Falcon) status and conference materials: https://csrc.nist.gov/presentations/2025/fips-206-fn-dsa-falcon
IETF TLS - ML-KEM Post-Quantum Key Agreement for TLS 1.3: https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/
IETF TLS - Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLS 1.3: https://datatracker.ietf.org/doc/draft-ietf-tls-ecdhe-mlkem/
IETF TLS - Hybrid key exchange in TLS 1.3 design draft: https://datatracker.ietf.org/doc/draft-ietf-tls-hybrid-design/
Chromium Blog - Protecting Chrome Traffic with Hybrid Kyber KEM: https://blog.chromium.org/2023/08/protecting-chrome-traffic-with-hybrid.html
Chromium Root Programme - Moving forward together PQC timeline: https://googlechrome.github.io/chromerootprogram/moving-forward-together/
IETF PQUIP tracker - PQC across protocols: https://github.com/ietf-wg-pquip/state-of-protocols-and-pqc
