NIST finalized its first three post-quantum cryptography standards — ML-KEM, ML-DSA, and SLH-DSA, published as FIPS 203, 204, and 205 — in August 2024. Two years later, the hard part isn't the math anymore. It's the plumbing: certificates, firmware, hardware security modules, and protocol stacks that were never designed to swap their cryptographic core.
According to MIT Tech Review, that shift — from picking an algorithm to actually rolling it out — is where most organizations are now stuck, and it's a far messier problem than the initial standardization process suggested.
For teams building AI products, this isn't a compliance footnote to skim past. API traffic, stored model weights, embeddings, and years of retained customer prompts are exactly the kind of long-lived, high-value data that "harvest now, decrypt later" attacks are designed to exploit: an adversary captures encrypted traffic today and waits for a quantum computer capable of breaking RSA or elliptic-curve keys to decrypt it later.
Why the clock is already running
The urgency isn't about a quantum computer existing tomorrow. It's about data with a long confidentiality shelf life. Anything encrypted today with RSA-2048 or ECDSA that still needs to be secret in 10-15 years is already exposed to a future break, regardless of when a cryptographically relevant quantum machine actually arrives.
That math is why the NSA's CNSA 2.0 timeline pushes federal contractors toward PQC-only signing and firmware by 2030, and full transition by 2033, and why browser vendors moved early: Chrome and Cloudflare both shipped hybrid post-quantum key exchange (classical X25519 combined with ML-KEM) in production TLS well before the NIST standards were finalized, precisely to start hedging that exposure now rather than later.
- ML-KEM (formerly Kyber) — key encapsulation, replaces RSA/ECDH for establishing shared secrets
- ML-DSA (formerly Dilithium) — digital signatures, replaces RSA/ECDSA for most general use
- SLH-DSA (formerly SPHINCS+) — a conservative, hash-based signature scheme kept as a backup in case lattice-based math is ever broken
What "practical" actually means once you start migrating
The obstacle isn't ignorance of which algorithm to use — it's that the new ones don't behave like the old ones. ML-KEM public keys and ciphertexts run roughly 3-6x larger than an equivalent ECDH exchange. SLH-DSA signatures can run into the tens of kilobytes versus 64-96 bytes for ECDSA. Protocols, hardware tokens, and embedded devices that hard-coded assumptions about handshake size or certificate length break in ways that are tedious, not exotic, to fix.
That's why the operative strategy right now is hybrid, not a clean cutover: pair a classical algorithm with a post-quantum one in the same handshake, so a flaw in either the new lattice-based math or the old elliptic-curve math alone doesn't compromise the connection. It's also why "crypto-agility" — designing systems so the cryptographic primitive is a swappable configuration, not a value baked into the code — has become the actual engineering discipline organizations are investing in, ahead of any specific algorithm choice.
What this means for teams building AI systems
Most AI teams don't own their own TLS stack — they inherit it from cloud providers, API gateways, and certificate authorities. That changes where the leverage is:
- Inventory before you panic. Find where RSA/ECC actually sits in your stack: TLS termination points, code-signing for model artifacts, VPNs, HSMs, and any embedded or edge inference hardware with fixed cryptographic firmware.
- Prioritize by data lifetime, not by system criticality. Training corpora, customer prompt logs, and proprietary embeddings that need to stay confidential for a decade are a higher migration priority than a low-sensitivity internal dashboard, even if the dashboard is "more important" operationally.
- Watch for library and vendor support rather than building it yourself. OpenSSL 3.2+ and BoringSSL already support hybrid ML-KEM key exchange; cloud providers and CAs are rolling out PQC certificate options on their own timelines. Piggybacking on that is far cheaper than a custom implementation.
- Test for size regressions early. Edge and on-device inference setups with tight handshake or payload budgets are the most likely place a larger PQC key or signature quietly breaks something.
AiiN's takeaway
The standards question is settled; the rollout question is now the whole game, and it will likely be paced more by infrastructure vendors than by individual application teams, in our estimation. For AI companies specifically, the practical move isn't rewriting cryptography — it's mapping which of your systems hold data with a decade-plus confidentiality requirement, and making sure your vendors have a stated PQC timeline before you need one.