Post-Quantum Cryptography Migration for AI Inference APIs

AI inference APIs are moving into a security window that most teams haven't priced in yet: the encrypted traffic they ship today, model outputs, embeddings, agent reasoning traces, token-bearing credentials, can be captured now and decrypted later once quantum computers catch up. This piece works through what that actually means for teams running inference at scale, how much runway is left, what the finalized NIST standards do and don't cover, what the real performance cost looks like, and how to build the inventory work that has to happen before any migration code gets written.

Worth saying up front why this differs from a generic HTTPS migration. Agentic workloads break the assumptions classical access control was built on: an agent runs continuously, touches a few dozen internal services in a session, and never logs out the way a person does. Every tool call, every MCP connection, every agent-to-agent handoff is a place where traffic can be intercepted with almost no monitoring, and that's a structural gap, not a configuration mistake somebody can patch. MCP itself is stateful and holds context over long sessions, so the stateless-REST gateways most shops already have can't inspect what's actually flowing through it. And even when an agent's own credential is something ordinary, like a symmetric API key, it still rides on a TLS handshake and issuer-signed tokens that remain protected by classical math, so the exposure doesn't go away just because the credential looks simple.

Layer onto that the credential hygiene problem already sitting inside most agentic stacks: keys that don't rotate, algorithms hard-coded years ago, dependency chains nobody's mapped end to end. A 2026 CSA survey of AI-agent security found that a third of organizations didn't know how often their agent credentials rotate at all. That's not a rounding error. It means the long-lived-key problem is often invisible before a migration team even starts scoping the work, which is exactly why a "just swap in the new algorithm" approach falls apart here: the attack surface, the sensitivity of the data, and the architecture itself all look different than they do in a standard TLS migration.

What "Harvest Now, Decrypt Later" means when the harvested traffic is AI inference

The mechanics are simple enough to state in one line: an adversary grabs encrypted traffic today, sits on it, and decrypts it once a cryptographically relevant quantum computer exists. It's a passive attack. Nobody gets a log entry that says "this session got copied." An organization has no way to know, right now, whether its inference traffic is already sitting in someone's archive waiting for the right hardware to show up.

AI cuts both ways in this story. On one side, it makes bulk collection more useful, because a model can triage stolen ciphertext by likely value without needing to crack it first, prioritizing what looks like it's worth decrypting later. On the other side, inference traffic is itself the kind of high-value ciphertext worth collecting: reasoning chains embedded in outputs, training data moving between systems, checkpoint signatures on proprietary models. All of it still travels over classically protected channels today.

There's a second failure mode that gets less attention: Harvest Now, Forge Later. Signed material captured today, agent credentials, CA signing keys, model-checkpoint signatures, provenance attestations, becomes forgeable once a quantum computer can break the signature scheme that produced it. That's not a confidentiality problem. It's an authenticity problem, and it means someone could, years from now, forge a signature on a model checkpoint or an agent credential using material stolen from a session that already happened.

Which categories of data actually need to survive into the 2030s untouched? Long-lived intellectual property that surfaces through model queries, health records processed by inference endpoints, proprietary weights moving between training and serving infrastructure. Per the Thales 2026 Quantum & AI Threat Report, which surveyed 3,120 security and IT professionals across 20 countries, Harvest Now Decrypt Later is the top quantum concern, cited by 61% of respondents, and 98% now factor in how AI and quantum computing interact when they think about risk. DHS, the UK's NCSC, ENISA, and the Australian Cyber Security Centre have all put out guidance that starts from the same premise: sophisticated adversaries are collecting encrypted traffic right now, not someday. Which raises the obvious question for anyone planning a migration: if the clock started when collection started, not when a quantum computer gets built, how much runway is actually left?

How close quantum hardware actually is and what that means for migration windows

Google's Willow chip crossed a real threshold in December 2024, achieving below-threshold quantum error correction, a milestone people in the field have been chasing for years because it's a prerequisite for fault-tolerant computing at scale. IonQ has published roadmaps pointing to cryptographically relevant trapped-ion systems by 2028. And the resource estimates for the attack circuits that would actually break RSA or elliptic-curve cryptography have dropped by something like an order of magnitude as qubit counts rise and error correction improves.

None of that means a cryptographically relevant quantum computer lands on a specific date. Nobody serious is claiming that. But here's the piece that should worry a CISO more than any hardware roadmap: large enterprises typically need something like 12 to 15 years to complete an infrastructure migration of this size and complexity. If fault-tolerant quantum computing shows up anywhere in the 2028 to 2030 window, and an organization starts its migration in 2025, there's a multi-year stretch where meaningful chunks of infrastructure remain protected by algorithms that are, by then, breakable. AI inference stacks sit right in the middle of that gap: they change fast, they carry data worth stealing, and they're often the last systems to get touched in a broader security overhaul because they're seen as product infrastructure rather than security infrastructure.

