post-quantum TLS is a platform migration, not a crypto project

Every post-quantum TLS discussion eventually turns into a fight about dates.

When will a cryptographically relevant quantum computer show up? Is it 2030, is it 2040, is it never, is "harvest now, decrypt later" actually a thing for my threat model? Someone brings up Shor's algorithm, someone else brings up the storage cost of keeping ciphertext for a decade, and forty minutes later the meeting ends without anyone writing a single line of configuration.

I have started to find that debate genuinely uninteresting.

Not because the risk is fake. Because it is not the problem that engineering teams actually have to solve this quarter.

The problem teams have is this: post-quantum TLS is no longer a research topic that lives in a standards committee. It is arriving as ordinary platform surface area — cloud provider defaults, SDK flags, CDN behavior, operating system crypto libraries, and eventually the certificate workflows that hold your mTLS paths together. And the surface is arriving before most teams have an inventory of the things it will touch.

That is the migration. Not the calendar.

what is actually changing in the handshake

Strip the drama away and the change is narrower than it sounds.

TLS today authenticates and agrees on keys using classical public-key cryptography. Key agreement usually comes from something like elliptic curve Diffie-Hellman, and authentication comes from RSA or ECDSA signatures in the certificate chain. Quantum computers threaten the math underneath both of those assumptions, but for different reasons and on different timelines.

The first migration wave is about key agreement, and it is hybrid.

In practice that means a classical algorithm such as X25519 is combined with a post-quantum key encapsulation mechanism, ML-KEM (the standardized descendant of CRYSTALS-Kyber). Cloudflare's edge-to-origin documentation names the group as X25519MLKEM768. AWS, Microsoft, and the IETF work on ML-KEM for TLS 1.3 all point at the same shape.

Hybrid is the important word. We are not ripping out classical crypto overnight. We are adding a post-quantum component next to it, so a connection still holds up if either half turns out weaker than expected. That is a sensible engineering choice and it is also why the migration looks harmless in a design review.

It is not harmless in production.

The handshake gets bigger. A post-quantum key share adds hundreds of bytes to the ClientHello, which means the first flight can split across multiple TCP packets, which means every middlebox on the path gets an opportunity to do something creative. Some stacks will negotiate the new group. Some will fall back to classical. Some will just fail, in a place that never appeared on an architecture diagram because the diagram ended at "load balancer."

AWS published benchmark numbers suggesting the performance cost is manageable, especially with TLS connection reuse. Good. That is one provider's workload, not yours. Your connection patterns, retry behaviour, proxy chain, and mobile clients are the only benchmark that counts.

And keep one boundary sharp: key exchange is not authentication.

ML-KEM protects the key agreement. Post-quantum signatures — ML-DSA and friends — are a separate migration for certificates, client certificates, mTLS verification, code signing, internal CAs, and HSMs. Negotiating a hybrid key share does not make any of that quantum-safe. When a dashboard collapses both into one green check mark, someone is about to make a bad decision.

the defaults are already moving

The reason I would put this on a platform roadmap instead of a research backlog is that other people are already making the decision for you.

AWS supports ML-KEM hybrid post-quantum TLS for KMS, ACM, and Secrets Manager, and has been explicit that clients need to be updated to offer ML-KEM when talking to AWS service endpoints. It has also flagged that older CRYSTALS-Kyber support is going away across AWS service endpoints in 2026. Read that again slowly: one of the three services is the thing your workloads call to decrypt secrets and bootstrap. That is not a lab endpoint.

Cloudflare documents post-quantum key agreement between its edge and origins, and separately covers post-quantum authentication toward origins with ML-DSA, including the awkward detail that presenting a post-quantum certificate does not help if the verifier still happily accepts classical ones on the same trust path.

Microsoft is shipping ML-KEM hybrid TLS groups at the Windows platform level and talking about accelerating migration of critical products and services toward 2029. The IETF draft for ML-KEM key agreement in TLS 1.3 is alive and moving.

None of those are opt-in research previews you can safely ignore. They are the boring defaults forming underneath your services.

this is platform work wearing a security costume

The failure mode I expect is ownership, not technology.

