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

The least useful post-quantum TLS conversation is the one where everyone argues about when a quantum computer will break RSA.

It is fun in the way all prediction fights are fun. Someone has a chart. Someone has a more skeptical chart. Someone says "harvest now, decrypt later" with the face of a person who has said it in eight meetings this quarter.

Fine.

But for engineering teams, that is not the interesting problem anymore.

The interesting problem is much more boring and much more dangerous:

Do we know which of our clients, SDKs, proxies, service meshes, CDNs, KMS integrations, payment providers, middleboxes, observability tools, and certificate workflows will tolerate the post-quantum TLS migration when the defaults start moving under us?

That is the work.

Not because quantum doom arrives tomorrow morning with a calendar invite. Because the platform surface is already changing. AWS has ML-KEM hybrid post-quantum TLS support in KMS, ACM, and Secrets Manager. Cloudflare documents post-quantum key agreement between its edge and origins. Microsoft has ML-KEM and ML-DSA in its crypto platform surface, hybrid TLS in SymCrypt-OpenSSL, and Windows TLS support on the roadmap. The IETF TLS work for ML-KEM in TLS 1.3 is active enough that this is not "future crypto" in the abstract anymore.

This is becoming normal migration work.

And normal migration work is where production breaks.

the narrow change is not that mystical

Let us remove the drama for a second.

TLS today usually relies on classical public-key cryptography during the handshake. The client and server agree on keys using mechanisms like elliptic curve Diffie-Hellman. Quantum computers, if they become strong enough, are a problem for those public-key assumptions.

Post-quantum TLS changes the key agreement side of the handshake so that the connection can resist that future attack class. In practice, the migration path most platforms are using first is hybrid key exchange: keep a classical algorithm like X25519 and combine it with a post-quantum algorithm like ML-KEM.

The hybrid part matters. It means we are not throwing away the classical mechanism overnight. We are adding a post-quantum component while preserving the current security properties if one side of the hybrid story turns out to be weaker than expected.

That sounds tidy. It is not free.

The handshake gets bigger. More bytes move at connection startup. ClientHello messages may split across packets. Some intermediaries and old TLS stacks will behave badly, because protocol ossification is basically the internet's hobby. Some connections will negotiate the new group. Some will fall back. Some will fail in places nobody had on the architecture diagram because the diagram stopped at "load balancer."

AWS measured this as a manageable performance cost for its KMS benchmark, especially when TLS connection reuse is enabled. That is good news. It is also not a permission slip to skip testing. Benchmarks from a cloud provider are not a substitute for your own connection patterns, your own proxies, your own mobile clients, and your own suspicious enterprise network path that somehow still matters because the CFO uses it.

The other important distinction: key exchange is not certificates.

ML-KEM helps with key agreement. Post-quantum signatures are the separate authentication problem. Your certificate chain, client certificates, mTLS setup, code signing, internal CAs, HSMs, and certificate rotation workflows do not become quantum-safe just because one TLS connection negotiated a hybrid key share.

This is exactly where I expect teams to get sloppy.

"We turned on PQC" will be used to describe three different things:

• hybrid key agreement on inbound browser traffic
• hybrid key agreement on service-to-service traffic
• post-quantum authentication through certificates or signatures

Those are not the same migration. If a dashboard flattens them into one green check mark, be suspicious.

the cloud default will arrive before the spreadsheet is perfect

The reason to start now is not panic.

The reason to start now is that cloud defaults have a habit of becoming production defaults while the backlog still says "investigate."

AWS is already explicit that customers need to update TLS clients and SDKs to offer ML-KEM when connecting to AWS service HTTPS endpoints. For services like KMS and Secrets Manager, that is not an academic endpoint. That is the path your applications use to decrypt secrets, fetch configuration, generate data keys, and bootstrap sensitive workloads.

Cloudflare is also a good preview of the operational shape. It supports X25519MLKEM768 in the edge-to-origin path and documents the fact that adding ML-KEM can split the ClientHello across two packets. That tiny sentence is a whole migration hiding in plain sight.

Can your origin handle it?

Can the load balancer in front of the origin handle it?

Can the WAF handle it?

Can the appliance nobody wants to own handle it?

Can the old Java service using a pinned runtime handle it?

Can the fintech partner endpoint handle it?

This is why I do not like framing post-quantum TLS as a security team project. Security should absolutely drive the risk framing and target state. But the actual migration is platform plumbing: TLS libraries, SDK versions, runtime images, ingress controllers, sidecars, managed load balancers, trust stores, certificate issuance, client retry behavior, dashboards, and rollback switches.