The point isn't to pin down a CRQC arrival date. It's that the risk is active today and the fix takes years, and that mismatch is exactly why the standards NIST finalized in 2024 function less like a planning document and more like a starting gun.

The NIST finalized standards and what each one does in an inference API context

NIST finalized three standards in August 2024, and each one does a distinct job.

FIPS 203, called ML-KEM and built from CRYSTALS-Kyber, is a key encapsulation mechanism: the algorithm that protects the session key during a TLS handshake. This is the main tool for securing the connection an inference API actually runs over. FIPS 204, ML-DSA, built from CRYSTALS-Dilithium, is a lattice-based signature scheme, relevant anywhere something needs signing: API tokens, model-checkpoint provenance records, agent credentials, certificate chains. FIPS 205, SLH-DSA, built from SPHINCS+, is a stateless hash-based signature scheme whose security rests on hash function properties rather than lattice math, making it a conservative fallback with a genuinely different risk profile than the other two.

There's a fourth piece still in motion. NIST picked HQC, Hamming Quasi-Cyclic, in March 2025 as a backup key encapsulation mechanism, with a draft standard expected in early 2026 and a final version in 2027. Teams thinking seriously about long-term crypto agility should have this on their radar even though it's not locked yet.

Mapped onto an inference API stack, the division of labor looks like this: ML-KEM protects the confidentiality of requests, responses, and embeddings moving in transit. ML-DSA protects authenticity, covering signed JWTs, model artifact signatures, and agent identity assertions. SLH-DSA earns its place where algorithm diversity matters more than raw speed, think root CA keys or long-lived signing keys tied to model provenance, where you want a fallback that doesn't share failure modes with the lattice-based schemes.

The regulatory calendar backs this up with real dates. NIST IR 8547, published in November 2024, deprecates RSA, ECDSA, and ECDH after 2030 and disallows them in federal systems outright after 2035. The NSA's CNSA 2.0 policy sets a 2030 deadline for national security systems. The EU requires organizations to have transition plans in place by 2026 and full implementation in high-risk sectors by 2030. Treat 2030 as the wall, not the target: the actual engineering work needed to clear that wall is what makes 2025 and 2026 the right window to start.

The actual performance cost of PQC on high-frequency inference API traffic

Here's the number that tends to alarm people first: hybrid key exchange using ML-KEM-512 alongside classical X25519 pushes mean connection time from 24.7 milliseconds to 30.4 milliseconds, about a 23% increase in connection establishment time. Read in isolation, that sounds like a real problem for a high-frequency API.

It isn't, once you look at where that overhead actually lands. It's a connection-establishment cost, not a per-request compute cost, so anything that reuses connections, keep-alive, HTTP/2 multiplexing, connection pooling, dilutes it heavily. Inference calls themselves typically run anywhere from 100 milliseconds to several seconds; a one-time handshake addition of 5 to 6 milliseconds barely registers against that baseline. AWS has published its own measurement putting the added cost at roughly 1,600 bytes of extra handshake data and 80 to 150 microseconds of additional compute per handshake. That's not nothing at scale, but it's not the kind of number that breaks a production system either.

Where does it actually bite? Services handling huge volumes of short-lived connections, CDNs, token endpoints, will see handshake bandwidth show up as a real line item in capacity planning. But even a service processing tens of millions of TLS connections a day should be able to absorb that within existing infrastructure headroom, assuming someone's actually planned for it rather than discovering it in production.

Algorithm choice matters more than people expect here. ML-KEM completes its key operations in microseconds on ordinary commodity hardware, which is why it's the default recommendation for latency-sensitive endpoints. HQC, the backup KEM NIST is still finalizing, runs in milliseconds, with key generation as the slowest step, which makes it a poor primary choice anywhere latency matters even if it earns a role later as a fallback for diversity. On the signature side, hybrid certificates add something like a few percent overhead compared to PQC-only variants, which tells you signatures aren't where the real bottleneck lives.

The actual constraint shows up at the edge: IoT-adjacent inference hardware in manufacturing or healthcare settings often doesn't have the memory or processing headroom to handle the larger key and signature sizes PQC requires, and no software update fixes that. That's a hardware replacement problem, not an engineering problem you can solve with better connection pooling. For most inference API deployments, though, the overhead is solvable, provided the team makes explicit decisions about pool sizing and session resumption rather than inheriting whatever defaults came with the classical setup.

Why hybrid-mode deployment is the right default during the transition and how it works mechanically

