Post-Quantum Cryptography Migration 2026: ML-KEM, ML-DSA, Hybrid TLS Architecture

Q: What is harvest-now-decrypt-later and why does it matter today even before quantum computers exist?

Harvest-now-decrypt-later (HNDL) is the adversary strategy of capturing encrypted traffic today and storing it for decryption when a sufficiently capable quantum computer arrives, expected in the early 2030s based on roadmaps from IBM, Google, and the broader cryptanalysis community. Any data with a confidentiality lifetime longer than the gap between today and the quantum window is at risk now, not later. The clearest examples are healthcare records (decades of liability), legal archives (statutory retention 7 to 30 years), intellectual-property exchanges (R’n’D, model weights, source code), identity assertions used in archived audit trails, and government-classified communications. The defensive posture in 2026 is to migrate the wire and the long-lived signed artefacts before the harvest window closes; what is captured today and not yet migrated is decryption fodder regardless of when you finish the rollout. The corollary is that there is no point in starting the migration the day a quantum computer is announced — by then the captured corpus is already a decade large. NIST published the post-quantum standards in August 2024 specifically to give organisations a five-to-eight-year runway to migrate before the threat materialises.

Q: Should I roll out pure ML-KEM-768 or hybrid X25519+ML-KEM-768 for TLS handshakes?

Hybrid is the correct production choice in 2026 across every public deployment that has shipped at scale: Cloudflare, Google Chrome, Apple iMessage PQ3, AWS KMS. The hybrid construction runs both classical X25519 and post-quantum ML-KEM-768 in parallel, concatenates the two shared secrets, and feeds the concatenation through the TLS 1.3 key schedule. The protection is preserved if either algorithm holds: a future cryptanalysis result against ML-KEM does not unlock the session because the X25519 half still protects, and a quantum computer breaking X25519 does not unlock the session because the ML-KEM half still protects. The cost is small: roughly 1 to 1.5 KB of additional ClientHello size and sub-millisecond computation on commodity CPUs. Pure ML-KEM-768 is defensible for internal east-west traffic where you control both endpoints and the operational risk of a future PQ-side surprise is acceptable, but most production teams will not save anything meaningful by skipping the hybrid half and will lose the defence-in-depth property. The IETF draft `draft-ietf-tls-hybrid-design` codifies the construction and assigns the code points (X25519MLKEM768) that OpenSSL 3.5, BoringSSL, and Rustls negotiate.

Q: How big is the handshake size impact and when does it actually break things in production?

An ML-KEM-768 public key is 1184 bytes and a ciphertext is 1088 bytes, which translates to roughly 1 to 1.5 KB of ClientHello growth on the hybrid TLS handshake. On any non-pathological link this is invisible. Where it becomes a real failure mode is when the ClientHello crosses the typical 1500-byte MTU and gets fragmented across multiple TCP segments. A small but real fraction of internet paths — documented in Chrome’s field-data telemetry during the 2024 PQC rollout — contain middleboxes (corporate firewalls, ISP-side DPI, antiquated load balancers) that fail closed on fragmented ClientHellos or strip unknown TLS extensions. The mitigation is twofold: keep the ClientHello compact by removing spurious extensions and ordering cipher-suites carefully, and instrument the handshake-failure rate per region per ISP so the auto-fallback can flip back to classical-only when post-quantum failure rate exceeds a threshold (a sensible default is 0.1 percent of attempts in a five-minute window). Cloudflare and Google’s deployments use exactly this pattern, and the rollback flag is the production-safety primitive that converts a one-shot algorithm change into a steady-state capability. On constrained radio links (under 9.6 kbps satellite or LoRaWAN-class IoT) the bandwidth cost is meaningful and the architecture decision is whether to defer those devices until hardware refresh or run classical-only there with a documented exception.

Q: When should I use SLH-DSA instead of ML-DSA for signatures?