That is platform work.

If only the cryptography people own it, the migration will produce beautiful documents and then die at the first strange proxy.

inventory beats speeches

The first useful deliverable is not a quantum readiness strategy deck.

It is an inventory.

Start with outbound clients. Which services initiate TLS connections, and with which runtime stacks?

• Java with JDK TLS
• Java with AWS CRT
• Node.js with OpenSSL through the runtime
• Go with the standard library
• Rust with rustls or native-tls
• Python with OpenSSL through the system or a bundled package
• mobile clients pinned to OS behavior
• vendor SDKs with their own HTTP clients
• sidecars doing outbound TLS on behalf of the service

Then map the destinations.

• AWS KMS, ACM, Secrets Manager, STS, S3, and other cloud APIs
• payment processors
• card networks and banking partners
• identity providers
• observability vendors
• webhook targets
• internal APIs behind meshes or gateways
• customer-controlled endpoints

This is the part where fintech teams should pay attention. Payment and banking integrations are often full of TLS constraints that nobody wants to touch unless a certificate is expiring. Some partners still have very specific TLS requirements. Some mutual TLS setups are held together by a certificate runbook last edited by a person who left three reorganizations ago. Some "temporary" proxies became permanent infrastructure by surviving long enough.

Post-quantum TLS will find those places.

Better you find them first.

test the path, not the box

A common mistake in migrations like this is testing one component and declaring the path safe.

"The service supports TLS 1.3."

Good. Does the whole path support the actual handshake you intend to use?

"The origin supports X25519MLKEM768."

Good. Does Cloudflare negotiate it to the origin through your current configuration?

"The SDK has a flag."

Good. Is that the HTTP client your production service actually uses, or did the dependency injection layer quietly choose a different one?

"The certificate library supports ML-DSA."

Good. Does your certificate authority, renewal pipeline, HSM, deployment process, mTLS verifier, and rollback plan support it too?

You need end-to-end tests that look like production paths:

• browser to CDN to origin
• Cloudflare edge to origin
• service to AWS KMS
• service to Secrets Manager
• service to payment provider
• service through mesh sidecar to internal API
• mobile app to API gateway
• batch job through corporate egress proxy

The word "through" is doing a lot of work there.

TLS migrations do not only fail at endpoints. They fail at the thing between endpoints that was not supposed to care.

observability needs to know what negotiated

"Turn it on" is not a strategy.

It is barely even an action unless you can prove what happened after you turned it on.

For post-quantum TLS, the minimum useful telemetry is:

• negotiated TLS version
• negotiated key exchange group
• handshake failure rate
• HelloRetryRequest rate
• fallback rate to classical key exchange
• TLS handshake latency
• connection reuse behavior
• ClientHello size distribution where you can measure it
• errors by client runtime, SDK version, region, and egress path
• certificate chain and signature algorithm where authentication is in scope

You probably will not get all of that on day one. Fine. Start with what your proxies, load balancers, service mesh, CDN, and client libraries can expose.

But if the only signal is "the service still seems up," you are flying blind.

The scary failure mode is not always total outage. The scarier one is false confidence. A team believes it is running post-quantum key agreement because the setting is enabled somewhere, but most traffic is falling back silently. Or one region negotiates the new group and another does not. Or browser traffic looks modern while service-to-service traffic is still entirely classical. Or the shiny edge path is upgraded, but the origin authentication path is still old RSA all the way down.

Security migrations love partial success because partial success produces screenshots.

Production needs evidence.

certificates are their own migration

Cloudflare's origin documentation is useful because it refuses to hide the awkward part: post-quantum signatures are a separate track.

It talks about ML-DSA for origin-facing authentication features, not just ML-KEM key agreement. It also calls out downgrade behavior: presenting a post-quantum certificate is not enough if the verifier still accepts classical certificates in the same trust path.

That should make every platform team slightly uncomfortable, in a healthy way.

Certificate workflows are usually older than people admit. They cross team boundaries. They include public CAs, private CAs, mTLS, device certificates, HSMs, Kubernetes secrets, ingress annotations, Terraform modules, emergency renewal docs, and maybe a spreadsheet called certs-final-v3.xlsx if your organization has a sense of humor by accident.

Do not bundle all of that into "enable PQ TLS."

Plan it separately:

• key exchange migration first where the platform supports it
• certificate and signature inventory in parallel
• mTLS verification rules reviewed explicitly
• private CA capability checked
• HSM and KMS support checked
• renewal and rollback rehearsed
• certificate pinning found and removed or updated
• partner requirements documented