As of 2026, the consensus across the industry is to run PQC alongside classical algorithms in a combined construction, not to rip out classical crypto and replace it outright. Mechanically, a hybrid TLS 1.3 handshake runs two key exchanges side by side, one classical, typically X25519, and one post-quantum, typically ML-KEM-768. The two results get combined cryptographically into the final shared secret. An attacker has to break both algorithms to compromise the session; breaking either one alone gets them nothing.

Why is this the right call rather than a stopgap? A few reasons stack up. Hybrid mode keeps backward compatibility with endpoints that haven't added PQC support yet. It gives immediate protection against Harvest Now, Decrypt Later for traffic captured today, since the quantum-resistant half of the handshake doesn't get weakened by pairing it with the classical half. And it gives teams a rollback path: if a flaw turns up in one of the PQC algorithms, and given how new these are, that's not a fantasy scenario, the classical component is still there as a floor. The IETF has already standardized hybrid key exchange for TLS 1.3, so this isn't an improvised workaround; it's a documented, interoperable approach teams can build against with confidence.

What does "available now" actually look like in production? Cloudflare reported that, as of mid-September 2025, roughly 43% of human-generated connections to its network were already running hybrid post-quantum key agreement, and the company has committed to making its whole platform quantum-resistant by 2029. AWS has made ML-KEM the default hybrid algorithm and is pulling CRYSTALS-Kyber-only endpoints across its services during 2026. Microsoft shipped ML-KEM and ML-DSA in production across Azure, Microsoft 365, Windows 11, and Windows Server 2025 following a SymCrypt update in November 2025. Apple's PQ3 protocol has had ML-KEM running inside the ongoing ratchet that protects forward secrecy in iMessage since iOS 17.4, not just at the start of a session but continuously through it.

There's a nuance worth sitting with here: public post-quantum certificates aren't likely to be broadly trusted across all client software before 2027, so the certificate layer moves slower than the handshake layer. Internal PKI is a different story. Private certificate authorities can issue ML-DSA certificates today, through DigiCert's private CA, AWS Private CA (which went GA in November 2025), or OpenSSL 3.5 and later with the OQS provider. For a team running an API gateway, that distinction should shape sequencing: internal service-to-service traffic can move to PQC signing now, while public-facing certificate trust catches up on its own timeline.

Underneath all of this sits the principle of crypto agility: building systems so an algorithm can be swapped out without re-engineering everything around it. NIST's CSWP 39 documents current approaches to getting there, and it's worth reading before locking in any architecture, because the algorithm you pick in 2026 is not guaranteed to be the one you're running in 2030.

Building the cryptographic inventory before writing a single line of migration code

None of the above matters if a team doesn't know what it's protecting. OMB M-23-02 requires federal agencies to keep a cryptographic inventory and produce a migration plan, and that discipline is worth adopting even outside government work, because migrating blind is how projects stall six months in.

For an inference API, the inventory needs to cover every TLS termination point: load balancers, API gateways, service mesh sidecars, the model-serving endpoints themselves. It needs every signing operation: JWT issuance, model-checkpoint signatures, agent credential assertions, mTLS certificate chains. It needs the full key lifecycle, where keys get generated, how they're stored, when they rotate, who's responsible for rotating them, and, critically, which of those answers come back as "we don't actually know." Remember that a third of organizations in the 2026 CSA survey couldn't answer the rotation question for their agent credentials; if that's true at your shop, the inventory is the thing that surfaces it before it becomes a migration blocker. Library and SDK versions matter too: which OpenSSL, BoringSSL, or language-native TLS stack is running where, and which of those already support ML-KEM and ML-DSA natively versus needing a provider plugin bolted on.

AI-specific stacks carry inventory items a standard TLS audit won't catch. Agent credential rotation schedules, or the absence of one. MCP and agent-to-agent channels that route around the standard API gateway entirely, invisible to whatever monitoring the security team thinks is comprehensive. Model artifact signing chains, meaning who signed the weights, with what key, and how that provenance actually gets checked at inference time. Long-lived tokens sitting in orchestration configs or environment variables that nobody's looked at since the service was stood up.

Tooling exists to make this less painful: automated cryptographic bill-of-materials scanners, network traffic analysis that fingerprints handshakes in the wild, static analysis across dependency graphs. NIST's NCCoE Migration to PQC project has published reference architectures for running this kind of inventory at enterprise scale, and it's a reasonable place to start rather than building the process from scratch.

The output of this work is what determines sequencing in the phase after it: not every endpoint deserves the same priority, and data sensitivity, connection lifetime, and external exposure are the three variables that should decide what moves first. Meta's own PQC migration framework, built for infrastructure at a comparable scale, follows the same logic, inventory first, prioritization second, algorithm swap last. That ordering isn't a suggestion. It's the difference between a migration that holds up in production and one that breaks something nobody thought to check.