Updated: 2026-07-07

In August 2024, NIST (National Institute of Standards and Technology) published the first definitive post-quantum cryptography standards: FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA). These standards are designed to replace RSA and elliptic-curve schemes when a sufficiently powerful quantum computer appears to run Shor’s algorithm at scale. This article explains the algorithms, realistic timelines, and most importantly, how to prepare your security stack for the transition.

Key takeaways

  • ML-KEM (FIPS 203) replaces RSA/ECDH key exchange; ML-DSA (FIPS 204) replaces RSA/ECDSA signatures; SLH-DSA (FIPS 205) is the hash-based alternative.

  • The immediate risk is not the quantum computer, which does not exist yet, but the "harvest now, decrypt later" attack: data encrypted today can be decrypted in the future.

  • Long-lived secrets (financial data, intellectual property, public sector) are most exposed and should be prioritised.

  • The recommended transition strategy is the hybrid approach: classical and PQC cryptography in parallel, to avoid dependence on a single scheme.

  • Crypto-agility, designing systems where cryptographic algorithms are interchangeable, is the technical prerequisite for any migration plan.

The problem PQC standards solve

Shor’s algorithm (1994) showed that a sufficiently large quantum computer can factorise large integers in polynomial time, breaking RSA. The same computer can solve the discrete logarithm problem, breaking elliptic-curve schemes (ECDH, ECDSA). Current quantum machines lack the necessary scale (the estimated threshold for breaking RSA-2048 is on the order of millions of logical fault-tolerant qubits), but the horizon is not indefinite.

The active risk already exists: the "harvest now, decrypt later" attack. State-level or well-funded adversaries can capture RSA/ECDH-encrypted traffic today and store it to decrypt when they have the quantum hardware. For data with 10-20 year lifecycles (classified communications, patents, financial data, medical records) the risk is real now, not in some abstract future.

Cryptographic transitions take 5-15 years in industry. Mission-critical systems, embedded hardware, software supply chains: everything needs time to update. Starting now is not alarmism. It is responsible risk management.

The three standards

FIPS 203: ML-KEM (Module-Lattice Key Encapsulation Mechanism)

ML-KEM is based on CRYSTALS-Kyber and replaces Diffie-Hellman and ECDH key exchange. It is not an encryption algorithm in itself; it is a key encapsulation mechanism: it generates a shared symmetric key between two parties without a passive observer being able to derive it. The full specification is in the official NIST FIPS 203 document[1].

Three variants with different security levels:

Variant Security level Public key size Ciphertext size
ML-KEM-512 ~128 classical bits 800 bytes 768 bytes
ML-KEM-768 ~192 classical bits 1,184 bytes 1,088 bytes
ML-KEM-1024 ~256 classical bits 1,568 bytes 1,568 bytes

The recommended choice for most applications is ML-KEM-768: it balances security and message size. ML-KEM-512 is for environments with severe bandwidth constraints; ML-KEM-1024 for cases requiring maximum security level.

FIPS 204: ML-DSA (Module-Lattice Digital Signature Algorithm)

ML-DSA is based on CRYSTALS-Dilithium and replaces RSA and ECDSA signatures. Digital signatures are used in TLS for server authentication, in code signing for software verification, in X.509 certificates and JWTs. ML-DSA has larger signatures than ECDSA but remains manageable, per the official FIPS 204 document[2]:

Variant Security level Public key size Signature size
ML-DSA-44 ~128 classical bits 1,312 bytes 2,420 bytes
ML-DSA-65 ~192 classical bits 1,952 bytes 3,293 bytes
ML-DSA-87 ~256 classical bits 2,592 bytes 4,595 bytes

For comparison: an ECDSA P-256 signature is 64 bytes. ML-DSA-44 is 2,420 bytes. This extra size has implications for protocols with MTU constraints (UDP, some TLS handshakes on low-MTU networks) that need attention during migration.

FIPS 205: SLH-DSA (Stateless Hash-Based Digital Signature Algorithm)

SLH-DSA is based on SPHINCS+ and offers a different mathematical basis from ML-DSA: security depends only on the properties of cryptographic hash functions, not on lattice problems. Its advantage is that it is extremely conservative: if a weakness were found in lattice-based schemes, SLH-DSA would remain secure. The official FIPS 205 document[3] covers the parameter detail.