Especially certificate pinning. If there is an old mobile app, embedded client, or partner integration pinning assumptions about certificates or algorithms, you want to discover it before a security migration turns into a customer-support incident.

the banking/government lag is a warning

The June 2026 measurement paper on post-quantum readiness is useful because it shows the internet doing what the internet does: migrating unevenly.

Across 32,011 domains, the authors 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. They also found no hybrid post-quantum certificate adoption in their observed set.

That is exactly the pattern I would expect.

Key exchange can move first because browsers, CDNs, cloud providers, and TLS libraries can push a lot of that surface forward. Certificates are slower because trust infrastructure is messy, regulated, audited, pinned, vendor-dependent, and painfully operational.

For fintech teams, this matters for two reasons.

First, you will be pulled forward by cloud providers and browsers.

Second, you will be held back by partners, legacy clients, compliance constraints, and external integrations.

The migration plan has to handle both directions at the same time. You need to be modern enough to negotiate the new defaults where available, and conservative enough to avoid breaking business-critical paths that are not ready yet.

That is not a crypto debate.

That is compatibility engineering.

rollback is part of the design

Post-quantum TLS rollout should look like every other serious platform rollout.

Small scope first. Known clients first. Clear metrics. Rollback switch. No hero deploys.

For outbound clients, that may mean enabling hybrid TLS only for one service calling KMS in one environment, then expanding by service class. For edge-to-origin, it may mean testing selected origins before relying on zone-wide behavior. For service mesh, it may mean proving behavior in a canary namespace with the same ingress, egress, and observability path as production.

The rollback question should be boring:

• How do we disable hybrid key agreement for this client?
• How do we force classical fallback if a partner path breaks?
• How do we know fallback happened?
• Who is allowed to change the setting?
• What metric tells us the rollback worked?
• What customer-facing behavior would trigger rollback?

If nobody can answer those, the rollout is not ready.

And yes, this can feel absurd. We are talking about preparing rollback behavior for a future-facing cryptographic migration that most users will never notice.

That is platform engineering. Most of the work is making sure users never notice.

what i would do now

If I owned a platform today, I would not start with a grand "quantum-safe transformation program."

I would start with a small, practical checklist.

1. Build the TLS client inventory. List services, runtimes, TLS libraries, SDK versions, sidecars, mobile clients, and outbound destinations. Do not forget CI jobs and batch workloads.

2. Identify cloud service paths. Pay special attention to KMS, Secrets Manager, ACM, identity, storage, and payment-adjacent services. Security-critical endpoints will move early.

3. Test hybrid key exchange in non-production. Use real client libraries, real proxies, and realistic connection reuse. Measure handshake latency and failure rates.

4. Add negotiation telemetry. At minimum, learn which TLS version and key exchange group were negotiated where your stack exposes it. Without this, every claim is vibes.

5. Exercise middleboxes. CDNs, WAFs, API gateways, service meshes, load balancers, corporate proxies, and partner gateways are where boring TLS changes become incidents.

6. Separate certificate planning. ML-KEM key agreement and ML-DSA signatures are different migration tracks. Treat private CA, mTLS, HSM, certificate pinning, and renewal flows as their own workstream.

7. Write rollback instructions before rollout. A crypto migration without rollback is just a production experiment with a better acronym.

8. Keep security and platform in the same room. Security owns the risk. Platform owns much of the machinery. Product teams own the traffic and partner dependencies. Splitting those too cleanly is how migrations become archaeology.

None of this requires panic.

It requires inventory, evidence, and boring discipline.

the punchline

Post-quantum TLS is not waiting for your organization to finish debating quantum timelines.

It is arriving through provider defaults, SDK options, CDN behavior, operating system support, TLS library releases, and partner requirements. Some of it will be opt-in. Some of it will become preferred behavior. Some of it will show up as a minor-looking changelog entry that quietly changes what production negotiates on a Tuesday.

The teams that handle it well will not be the ones with the most dramatic quantum slide deck.

They will be the ones that can answer simple questions:

What do our clients support?

What did this connection negotiate?

Where did it fall back?

Which path broke?

Can we roll it back?

That is the migration.

Not hype. Not prophecy. Not a religious war about timelines.

Just another piece of platform work that becomes much easier if you start before the default changes.

references

• AWS Security Blog: ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager
• AWS KMS Developer Guide: Using hybrid post-quantum TLS with AWS KMS
• Cloudflare SSL/TLS docs: Post-quantum cryptography
• Cloudflare SSL/TLS 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: Measurement Study of Post-Quantum Readiness of Internet: 2026

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