Use SLH-DSA-128s when the threat model demands a conservative algorithm whose security rests only on hash-function pre-image resistance, with no reliance on lattice problems or any other novel cryptographic assumption. The canonical use cases are firmware roots of trust on hardware with 20-year operational lifetimes, hardware boot certificates, and any signed artefact whose verification must survive an unexpected cryptanalysis result against the lattice family. The cost is signature size: SLH-DSA-128s signatures are roughly 7856 bytes versus ML-DSA-65 signatures at 3293 bytes versus Ed25519 at 64 bytes. For everything else — code signing, container-image signing, model-weight provenance, software-update manifests, document e-signing, long-lived JWT and SAML — ML-DSA-65 is the right default. ML-DSA is faster to verify, smaller on the wire, well-supported across the post-quantum tooling ecosystem, and rests on the well-studied learning-with-errors family that has had a decade of public cryptanalysis. The pragmatic 2026 split is ML-DSA for the bulk of signed artefacts, SLH-DSA reserved for the deepest-trust hardware-and-firmware tier where conservative algorithm diversity earns its bandwidth cost.

Q: How do I migrate code-signing pipelines without breaking the verifier fleet?

Adopt a dual-signing transitional period. The artefact carries both a classical signature (Ed25519 or RSA) and an ML-DSA-65 signature; the verifier fleet is upgraded to accept either; once the verifier fleet is fully migrated the classical signature is dropped from the signing side. The Linux Foundation Model Signing project, Sigstore, in-toto, and Notation have all been adding ML-DSA support during 2024 to 2026, so the signer-side change is mostly a configuration flip in modern tooling. The verifier-side migration is the longer pole because it is the consumer of the signed artefact: every operating-system package manager that verifies signatures, every container runtime that verifies image signatures, every device that verifies a software update, every CI gate that checks Sigstore policy, every regulator that checks document signatures. A reasonable transitional period is 18 to 30 months, gated on telemetry that shows the verifier population has converged on ML-DSA support. Skipping the dual-signing window is the named anti-pattern of "migrate the signer first and break the verifiers" — a signed artefact that no consumer can verify is a brick. The same dual-publish discipline applies to JWT-issuing services, SAML IDPs, and notary chains: emit both signature families during the transition, drop the classical family only when the consumer-side telemetry says it is safe.

Q: What does the crypto-agility control plane minimally need to ship in 2026?

Four cooperating services, each small enough for a two-person team to ship in a quarter. First, an inventory service that maintains the canonical list of cryptographic surfaces — every TLS endpoint, every KMS key, every signing pipeline, every embedded device class — with current algorithm, parameters, lifetime, and dependent consumers. Source of truth is one Postgres table or a graph database, fed by automated discovery (cloud-provider API scrapes, CI introspection, agent-based device reporting) reconciled against a manual register. Second, a policy service that answers "given this surface, which configurations are permitted today" using Rego or CEL, referencing inventory attributes plus regulator profiles (CNSA 2.0, BSI TR-02102, ANSSI, JCMVP). Third, an enforcement layer that wires policy to the wire — sidecars or library hooks for TLS, KMS wrapper for key wrap, CI gates for signing, OTA pre-flight for embedded fleets. Fourth, a telemetry layer with OTel attributes (`tls.protocol_version`, `tls.kex_group`, custom `pq.kex_algorithm` and `pq.parameter_set`) that drives both the migration progress dashboard and the auto-fallback that protects production. None of these is novel infrastructure; the work is wiring them together and emitting consistent telemetry. Without the plane, every algorithm change becomes a multi-quarter archeology project across an estate nobody has fully inventoried since 2019.

Q: How does post-quantum migration affect AI and LLM workloads specifically?

AI systems concentrate exactly the long-lived, high-value, signature-heavy artefacts that PQC is built to protect, which is why the 2026 AI security architecture playbook treats PQC as foundational rather than peripheral. Model weights are signed artefacts and the Linux Foundation’s Model Signing project explicitly targets ML-DSA support; weight provenance is the supply-chain moat that prevents poisoned-weight ingestion. Tenant data passing through inference is HNDL-relevant when it includes regulated PII, because capturing TLS to the inference endpoint and decrypting later harvests every prompt and every retrieved chunk. Long-lived JWT and SAML assertions authenticating archived inference traces are HNDL targets, which is why a zero-trust AI posture needs PQC on the assertions before 2030. The LLM gateway — where east-west traffic from agent loops to model providers concentrates — is where PQC instrumentation pays back fastest because it is the natural enforcement point for hybrid TLS toward provider endpoints. Confidential computing layers compose with PQC: a TEE that loads a poisoned weight runs a poisoned model very privately, so the model-weight signing pipeline being on ML-DSA is a precondition. The composition rule is: AI workloads inherit the agility plane, with explicit attention to model-weight signing pipelines and to the gateway’s outbound TLS posture, both of which carry quietly long-lived risk that classical signatures and key exchange can no longer cover.