The trade-offs are considerably larger signatures (from ~8 KB to ~30 KB depending on the variant) and slower signature generation. Its role is as a safety net: not the first choice for most applications, but its existence as an alternative reduces the systemic risk of relying on a single mathematical approach.

The fifth standard: HQC

In March 2025, NIST selected HQC (Hamming Quasi-Cyclic)[4] as its fifth PQC algorithm, an alternative KEM based on code theory rather than lattices. Its purpose is redundancy: if a weakness were found in ML-KEM, HQC provides an already-selected alternative, with a draft standard expected around 2026 and a final version estimated for 2027.

Available implementations

The good news is that implementations are already available before most teams need to migrate:

OpenSSL / BoringSSL: experimental ML-KEM support in TLS 1.3 via development branches. Chrome and Cloudflare already have hybrid TLS enabled[5] (X25519 plus ML-KEM-768) for a growing share of their connections.

Go: crypto/mlkem768 is landing in the stdlib. The Open Quantum Safe liboqs-go library is already available as an external dependency with every algorithm stabilised.

Rust: the pqcrypto crate covers ML-KEM and ML-DSA. Independent implementations such as kyber-rust and dilithium-rust are also available.

Python: pqcrypto bindings exist, but production use is still limited. For Python projects, the more robust path is calling OpenSSL via cryptography once support stabilises.

OpenSSH: since version 9.0 it has offered post-quantum key exchange by default (sntrup761x25519-sha512), and since 9.9 it adds mlkem768x25519-sha256, which version 10.0 made the default scheme, per the official OpenSSH PQC page[6].

Migration strategy: hybrid approach

Migrating directly from RSA/ECDH to pure ML-KEM means betting everything on a new cryptographic scheme that, despite years of public review, lacks RSA’s production track record. The recommended approach, also documented in practice around real-world PQC adoption in TLS, is the hybrid:

  • TLS 1.3 with X25519Kyber768Draft00: uses ECDH X25519 and ML-KEM-768 in parallel. To compromise the session, an attacker must break both. This is already active in Chrome and Cloudflare.

  • Signatures can migrate more gradually: ML-DSA can be combined with ECDSA in hybrid certificates during the transition period.

  • The move from hybrid to pure PQC will come when confidence in the new algorithms is sufficiently high and ecosystem support is universal.

Crypto-agility: the technical prerequisite

The most important lesson from NIST is not which algorithms to use, but how to design systems that can change algorithms. The most common anti-agility pattern:

BAD: RSA and SHA-256 hardcoded directly into application code
GOOD: interchangeable abstract "signer" and "encrypter" interface

A system with crypto-agility can migrate algorithms with a configuration or parameter change, without rewriting application logic. For teams managing infrastructure with TLS certificates via Trivy and security audits, crypto-agility is also an auditable property: inventorying hardcoded cryptographic primitives is the first step of the migration plan.

Concrete steps:

  • Inventory all cryptographic primitives hardcoded in code and configuration.

  • Abstract cryptographic usage behind interchangeable interfaces or libraries.

  • Choose libraries already adopting PQC (OpenSSL, BoringSSL, libsodium on its roadmap).

  • Key management: in line with the same secrets-management principles you already apply under zero trust, make sure the key management system supports algorithm rotation, not just key rotation.

Migration priority

Not everything requires the same urgency. Recommended order:

  • Long-lived secrets with harvest-now risk: classified data, sensitive IP, long-term customer financial data. High priority.

  • TLS at the edge: CDN, load balancers, TLS termination points. Hybrid approach already available; low risk to activate.

  • Code signing and certificates: PKI lifecycle makes migration slower; start the roadmap now.

  • VPN and SSH: WireGuard has PQC proposals; OpenSSH has shipped ML-KEM support in production since version 10.0. Follow vendor roadmaps.

  • Legacy systems: embedded hardware, industrial systems. Longer timelines; prioritise inventory.

Conclusion

NIST PQC represents the largest cryptographic change since RSA adoption four decades ago. The standards are published, implementations are arriving, and the "harvest now, decrypt later" risk is real for long-lived data today. The correct response is neither panic nor paralysis. It is to inventory, adopt the hybrid approach in already-available TLS, design systems with crypto-agility, and migrate in phases according to risk exposure.

Sources

  1. official NIST FIPS 203 document
  2. official FIPS 204 document
  3. official FIPS 205 document
  4. selected HQC (Hamming Quasi-Cyclic)
  5. Cloudflare already have hybrid TLS enabled
  6. official OpenSSH PQC page