Security teams will correctly frame the risk, publish a target state, and hand over a document. Then the actual work lands in TLS library versions, runtime base images, ingress controllers, sidecar proxies, managed load balancers, trust stores, SDK upgrades, retry logic, dashboards, and rollback switches — and none of that is crypto. It is platform plumbing.

So the first deliverable is not a quantum readiness strategy. It is an inventory.

Start with who initiates TLS and with what:

• Java services on the JDK TLS stack, and Java services on the AWS CRT HTTP client, which are not the same client
• Node.js borrowing OpenSSL through the runtime
• Go using the standard library
• Rust on rustls or native-tls
• Python sitting on a system OpenSSL or a bundled wheel
• mobile apps pinned to whatever the OS decides
• vendor SDKs that ship their own HTTP client and quietly ignore your config
• sidecars and service mesh data planes doing outbound TLS on behalf of a service
• CI jobs, batch workers, and that one CronJob everybody forgot

Then map the destinations. Cloud APIs like KMS, ACM, Secrets Manager, STS, and S3. Identity providers. Observability vendors. Webhook targets. Internal APIs behind gateways and meshes. And in a fintech context, payment processors, card networks, and banking partners, where TLS requirements are often contractual, occasionally bizarre, and held together by a runbook written by someone who left two reorganisations ago.

Those partner paths are where a crypto migration becomes a support incident.

test the path, not the box

The classic mistake here is proving one component and declaring the route safe.

"The service supports TLS 1.3." Great. Does the whole path support the handshake you intend to negotiate?

"The origin supports X25519MLKEM768." Great. Does your current Cloudflare configuration actually negotiate it to the origin, on the hostname that matters, with the same rules?

"The SDK has a flag." Great. Is that SDK the HTTP client your production service actually ends up using, or did a transitive dependency pick a different one?

"The library supports ML-DSA." Great. Does your private CA, renewal pipeline, HSM, mTLS verifier, deployment automation, and rollback plan agree?

What you want are tests that look like production paths, not component unit tests:

• browser to CDN to origin
• edge to origin with your real caching and WAF rules in front
• service to KMS and Secrets Manager in every environment, including the one that only exists for incident response
• service to payment or banking partner endpoints
• pod through mesh sidecar through egress gateway to an internal API
• mobile app through a corporate network to your API gateway

The word "through" is carrying all the weight in those bullets. TLS migrations rarely fail at the endpoints. They fail at the thing in between that was never supposed to care.

"turn it on" is not a strategy

Here is the skeptical part, and it is the part I would defend hardest.

Enabling post-quantum key agreement is not an action unless you can prove what happened afterwards. Otherwise you have changed a setting and acquired a feeling.

The minimum useful telemetry:

• negotiated TLS version
• negotiated key exchange group
• handshake failure rate, split by client runtime, SDK version, region, and egress path
• HelloRetryRequest rate, because that is where extra round trips and latency show up
• fallback rate to classical key exchange
• TLS handshake latency, and connection reuse behaviour
• ClientHello size distribution where your stack lets you see it
• certificate chain and signature algorithm wherever authentication is in scope

You will not get all of that on day one. Almost nobody can. But if your only signal is "the service still looks up," you are not testing a migration, you are guessing about one.

And the failure mode I fear most is not a loud outage. It is quiet partial success. The flag is on in one region and not another. Browser traffic negotiates hybrid, service-to-service stays fully classical. The edge path got upgraded while origin authentication stayed old all the way down. Everything reports healthy, and the only thing that actually changed is the confidence level in a slide.

Security migrations love partial success, because partial success produces screenshots. Production needs evidence.

certificates are a separate workstream

Certificates deserve their own plan, not a bullet inside "enable PQ TLS."

The June 2026 measurement work across 32,011 domains is a useful reality check here. It found real adoption of modern protocols and hybrid post-quantum key exchange, but also stubborn TLS 1.2 usage in critical sectors like banking and government, and no hybrid post-quantum certificate adoption in the observed set.

That is exactly the shape I would expect. Key exchange moves first, because browsers, CDNs, cloud providers, and TLS libraries can drag a lot of that surface forward at once. Certificate trust infrastructure moves slowly, because it is federated, regulated, audited, pinned in strange places, and painfully operational.