Q: What is a sane auto-fallback failure threshold for the north-south rollout?

0.1 percent of post-quantum handshake attempts failing within a five-minute rolling window is the production-tested threshold that Cloudflare and Google’s public deployments converged on. Below that, the failure rate is indistinguishable from baseline TLS noise (transient network blips, client misconfiguration, expected middlebox edge cases). Above it, the failure pattern is almost always systemic — a specific corporate firewall version, an ISP middlebox, a cloud-provider load-balancer that fails closed on ClientHello fragmentation — and rolling back to classical-only protects the user experience while the engineering team triages the cause. The fallback flag is per-region and per-listener so a single misbehaving deployment does not pull the rollout back across the entire fleet. The auto-fallback is wired to telemetry, not to a manual button, because the failure mode appears within minutes of a misbehaving middlebox seeing the new handshake; a human-in-the-loop response time of an hour is too slow to protect availability. Once the auto-fallback fires the team investigates, identifies the upstream issue, files a vendor or ISP ticket, and either hand-rolls back forward when the issue is fixed or carves out a per-network exception. The same threshold and shape works for ML-DSA verifier rollouts on signed artefacts, with the metric reframed as verifier acceptance rate.

Q: How long should the dual-signing transitional period be for code and model signatures?

18 to 30 months is the realistic range, gated on telemetry not on calendar. The signer-side change is fast — a configuration flip in Sigstore, Notation, or the Linux Foundation Model Signing toolchain — and most teams can ship dual-signing within a quarter. The longer pole is the verifier fleet: every operating-system package manager that verifies signatures, every container runtime, every device that runs OTA verification, every CI gate that checks artefact policy, every regulator-facing notary chain. Until the verifier-side telemetry shows that more than 99.5 percent of verification attempts succeed against the ML-DSA signature alone, the classical signature must remain on the artefact. Instrument the verifier population by emitting a metric per verification (which signature was actually checked, which one would have been checked if the other were absent) and roll the metric up across the fleet. Drop the classical signature only when the metric is green for an extended steady-state window (a quarter is reasonable) and when no remaining verifier population is structurally unable to upgrade (legacy hardware that will not get firmware updates in the migration window). Skipping the verifier-side telemetry is the anti-pattern: teams that drop classical signatures based on the signer-side rollout date discover broken verifiers in the field weeks later, by which time the regression is cohort-wide.

Q: What is the actual cost impact in dollars and milliseconds for a typical estate?

Performance: hybrid X25519MLKEM768 adds well under one millisecond to handshake CPU time on commodity x86 versus X25519 alone, and roughly 1 to 1.5 KB to the ClientHello. On a typical web request handshake budget of 50 to 100 ms end-to-end, this is invisible. ML-KEM-1024 for KMS key wrap adds a few milliseconds per wrap, which is irrelevant for at-rest data but matters for ultra-high-throughput key-derivation pipelines (multi-million-ops-per-second crypto services need to architect around it). Signature size: ML-DSA-65 signatures are 3293 bytes versus 64 bytes for Ed25519; in a software-update manifest signing 1000 artefacts the size growth from 64 KB to 3.3 MB is real and is the reason Merkle aggregation patterns matter. Engineering cost: the inventory service plus policy plane plus enforcement wiring plus telemetry layer is six to twelve engineering months for a mid-size estate. The hybrid TLS rollout itself is a configuration change at every TLS-terminating component, deployable in weeks once the agility plane is live. Hardware cost: PQ-capable secure elements (NXP, ST, Infineon, recent Apple Secure Enclave) are at price parity with predecessors; the cost is the device-fleet refresh cycle, which is normally on a 3-to-7-year cadence and aligns naturally with the 2030 NSA mandate. The expensive part of the migration is starting late: a 2028 start with a 2030 mandate is a frantic crunch; a 2026 start with the same mandate is steady-state delivery.