NIST PQC: The Post-Quantum Cryptography Standards

Actualizado: 2026-05-03

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 — it 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 + 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 a key encapsulation mechanism: it generates a shared symmetric key between two parties without a passive observer being able to derive it.

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 — ML-DSA-44 is 2,420 bytes vs 64 bytes for ECDSA P-256 — which has implications for protocols with MTU constraints.

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. 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.

Migration strategy: hybrid approach

The recommended approach 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 with hybrid certificates during the transition period.
• The move from hybrid to pure PQC will come when confidence in 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. A system with crypto-agility can migrate algorithms with a configuration change, without rewriting application logic.

Concrete steps:

1. Inventory all cryptographic primitives hardcoded in code and configuration.
2. Abstract cryptographic usage behind interchangeable interfaces or libraries.
3. Choose libraries already adopting PQC (OpenSSL, BoringSSL, libsodium roadmap).
4. Key management: ensure the key management system supports algorithm rotation, not just key rotation.

Migration priority

Not everything requires the same urgency. Recommended order:

1. Long-lived secrets with harvest-now risk: classified data, sensitive IP, long-term customer financial data. High priority.
2. TLS at the edge: CDN, load balancers, TLS termination points. Hybrid approach already available; low risk to activate.
3. Code signing and certificates: PKI lifecycle makes migration slower; start the roadmap now.
4. VPN and SSH: WireGuard has PQC proposals; OpenSSH has experimental ML-KEM support. Follow vendor roadmaps.
5. 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: inventory, adopt the hybrid approach in already-available TLS, design systems with crypto-agility, and migrate in phases according to risk exposure.