After eight years of evaluation, the National Institute of Standards and Technology (NIST) has officially published its first three finalized post-quantum cryptography (PQC) standards. FIPS 203 (ML-KEM, based on CRYSTALS-Kyber), FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium), and FIPS 205 (SLH-DSA, based on SPHINCS+) are now official standards, ready for implementation.
If you’ve been treating quantum computing as a distant theoretical concern — and I’ll admit I was in that camp for years — this announcement should recalibrate your timeline. When NIST finalizes standards, it means the migration clock is ticking.
Why This Matters Now#
The common objection I hear is: “Quantum computers can’t break current encryption yet, so why worry?” The answer is a concept called “harvest now, decrypt later.” Adversaries — state-sponsored and otherwise — are already intercepting and storing encrypted traffic today, with the expectation that future quantum computers will be able to decrypt it.
If you’re handling data that needs to remain confidential for more than 10-15 years (medical records, financial data, government communications, long-lived signing keys), the data you’re encrypting today with RSA or ECDSA might be readable in the future. That’s not science fiction; it’s the explicit threat model that drove NIST to begin this standardization process back in 2016.
Understanding the Three Standards#
Let me break down what was actually standardized, because the naming has been confusing throughout this process:
FIPS 203 — ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) This is your replacement for key exchange. Where you currently use ECDH or RSA key exchange in TLS, SSH, and VPNs, ML-KEM is the post-quantum alternative. It’s based on the mathematical hardness of lattice problems, which are believed to be resistant to quantum attacks. Key sizes are larger than what we’re used to — ML-KEM-768 public keys are 1,184 bytes compared to 32 bytes for X25519 — but the performance is actually quite reasonable.
FIPS 204 — ML-DSA (Module-Lattice-Based Digital Signature Algorithm) This replaces RSA and ECDSA for digital signatures. Think code signing, certificate authorities, JWT tokens, and software updates. Again, larger key and signature sizes, but computationally fast. ML-DSA-65 signatures are 3,309 bytes versus 64 bytes for Ed25519.
FIPS 205 — SLH-DSA (Stateless Hash-Based Digital Signature Algorithm) This is a more conservative alternative for signatures, based on hash functions rather than lattice mathematics. It’s slower and produces larger signatures, but its security relies on the well-understood properties of hash functions. Think of it as the “belt and suspenders” option.
Practical Impact for Developers#
Here’s what I’d be thinking about if I were planning a migration (and I am):
TLS and HTTPS: The good news is that most of this will be handled by your TLS library and infrastructure. OpenSSL, BoringSSL, and other libraries are already adding PQC support. Chrome and Firefox have been experimenting with hybrid key exchange (combining classical and post-quantum algorithms) for over a year. Your HTTPS connections may already be partially post-quantum without you knowing it.
SSH: OpenSSH 9.0 already defaults to a hybrid key exchange that includes a post-quantum component. If you’ve updated your SSH installations recently, you might already be covered for key exchange (though not yet for authentication).
Application-level cryptography: This is where most developers will need to do actual work. If your application directly uses cryptographic libraries for encryption, signing, or key exchange — think JWT libraries, message encryption, document signing — you’ll need to plan a migration path.
Certificate infrastructure: This is the hard part. The entire PKI ecosystem — certificate authorities, certificate chains, OCSP — needs to transition. Larger certificates mean more bandwidth, and some constrained environments (IoT devices, embedded systems) may struggle with the increased sizes.
The Migration Strategy#
Don’t panic, but do start planning. Here’s a reasonable approach:
Inventory your cryptographic dependencies. Know where you’re using RSA, ECDSA, ECDH, and AES (AES-256 is already quantum-resistant for symmetric encryption, by the way).
Adopt crypto-agility. Design your systems so that swapping cryptographic algorithms doesn’t require a complete rewrite. Abstract your crypto behind interfaces.
Start with hybrid approaches. Use both classical and post-quantum algorithms simultaneously. This protects you against quantum threats while maintaining security if the new algorithms turn out to have weaknesses.
Watch your library ecosystem. Most major cryptographic libraries will handle the heavy lifting. Keep them updated.
My Take#
I’ve been through enough cryptographic transitions — from DES to AES, from SHA-1 to SHA-256, from RSA-1024 to RSA-2048 — to know that these things always take longer than expected. Organizations that start planning now will be fine. Organizations that wait until quantum computers are actually breaking things will be scrambling.
The NIST standardization is the starting gun. You don’t need to sprint, but you should be lacing up your shoes. Start with an inventory of your cryptographic dependencies, adopt hybrid approaches where your libraries support them, and design for crypto-agility going forward. Your future self — and your future users — will thank you.