Why every TLS termination is a separate migration boundaryA cloud application rarely has one TLS connection. A single API request can be decrypted and re-encrypted at a CDN, a web application firewall, an API gateway, a load balancer, a service-mesh proxy, an application runtime, and a managed cloud endpoint. Each termination negotiates a fresh session. Upgrading only the public edge can leave every downstream hop protected by classical key exchange.That architectural fact changes how teams should approach post-quantum TLS. The right unit of migration is not the hostname, service, cluster, or application. It is the directional TLS link between two adjacent termination points, complete with an owner, a policy, a negotiated group, and runtime evidence.The Unit of Migration Is the TLS LinkTreat the request path as a graph. The nodes are clients, gateways, proxies, workloads, and managed services. Every edge is an independently negotiated TLS connection. For each edge, record the source and destination, the team or provider that owns it, the data's confidentiality lifetime, the full-handshake rate, the selected key-establishment group, the authentication algorithm, the policy that produced the configuration, and the evidence that proves the result.This link-level model prevents an attractive but misleading label such as "PQC enabled." A client can advertise a hybrid group without the server selecting it. A gateway can negotiate hybrid on ingress and classical TLS to the backend. A service mesh can provide pervasive mTLS while its certificates still use classical signatures. Readiness must be measured from observed behavior, not configuration intent.Design rule: Count a link as post-quantum protected only when telemetry proves that it successfully negotiated an approved hybrid or post-quantum group.What X25519MLKEM768 Protects - and What It Does NotTLS 1.3 makes three largely independent cryptographic choices: a symmetric record cipher and hash, a key-establishment group, and an authentication mechanism. X25519MLKEM768 changes the second choice. It combines classical X25519 with NIST-standardized ML-KEM-768 and feeds both 32-byte shared secrets into the TLS 1.3 key schedule.The hybrid construction is designed so the session secret remains protected if either component remains secure, subject to the combiner and transcript assumptions. That is useful against a harvest-now, decrypt-later adversary recording traffic today. It does not make an RSA- or ECDSA-signed certificate quantum resistant, and it does not change AES-GCM record protection.TLS PROPERTYWHAT HYBRID PROVIDESWHAT STILL REMAINSRecorded-traffic confidentialityA combined X25519 and ML-KEM session secretEvery link carrying the data must negotiate hybridServer authenticationNormal TLS transcript authenticationClassical RSA or ECDSA remains quantum vulnerableClient authentication in mTLSConventional certificate-based mTLSClient certificate and trust chain need a separate signature migrationBulk encryptionUnchanged TLS 1.3 record protectionKey establishment changes; AES-GCM does notFallbackClassical peers may still connect when policy allowsFallback must be visible, bounded, and eventually retiredResumptionA PSK can inherit security from the original sessionPSK-only resumption has no fresh key exchangeUse honest labels: Publish post-quantum key-establishment coverage and post-quantum authentication coverage as separate fields. A hybrid key exchange is not complete post-quantum TLS.The Benchmark: Modest Compute, Much Larger First FlightsThe research used OpenSSL 3.6.3 and paired in-memory BIOs to isolate protocol encoding, allocation, signature work, and key-establishment CPU from network latency. Across 120,000 successful full TLS 1.3 handshakes on an Apple M3 Pro, the only intended variable was X25519 versus X25519MLKEM768. Session tickets and caches were disabled, and each configuration used the same ECDSA P-256 certificate and TLS_AES_128_GCM_SHA256.SINGLE-WORKER MEASUREX25519X25519MLKEM768CHANGETLS-record bytes1,1723,438+2,266 (+193.3%)Process CPU per handshake332.5 us416.8 us+84.3 us (+25.3%)Throughput2,977 hs/s2,389 hs/s-19.7%Median elapsed time320.3 us405.0 us+84.7 usThe raw hybrid key shares add 2,272 bytes: a 1,184-byte ML-KEM encapsulation key in the ClientHello and a 1,088-byte ML-KEM ciphertext in the ServerHello. In the measured handshake, surrounding encoding reduced the observed TLS-record delta slightly to 2,266 bytes. The important deployment effect is that a previously small ClientHello can cross packet boundaries and expose brittle middleboxes, parsers, or firewalls before cryptographic CPU becomes the bottleneck.Connection Reuse Determines the Real CostThe isolated benchmark is intentionally a worst case for connection churn: every request creates a fresh connection. In real cloud systems, HTTP/2, long-lived gRPC streams, SDK connection pools, and keep-alive amortize the handshake across many application requests. Aggressive idle timeouts, autoscaling bursts, DNS churn, unbalanced pools, serverless cold starts, and per-request clients can erase that advantage.REQUESTS PER CONNECTIONFULL HANDSHAKES/S AT 50,000 REQUESTS/SESTIMATED EXTRA CPUESTIMATED EXTRA BANDWIDTH150,0004.214 cores906.4 Mb/s105,0000.421 core90.6 Mb/s1005000.042 core9.1 Mb/s1,000500.004 core0.9 Mb/sOperational implication: Measure requests per connection by source-destination pair. Capacity tests should include cold starts, failover, and connection-pool disruption, not only steady-state request traffic.Cloud Controls Are Directional, Versioned, and ExplicitThe implementation landscape is uneven. A product may support the hybrid group on one direction, behind one policy name, or only when linked with a recent cryptographic library. The control plane therefore needs a capability registry that records provider, product version, binary build, direction, supported group names, policy provenance, and verification method.Managed gateways and edges• Amazon API Gateway documents enhanced security policies with PQ for incoming REST API connections, while its integration egress remains a separate TLS link. Treat ingress and backend connectivity as different inventory records.• Application Load Balancer policies can expose hybrid key exchange and log the selected group. Set the listener policy explicitly in infrastructure as code because console and automation defaults can differ.• Cloudflare can extend hybrid key establishment from its edge to the origin, but the origin connection remains a distinct boundary that must be tested and observed.Service meshesEnvoy and Istio provide central levers for internal mTLS, but a recent proxy image alone is not evidence that ordinary mesh traffic negotiated X25519MLKEM768. Default curve lists, BoringSSL builds, FIPS profiles, and rolling-upgrade revisions can differ. Canary a prefer policy by namespace or proxy revision, inspect configuration dumps, and probe both inbound and outbound paths.meshConfig: meshMTLS: minProtocolVersion: TLSV1_3 ecdhCurves: - X25519MLKEM768 - X25519Application and egress TLSDatabase drivers, message brokers, SDKs, and application-managed HTTPS clients may bypass the mesh or establish TLS after a CONNECT tunnel. Their linked runtime matters. OpenSSL 3.5 and later support ML-KEM and hybrid groups, while NGINX passes group configuration to its linked OpenSSL library. Pin patched versions, record the provider build, and observe selected-group distributions after upgrades.Infrastructure rule: Every managed listener and every application-controlled TLS client must receive an explicit, versioned policy. An omitted default should fail review.Roll Out Hybrid TLS as an Observable State MachineA Boolean flag such as pqc_enabled hides peer compatibility, mixed proxy versions, middlebox failures, classical fallback, and policy drift. Use explicit states whose transitions depend on evidence and whose rollback changes policy rather than rebuilding software.Observe. Upgrade clients, proxies, and libraries so they can advertise the hybrid group without requiring it. Inventory directional links and record offered groups, selected group, TLS version, resumption state, certificate signature algorithm, failure stage, build, and policy ID.Prefer. Put X25519MLKEM768 first while retaining time-bounded X25519 fallback. Roll out by listener, namespace, mesh revision, client cohort, or traffic percentage. Compare the canary with a matched classical baseline.Require. Move only capability-complete scopes to hybrid-only. Internal mTLS segments and controlled partner endpoints are usually better candidates than broad public APIs with unknown older clients.Retire. Remove classical groups from required scopes, deny legacy policy creation, close exceptions, and verify that health checks, direct pod paths, backup regions, and administrative endpoints do not bypass the policy.Promote on Evidence, Not ConfigurationThe minimum useful dashboard describes both the security result and the operational cost. Every measurement must be attributable to a directional link, proxy or library build, and policy digest so the team can separate peer incapability from middlebox failure, local misconfiguration, or capacity exhaustion.SIGNALREQUIRED DIMENSIONSEXAMPLE PROMOTION GATENegotiated groupSource class, destination, listener, build, policy ID>= 99.99% hybrid in a controlled scope; every remainder explainedHandshake outcomeError stage, alert, timeout, HRR, retransmit, path classNo statistically significant success regressionResource costFull/resumed, CPU, queue time, p50/p95/p99, saturationp95 within budget and at least 30% CPU headroomConnection reuseRequests/connection, connection age, idle-close reasonReuse ratio meets a workload-specific targetAuthentication stateServer/client certificate algorithm, chain, issuerAuthentication coverage reported separatelyConfiguration provenanceCanonical policy, provider translation, digest, deploy ID100% of observed links map to an approved digestException stateOwner, reason, risk weight, expiry, compensating controlNo expired exception; weighted coverage increases each releaseChoose the First Rollout by Risk, Not ConvenienceThree rollout patterns are useful, and most programs will combine them. Order the work by confidentiality lifetime and capture feasibility so that long-lived, internet-facing health data, credentials, source code, and secrets outrank low-risk endpoints that are merely easy to upgrade.• Edge-first reaches the most capturable public segment quickly and produces compatibility data, but downstream re-encryption can remain classical.• Mesh-first can move a large controlled workload population through one proxy fleet and provide consistent telemetry, but proxy revisions can diverge and workload certificates may still use classical signatures.• SDK-first protects direct calls to capable cloud services, including selected secrets and key-management paths, but support varies by language runtime and connection pooling can hide whether fresh negotiations occur.Preproduction Checklist• Every in-scope TLS link has a source, destination, owner, provider, current group, certificate algorithm, and replacement path.• Active probes and runtime telemetry confirm the selected group; capability is not inferred from a library version or policy name.• Hybrid key establishment and post-quantum authentication are reported separately.• ClientHello fragmentation, HelloRetryRequest behavior, retransmits, and representative middlebox paths have been tested.• Handshake success, fallback, p95/p99 latency, full-handshake rate, connection reuse, and CPU headroom gates are defined before rollout.• Rollback restores the previous approved policy state and has been exercised in the same environment.• Every classical fallback or provider exception has an owner, reason, blast radius, compensating control, and expiration date.• Infrastructure as code sets an explicit TLS policy and blocks omitted or legacy defaults.• The full trust path - leaf, intermediate, root, and distributed trust bundle - has been validated independently of the key-establishment rollout.ConclusionPost-quantum TLS for cloud APIs is deployable, but it is not an application checkbox. X25519MLKEM768 adds modest compute on modern hardware and a much larger first flight. Connection pooling can reduce the per-request cost by orders of magnitude, while churn, autoscaling, and regional failover can expose it again.The decisive engineering problem is TLS termination. A credible migration inventories every directional link, separates key establishment from authentication, prefers hybrid with observable fallback, tests packet-size and middlebox behavior, enforces explicit policy, and advances only when SLO and rollback gates pass. That operating model turns post-quantum TLS from a library experiment into a measurable cloud security control.Practical milestone: The first definition of readiness is not that every workload is hybrid-only. It is that every important TLS link is visible, owned, risk-ranked, measurable, and reachable through a controlled migration path.Research Basis and Further ReadingNIST FIPS 203: Module-Lattice-Based Key-Encapsulation Mechanism StandardNIST SP 800-227: Recommendations for Key-Encapsulation MechanismsIETF draft: Post-quantum hybrid ECDHE-MLKEM Key Agreement for TLS 1.3OpenSSL 3.6 supported-group configurationAWS post-quantum confidentiality readinessCloudflare: Post-quantum between Cloudflare and origin servers