For fintech teams this cuts both ways. Cloud providers and browsers pull you forward. Partners, legacy clients, compliance constraints, and external integrations hold you back. A workable plan has to be modern enough to negotiate the new defaults and conservative enough not to break the business path that is not ready — and it has to know which path is which.

So keep it separate:

• key exchange first, where the platform supports it
• certificate and signature inventory in parallel
• mTLS verification rules reviewed explicitly, not assumed
• private CA capability, HSM support, and renewal automation checked
• certificate pinning found, and either removed or updated on purpose
• partner TLS requirements written down instead of remembered

Certificate pinning deserves a special mention. If an old mobile app, an embedded client, or a partner integration pins certificate or algorithm assumptions, you want to discover it before a routine security change becomes a customer-visible incident.

rollback, then rollout

Post-quantum TLS should roll out like anything else that touches connection establishment.

Small scope. Known clients. Clear metrics. A rollback switch. No hero deploys.

For outbound clients that might mean hybrid key agreement for one service talking to KMS in one environment, then expanding by service class. For edge-to-origin, it might mean specific origins before zone-wide behaviour. For a mesh, it might mean proving it in a canary namespace that shares the same ingress, egress, and observability path as production.

The rollback questions should be boring enough to answer in one sentence each:

• how do we disable hybrid key agreement for this client?
• how do we force classical fallback if a partner path breaks?
• how do we detect that fallback happened?
• who is allowed to change the setting at 2am?
• which metric tells us the rollback worked?
• what user-visible behaviour triggers the rollback?

If nobody can answer those, the rollout is not ready, no matter how good the readiness deck is.

the checklist I would actually run

If I owned a platform this quarter, I would not start a "quantum-safe transformation programme." I would start with eight boring things.

1. Build the TLS client inventory. Services, runtimes, TLS libraries, SDK versions, sidecars, mobile clients, CI jobs, batch workers. Write down the outbound destinations too.
2. Flag the security-critical paths. KMS, Secrets Manager, ACM, identity, and anything payment-adjacent will move early, whether or not you planned for it.
3. Test hybrid key exchange outside production. Real client libraries, real proxies, realistic connection reuse. Measure latency and failure rates, not just success.
4. Add negotiation telemetry. Negotiated version and group, fallback, HelloRetryRequest, handshake latency. Without this, every claim about readiness is vibes.
5. Attack the middleboxes. CDNs, WAFs, API gateways, meshes, load balancers, corporate proxies, partner gateways. That is where a boring TLS change becomes an incident.
6. Split certificates out. ML-KEM key agreement and ML-DSA signatures are different migrations. Treat CA, mTLS, HSM, pinning, and renewal as their own track.
7. Write rollback before rollout. A crypto migration without a rollback path is a production experiment with a better acronym.
8. Keep security and platform in the same room. Security owns the risk. Platform owns the machinery. Product teams own the partner dependencies. Splitting that too cleanly turns migration into archaeology.

None of this requires panic. It requires inventory, evidence, and the willingness to be boring about it.

the punchline

Post-quantum TLS is not waiting for your organisation to finish arguing about quantum timelines.

It is showing up in provider changelogs, SDK flags, CDN defaults, operating system crypto libraries, and partner questionnaires. Some of it will be opt-in. Some of it will become preferred behaviour. Some of it will arrive as one line in a release note that quietly changes what production negotiates on a Tuesday afternoon.

The teams that handle this well will not be the ones with the most dramatic quantum roadmap. They will be the ones who can answer simple questions:

What do our clients actually support?

What did this connection negotiate?

Where did it silently fall back?

Which path broke, and did the telemetry even notice?

Can we turn it off?

That is the migration. Not prophecy, not hype, not another argument about dates.

Just platform work that gets a lot easier if you start before the default changes under you.

references

• AWS Security Blog: ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager
• AWS KMS Developer Guide: Use hybrid post-quantum TLS with AWS KMS
• Cloudflare docs: Post-quantum cryptography
• Cloudflare docs: Post-quantum between Cloudflare and origin servers
• Microsoft Security Blog: New Windows features to secure today's data in a post-quantum world
• IETF Datatracker: ML-KEM Post-Quantum Key Agreement for TLS 1.3
• arXiv 2606.16473: measurement study of post-quantum readiness across 32,011 domains

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