Final NIST PQC standards: what to do with them now
Updated: 2026-07-07
In August 2024, NIST published the three final post-quantum cryptography standards:
-
FIPS 203 (ML-KEM, based on CRYSTALS-Kyber)
-
FIPS 204 (ML-DSA, based on CRYSTALS-Dilithium)
-
FIPS 205 (SLH-DSA, based on SPHINCS+)
Six months on, the headline is no longer news, and it’s time to turn it into a plan. This post collects what I’ve seen work and not work in teams starting the transition.
Key takeaways
-
There isn’t yet a quantum computer capable of breaking RSA-2048. The real risk today is "harvest now, decrypt later": adversaries capture encrypted data today to decrypt later.
-
The first step is the most ignored: honest crypto inventory in layers (external communications, internal PKI, data at rest, vendors).
-
The most frequent mistake is swapping algorithms one-by-one instead of building crypto-agility: architectures that let you change the algorithm without rewriting the application.
-
The tactic that has settled in serious deployments: hybrid algorithms (ECDHE + ML-KEM) for external communications, classical cryptography elsewhere for now.
-
PQC signatures (ML-DSA, SLH-DSA) are orders of magnitude larger than ECDSA: an X.509 certificate with ML-DSA grows from 1-2 KB to 4-6 KB.
Order of magnitude first
There isn’t yet a quantum computer capable of breaking RSA-2048 or ECDSA P-256. Serious estimates of when there will be range from a decade to never. But patient adversaries can capture data today and decrypt it tomorrow: that is "harvest now, decrypt later." For data with long-term value, the transition isn’t optional.
The inventory almost nobody has
The first step is the most boring and ignored: knowing where cryptography lives in your organization. Not just TLS on public websites. It includes: VPN between offices, client certificates on IoT machines, firmware update signatures, JWT in internal APIs, at-rest encryption in databases, SSH keys on admin servers, S/MIME signed mail, audit log integrity.
The sensible approach is to tackle it in layers: external communications first, then internal infrastructure, then at-rest data with long retention, then vendor integrations.
A useful tool to start: CBOMkit[1], IBM Research’s open-source toolkit that generates and analyzes crypto inventories (CycloneDX format) for Java and Python applications, alongside the community scripts published for analyzing X.509 certificates.
Crypto-agility before crypto-correct
The most frequent mistake is wanting to swap algorithms one by one. Patch an application with ML-KEM and leave the rest. It produces a tick on a report, but it’s usually a mistake.
The more productive conversation is about crypto-agility. Instead of asking "which algorithm do we use?", ask "how do we change the algorithm without rewriting the application?" That forces reviewing: where the crypto provider is instantiated, whether on-disk and on-wire formats carry algorithm identifiers, whether configuration is externalized, whether there are compatibility chains for reading old ciphertext while writing new.
A well-designed crypto-agile system today absorbs the first PQC transition without drama, and will also absorb a second when current algorithms show weaknesses.
Hybrids outside, classical inside
The tactic that has settled in serious deployments is using hybrid algorithms in key-exchange for communications, and leaving the rest on classical cryptography for now. A hybrid combines classical ECDHE with ML-KEM in the same negotiation, so an attacker needs to break both.
Cloudflare, Google, and AWS already support hybrids on their TLS edges: by October 2025, more than half of human-initiated TLS traffic on Cloudflare’s network[2] already used the X25519MLKEM768 hybrid exchange. And OpenSSH 9.9[3] added the ML-KEM hybrid (mlkem768x25519-sha256) in 2024, alongside the NTRU Prime hybrid (sntrup761x25519) it already had.
For at-rest symmetric encryption, no urgency: AES-256 remains secure against quantum adversaries under Grover’s algorithm, which reduces effective security to 128 bits: still reasonable.
Sizes, latencies, budgets
PQC standards aren’t drop-in. Signature and key sizes are orders of magnitude larger than classical algorithms. An X.509 certificate with ML-DSA grows from 1-2 KB to 4-6 KB. A full TLS chain with three post-quantum certificates approaches 20 KB. On slow links (cellular IoT, satellite) this shows.
A timeline that makes sense
-
First quarter: honest crypto inventory.
-
Second quarter: enable hybrids on TLS at every balancer and outgoing mail when the partner supports it.
-
Second half: review internal PKI and plan a post-quantum hierarchy for 2026-2027, without rushing.
-
In parallel: adopt crypto-agility as a requirement in all new code.
Mid-term, regulators will push. Germany’s BSI has had recommendations since 2020[4], France’s ANSSI moved in 2022[5] with a three-phase roadmap, the US NSA’s CNSA 2.0[6] sets staged milestones through full compliance in 2035, and ENISA published a 2024 integration study[7] several governments now use as a reference.
How to think about the decision
The most valuable thing I’ve learned is that the post-quantum transition is a perfect excuse to do something you already needed: clean up your organization’s cryptography. Most teams starting today discover during inventory forgotten RSA-1024 keys, SHA-1 certificates, outdated libraries, or hardcoded secrets. PQC comes after; the prior cleanup is what actually raises security.
Treating it as a compliance project with a date and a tick works but is expensive and fragile. Treating it as an opportunity to invest in crypto-agility, crypto hygiene, and documentation pays off more.
And if your reaction is "we’ll leave it for when a quantum computer appears," remember harvest now, decrypt later. For legal acts, medical records, trade secrets, or diplomatic communications, the transition isn’t optional. It’s a matter of dates.
This article is also available in Spanish: Estándares NIST PQC finales: qué hacer con ellos ahora.
