Paulo Victor Leite Lima Gomes

Posted on Sep 13

Post-Quantum TLS Is a Platform Migration, Not a Crypto Project

#ai #softwareengineering #opinion #devops

The least useful question in post-quantum cryptography is "when will quantum computers break RSA?"

It sounds important. It starts arguments. It lets everyone pick a year that matches their appetite for panic.

It is also the wrong question for most engineering teams.

The useful question is much more boring: when a cloud provider, CDN, browser, operating system, SDK, or TLS library changes the default, do we know which of our systems will negotiate the new thing, which will fall back, and which will quietly fail?

That is the shape of post-quantum TLS in 2026. Not a dramatic cryptography project. A platform migration.

And platform migrations are won or lost on inventory, compatibility testing, telemetry, rollback, and ownership. Not on whether the team can explain lattice cryptography in a slide deck.

the narrow change first

It helps to separate the parts, because the marketing tends to mash everything together.

The thing moving into production now is mostly hybrid TLS key agreement. In plain English: during a TLS 1.3 handshake, the client and server can combine a classical key exchange such as X25519 with a post-quantum mechanism such as ML-KEM. The common deployed shape is X25519MLKEM768.

Hybrid matters because it avoids a weird all-or-nothing bet. If the classical part survives, good. If the post-quantum part survives, also good. You get a migration path without pretending that every dependency on the internet upgraded at the same time.

That is different from post-quantum authentication.

Authentication means certificates, signatures, trust chains, certificate authorities, HSMs, code signing, device roots, and procurement meetings that mysteriously multiply. ML-DSA certificates are a separate problem from ML-KEM key exchange. They will matter a lot, but they are not the same rollout.

This distinction is not pedantic. It is operationally useful.

Hybrid key exchange is a TLS compatibility and observability problem. Post-quantum signatures are a PKI migration. If those become one ticket, the ticket will become a swamp.

why this is not future crypto anymore

The reason to care now is not that anyone has a reliable countdown to "Q-day". The reason to care is that the platform surface is already changing.

AWS supports ML-KEM hybrid post-quantum TLS for AWS KMS, ACM, and Secrets Manager. Those are not random services; they are exactly the kind of security-critical dependencies that sit under production systems. AWS also says the older CRYSTALS-Kyber support on service endpoints will be removed in 2026 in favor of ML-KEM.

Cloudflare documents post-quantum key agreement for TLS 1.3 and has specific guidance for the Cloudflare-to-origin leg, including X25519MLKEM768 and ML-DSA origin authentication. That matters because a lot of teams mentally stop at "the CDN handles TLS" and forget that an uncached request still has more than one connection in its life.

Microsoft has shipped Windows platform support for ML-KEM hybrid TLS groups and post-quantum APIs, and is openly talking about accelerating critical product and service migration toward the end of the decade.

The IETF TLS work for ML-KEM in TLS 1.3 is active. Vendors are not waiting for every enterprise architecture committee to feel ready.

And measurement work from 2026 shows exactly the kind of uneven internet readiness we should expect: modern TLS 1.3 and QUIC adoption in some places, old TLS 1.2 in others, partial support for hybrid key exchange, and almost no post-quantum certificate adoption. Banking and government show up in the uncomfortable part of that picture, which should surprise nobody who has ever integrated with a legacy partner API.

So no, the question is not whether your team should become a cryptography research group.

The question is whether your production traffic is about to inherit new TLS behavior from somebody else's roadmap.

the migration surface is bigger than the endpoint

Ask a team which of their services make outbound TLS connections and the answer is usually a memory exercise.

That is not an inventory. That is folklore with YAML nearby.

The real list includes:

JVM services with their own trust stores and TLS providers
Go and Rust binaries with statically linked crypto
Node services tied to a base image's OpenSSL
Python clients behind old requests versions
database drivers and message brokers
service mesh sidecars
forward proxies and egress gateways
load balancers and CDN origin paths
vendor SDKs for payments, identity, fraud, messaging, and analytics
webhook delivery and callback endpoints
old jobs on old VMs that nobody wanted to touch because they still work

Then add the network path.

A TLS handshake is not just "service A talks to service B". It moves through proxies, gateways, meshes, middleboxes, packet inspection, CDN edges, origin pools, partner infrastructure, and occasionally a very opinionated appliance purchased before half the current team joined.

Hybrid post-quantum handshakes are larger. AWS measured about 1600 additional bytes during the TLS handshake for hybrid ML-KEM, plus extra cryptographic compute. In ordinary connection-reuse scenarios that may be tiny. In systems that open short-lived connections, sit behind brittle middleboxes, or run at serious volume, "tiny" still deserves measurement.

This is exactly the kind of change that finds the thing nobody put in the architecture diagram.

fintech makes this less abstract

Fintech integrations are where this gets practical fast.

Payments, banking APIs, card processors, fraud vendors, KYC providers, open banking aggregators, ledger exports, settlement systems, and regulator-facing gateways tend to have three charming properties:

