Post-Quantum Cryptography for Developers: NIST's Final Standards and How to Migrate Before It's Urgent

Most developers treat cryptography as solved infrastructure. You use TLS, you use RSA or ECDSA for signatures, you use AES for symmetric encryption, and you do not think about it again. That assumption was reasonable for 20 years. It is becoming unreasonable now.

NIST published its first three post-quantum cryptography standards on August 13, 2024. A US Executive Order in June 2025 mandated that federal agencies begin migrating. NIST's transition guidance explicitly tells organisations to start moving as soon as possible — not when quantum computers arrive, but now.

The reason is the harvest now, decrypt later attack. State-level actors are actively collecting encrypted traffic today — VPN sessions, TLS connections, government communications — to decrypt later once sufficiently powerful quantum computers exist. For broader context on the quantum threat to current encryption, see quantum computing and the RSA threat. The encryption you use today to protect data that must remain confidential for 10+ years is already at risk.

What NIST Standardised

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

ML-KEM, based on the CRYSTALS-Kyber algorithm, is the primary standard for key encapsulation — the process by which two parties establish a shared secret over an untrusted channel. This replaces RSA and ECDH key exchange in TLS and similar protocols.

Three security levels are specified:

• ML-KEM-512: comparable to AES-128 security
• ML-KEM-768: comparable to AES-192 security (recommended default)
• ML-KEM-1024: comparable to AES-256 security

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

ML-DSA, based on CRYSTALS-Dilithium, is the primary standard for digital signatures — replacing RSA-PSS and ECDSA for code signing, document signing, and authentication protocols. It balances security and efficiency, making it the default recommendation for most signature use cases.

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

SLH-DSA is based on a completely different mathematical foundation from ML-KEM and ML-DSA — hash functions rather than lattice problems. Its security does not depend on any hardness assumption that could be invalidated by a mathematical breakthrough; it is secure as long as the hash function is secure. The tradeoff is larger signature sizes.

FIPS 206 — FN-DSA (FALCON-based signature algorithm)

FIPS 206, based on the FALCON algorithm, was submitted for final approval in August 2025 and is expected to be published in 2026. It produces significantly smaller signatures than ML-DSA, making it the preferred choice for bandwidth-constrained environments (IoT, mobile, high-frequency signing).

HQC — Fifth Algorithm (March 2025)

NIST standardised HQC (Hamming Quasi-Cyclic) in March 2025 as a backup key encapsulation mechanism using code-based cryptography — a completely different mathematical foundation from the lattice-based ML-KEM. This provides algorithmic diversity: if a breakthrough attack on lattice problems is discovered, HQC remains secure.

The Migration Mandate

Executive Order 14306 (June 6, 2025): Required CISA to publish lists of hardware and software product categories that must use PQC standards. Required federal agencies to begin inventorying their cryptographic dependencies.

NIST IR 8547: NIST's transition guidance. It describes the expected approach for migrating from quantum-vulnerable algorithms to PQC standards and sets deprecation timelines. The document explicitly discourages waiting — the recommendation is to begin migration immediately.

Deprecation timeline: NIST is expected to deprecate RSA, ECDSA, and ECDH for new deployments by 2030, and disallow them entirely by 2035. If your system has a 10-year lifespan, you need to begin migration planning now.

What Developers Need to Change

TLS and Key Exchange

The highest-priority migration for most developers. TLS 1.3 uses ECDH for key exchange — this needs to move to ML-KEM. The migration path:

• Hybrid key exchange is the recommended transition approach: use both X25519 (current) and ML-KEM-768 simultaneously. This protects against harvest-now-decrypt-later attacks while maintaining backward compatibility.
• OpenSSL 3.x supports ML-KEM and hybrid key exchange via the oqs-provider library
• BoringSSL (used by Chrome and Android) added ML-KEM support in 2024
• Cloudflare, Google, and Cloudflare already deploy hybrid post-quantum TLS on their edges

Code Signing and Authentication

If you sign software releases, Docker images, JWT tokens, or API responses with RSA or ECDSA private keys:

• Plan migration to ML-DSA for new signing keys
• Run dual-signing (sign with both ECDSA and ML-DSA) during transition
• Libraries: liboqs (Open Quantum Safe project) provides ML-DSA in C, Python, Java, and Go

Certificates and PKI

Certificate authorities are beginning to issue post-quantum certificates. Let's Encrypt and major commercial CAs have announced ML-DSA support timelines. Your internal PKI — if you run one — needs to be updated before migrating certificates.

Symmetric Encryption

AES-256 is quantum-resistant. AES-128 provides roughly half the security margin against quantum attacks (Grover's algorithm). If you are using AES-128, upgrade to AES-256. If you are already on AES-256, no change needed.

Password Hashing

Argon2, bcrypt, and PBKDF2 remain secure against quantum attacks. No migration needed.

The Practical Checklist

Immediate (do this now):

• Inventory all cryptographic primitives in your stack: what uses RSA, what uses ECDSA/ECDH, what uses ECC
• Identify which data your system protects that must remain confidential for more than 5 years
• Enable hybrid post-quantum TLS on any load balancer or reverse proxy that supports it (nginx with oqs-provider, Cloudflare, AWS ACM pending)

6–12 months:

• Test ML-KEM and ML-DSA in non-production environments
• Establish key lifecycle policies for PQC keys (these have different size/performance characteristics)
• Update internal documentation and security policies to reference FIPS 203/204/205

1–3 years:

• Migrate code signing to ML-DSA
• Move JWT and API authentication to PQC-safe algorithms
• Replace any internal PKI certificates with PQC-signed equivalents

Performance Implications for Developers

PQC algorithms have different performance profiles from RSA and ECC:

The main practical impact is larger key and signature sizes — ML-DSA signatures are roughly 50x larger than ECDSA. For most web applications, this is a rounding error in payload size. For bandwidth-constrained IoT devices or high-frequency signing operations, it needs to be planned for.

Libraries Available Today

• Open Quantum Safe (liboqs): C library with Python, Java, Go, and Rust bindings; implements all NIST PQC standards
• PQClean: C reference implementations of all NIST standards, audited and portable
• Bouncy Castle 2.x: Java/Kotlin library with full PQC support
• Go x/crypto: experimental PQC support via golang.org/x/crypto/mlkem
• Node.js: no native PQC support yet; use WebAssembly bindings to liboqs