They are critical.
They are slow to change.
You do not control both ends.

That combination is where "the SDK upgraded and now TLS negotiates differently" stops being a nice security improvement and becomes a production risk.

The partner may support TLS 1.3, or it may not. A proxy in the path may tolerate a larger ClientHello, or it may not. The provider may prefer hybrid key exchange, or it may fall back. Their status page may say "operational" because from their side it is.

If you cannot prove what negotiated, you do not know what happened.

And if you cannot force or disable the new behavior per path during an incident, rollback becomes a Slack debate instead of an operational control.

what to measure before changing anything

The lazy strategy is "turn it on and see if anything breaks."

Sometimes that is fine. For post-quantum TLS, it is not enough, because the failure mode is not only "broken". It is also "fell back", "got slower", "retried", "worked from one runtime but not another", and "failed only through the partner path nobody load-tested".

The useful signals are boring:

Negotiated key exchange group. Record the actual group negotiated per important path. Not the library version. Not the intended configuration. The result.
TLS version and fallback behavior. Know when a client used TLS 1.3, when it fell back, and which peer caused the fallback.
Handshake size and latency. Watch the startup cost separately from request latency. Connection reuse can hide a lot until it disappears.
Handshake error rates. Timeouts, retries, EOFs, and connection resets can be TLS migration symptoms before they become obvious incidents.
Runtime and library distribution. Track which services use which TLS stacks. Language, container base image, OS, OpenSSL or BoringSSL version, Java provider, mesh sidecar version. This is your blast-radius map.
Critical partner paths. Payments and banking integrations deserve their own dashboard slice, because their change windows and escalation paths are different.
Certificate and signature readiness. Track it separately from key exchange. The certificate migration will move slower and break in different ways.

The first deliverable of a post-quantum TLS program should probably be telemetry, not a migration flag.

That is less exciting than announcing "we enabled PQC". It is also how you avoid lying to yourself.

"enabled" is not the same as "understood"

This is the part where platform teams should be skeptical.

Cloud and CDN defaults are good. I like boring secure defaults. Most teams are safer because providers keep moving the baseline forward.

But "the provider enabled it" is not a complete strategy.

It does not tell you whether your old Java service offered ML-KEM. It does not tell you whether the payment provider fell back. It does not tell you whether a middlebox dropped the first ClientHello. It does not tell you whether one region behaves differently because the AMI is older. It does not tell you whether your canary covered the one path that matters.

We have seen this movie with certificate expiry, cipher deprecations, TLS minimum version changes, DNS behavior, CA bundle updates, and Kubernetes trust rotation. The technical change can be small and still have a large operational surface.

Post-quantum TLS is the same category of work.

The teams that handle it well will not be the ones with the loudest quantum roadmap. They will be the ones that can answer, calmly:

Which clients offered a hybrid group?
Which peers accepted it?
Which paths fell back?
Which failures increased?
Which workloads are sensitive to handshake cost?
Which partner integrations are pinned to older TLS behavior?
How do we roll back one path without rolling back the whole platform?

That is not a crypto strategy. That is production engineering.

a practical checklist

If I were starting this inside a platform team, I would not begin with a company-wide "quantum readiness initiative". I would start smaller and make it real.

Create an outbound TLS inventory. List services, jobs, scripts, and vendor SDKs by owner. Include runtime, OS, container base image, TLS library, and dependency path.
Mark critical paths. Payments, banking, identity, secrets, KMS, certificate issuance, customer callbacks, and regulator-facing integrations get priority.
Map the network path. Record CDN, proxy, gateway, service mesh, NAT, partner appliance, and origin hops. Compatibility problems often live between endpoints.
Capture negotiated groups before rollout. Add logs, traces, sidecar metrics, or synthetic probes that can show the actual TLS group and version.
Test hybrid key exchange in one boring place first. Pick a path with an owner, traffic, rollback, and low drama. Learn there.
Load-test short-lived connections. If connection reuse is weak or intentionally disabled, measure the handshake cost under realistic traffic.
Ask partners for explicit TLS/PQC posture. Do not accept "we support modern TLS" as an answer for critical integrations. Ask about TLS 1.3, supported groups, fallback, certificate plans, and test endpoints.
Keep signatures separate. Track ML-DSA, certificate authority support, code signing, and HSM work as a separate PKI program.
Rehearse rollback. Know how to disable or deprioritize hybrid key exchange per client, runtime, path, or proxy layer.
Make ownership boring. Security can set the risk frame, but platform and service owners need to own the actual migration surface.

None of that requires panic. It does require admitting that "crypto agility" is not a slogan. It is whether you can change cryptographic behavior without discovering your system through outages.

Post-quantum TLS is leaving the future bucket. It is becoming another platform default that changes under production.

The teams that treat it as ordinary migration work will be fine.

The teams that treat it as a far-away cryptography debate will eventually have a very modern incident caused by a very boring missing inventory.

sources

To test my projects, I use Railway. If you want $20 USD to get started, use this link.

DEV Community