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

The least useful question about post-quantum TLS is still the one people like asking first:

When will quantum computers break today's public-key cryptography?

I get why the question is attractive. It sounds strategic. It lets everyone argue about timelines, threat models, nation states, and whether the whole thing is hype. It also lets engineering teams postpone the boring work, because if the scary computer is far enough away, the migration can stay in the "future crypto" bucket.

That bucket is leaking.

Post-quantum TLS is already turning into ordinary platform migration work. Not because every company suddenly needs to panic about quantum attacks tomorrow morning, but because cloud providers, browsers, operating systems, CDNs, SDKs, cryptographic libraries, and compliance teams are starting to expose the surface area now.

AWS supports ML-KEM hybrid post-quantum TLS for KMS, ACM, and Secrets Manager. Cloudflare documents post-quantum key agreement between visitors, its edge, and origins. Microsoft has Windows platform support for ML-KEM hybrid TLS groups and post-quantum APIs. The IETF TLS work is active. The measurements say internet readiness is uneven, especially in sectors that should know better.

That is the migration signal.

The engineering problem is not "when does quantum break RSA?"

The engineering problem is "do we know which of our services, SDKs, middleboxes, payment integrations, certificate workflows, and observability paths will tolerate the TLS ecosystem changing underneath them?"

Most teams cannot answer that yet.

what is actually changing

The first wave is mostly about key exchange.

In normal TLS 1.3 today, clients and servers use classical elliptic-curve key agreement such as X25519 or P-256 to establish shared secrets for the connection. Post-quantum TLS introduces key establishment based on ML-KEM, the NIST-standardized key encapsulation mechanism that came out of the Kyber work.

The practical deployment pattern is usually hybrid key exchange. The client and server combine a classical algorithm with ML-KEM, so the connection is protected as long as at least one side of the hybrid construction remains sound. That is why you see names like X25519MLKEM768: familiar X25519 plus ML-KEM-768.

This sounds exotic until you translate it into production behavior:

• the TLS ClientHello can get larger
• the server response can get larger
• handshakes do a little more cryptographic work
• clients and servers need compatible TLS stacks
• middleboxes that make assumptions about handshake size or extensions can misbehave
• fallback behavior starts to matter a lot
• observability needs to show what actually negotiated

AWS's measurements are a useful sanity check here. In their KMS benchmark, enabling hybrid post-quantum TLS added roughly 1,600 bytes to the handshake and a small amount of compute. With TLS connection reuse enabled, the measured request-rate impact was almost invisible for that workload. Without connection reuse, the penalty was larger but still not dramatic.

That is good news, but it is not permission to stop thinking.

Your workload is not AWS's benchmark. Your network path may have old proxies. Your mobile clients may use older TLS libraries. Your service mesh may terminate and re-originate TLS. Your fintech partner may still be on TLS 1.2. Your payment gateway may have a device in the path that nobody has touched since a migration three org charts ago.

"The crypto is fast enough" and "our platform is ready" are different claims.

signatures are a separate migration

One trap in this conversation is mixing key exchange with signatures and certificates.

Hybrid ML-KEM in TLS is about establishing the connection secrets. It helps with the "harvest now, decrypt later" concern: an attacker records encrypted traffic today and hopes to decrypt it later with a quantum computer.

Post-quantum signatures are a different problem. Certificates, certificate chains, hardware security modules, code signing, device identity, private PKI, certificate transparency, ACME workflows, load balancers, origin authentication, and audit requirements all get involved.

Cloudflare's origin documentation is interesting because it points at both sides of the house: post-quantum key agreement to the origin, and ML-DSA for origin authentication in supported paths. That is exactly how this will land in real platforms. First the key exchange knob appears. Then certificate and signature paths start appearing. Then someone asks why the team treated it as one ticket.

Do not treat it as one ticket.

Key exchange, public TLS certificates, private service certificates, client certificates, KMS/HSM integrations, and code-signing chains should be planned separately. They share vocabulary, but they do not share the same blast radius, owner, tooling, or rollback story.

If security creates a single epic called "enable PQC", platform teams should split it before the work starts.

the cloud default problem

The reason this matters now is not that every team needs to flip every switch today.

The reason is that platform defaults have a way of becoming production defaults before anyone has finished the inventory.

AWS is a good example. It already supports ML-KEM hybrid TLS on security-critical services like KMS, ACM, and Secrets Manager, and it says older CRYSTALS-Kyber support will be removed across AWS service endpoints in 2026. AWS customers using older clients can fall back to classical key agreement when the old Kyber support disappears, but that sentence should make platform teams uncomfortable.

Fallback is not the same as readiness.

If your KMS client silently falls back to classical TLS and nobody records it, you did not migrate. You just failed quietly in the safest available direction. That may be the right runtime behavior, but it is a terrible migration signal.

The same pattern shows up with CDNs and origins. Cloudflare has supported post-quantum hybrid key agreement for visitor-to-edge TLS 1.3 for years, but edge-to-origin support depends on the origin stack, protocol, and configuration. An internet user may have a post-quantum-protected connection to the edge while your origin path remains classical. Or your browser path may be ready while a server-to-server client is not.

That split is normal. It is also easy to misunderstand.

Platforms need to know where TLS terminates, where it restarts, which negotiated group was actually used, and which policy decided the fallback. Without that, "we enabled PQC" is just a sentence in a slide deck.

inventory before ideology

The practical starting point is not a cryptography debate. It is inventory.

Start with outbound clients. Which services talk to AWS KMS, Secrets Manager, ACM, payment providers, identity providers, banks, partners, and internal APIs over TLS? Which SDK versions do they use? Which HTTP clients? Which TLS libraries? Which container base images? Which runtime versions?

This is where the real mess appears.

A Java service using the AWS SDK with a modern CRT client is a different migration target from an old JVM using a default TLS provider. A Rust service using rustls is different from a Go service pinned to an old toolchain. A mobile app with embedded networking code is different from a backend worker. A legacy appliance behind a private link is different from a Lambda function. A payment integration with strict certification is different from a disposable internal dashboard.

Then map the termination points:

• public edge
• CDN
• WAF
• load balancer
• API gateway
• service mesh sidecar
• ingress controller
• outbound proxy
• corporate proxy
• private connectivity
• payment and banking partners
• KMS, HSM, and secrets services

Every TLS termination point is a policy point. Every re-origination point is a place where the post-quantum property may stop and start again.

That is the platform view. It is less glamorous than reading algorithm names, but it is the view that prevents production surprises.

middleboxes are where optimism goes to die

TLS migrations are rarely broken by the happy path.

They are broken by the thing in the middle that nobody remembers owning.

Post-quantum key exchange makes this worse because larger handshakes and newer TLS extensions stress old assumptions. Some boxes inspect ClientHello messages. Some enforce brittle allowlists. Some have buffer limits. Some do TLS interception. Some fail open, some fail closed, and some fail in a way that looks like random packet loss at 2 percent of traffic.

If you work in fintech, this should feel familiar. The clean architecture diagram says service A calls partner B over TLS. The production path says service A calls an outbound proxy, then a network appliance, then a private connectivity service, then a partner gateway, then something on the other side that nobody is allowed to inspect directly.

The only honest way to migrate that is to test the real path.

Not just "curl from my laptop."

Test from the actual workload environment. Test through the actual proxy. Test with the actual SDK. Test the payment provider sandbox and, when allowed, a controlled production path. Test with connection reuse on and off. Test with the same retry behavior the service uses in anger.

And when the fallback happens, record it.

observability is the migration control plane

Here is the part I would be annoying about in a design review: if nobody can tell what negotiated, nobody has enabled anything meaningful.

A post-quantum TLS rollout needs observability before rollout. At minimum, teams should be able to answer:

• Which TLS version negotiated?
• Which key exchange group negotiated?
• Did the client offer ML-KEM or a hybrid group?
• Did the server select it?
• Did the connection fall back to classical key exchange?
• Which client library and version made the connection?
• Which proxy or load balancer handled it?
• Did handshake failures, latency, or retry rates change?
• Did connection reuse hide a handshake problem until scale changed?

Some of this data lives in load balancer logs. Some lives in CDN analytics. Some can be exposed by TLS libraries. Some may require synthetic probes. Some may need targeted packet captures in test environments.

The exact implementation matters less than the discipline: negotiate, observe, prove, then expand.

"Turn it on" is not a strategy. "We can prove 97 percent of KMS traffic negotiated X25519MLKEM768, 3 percent fell back because of these client versions, and here is the upgrade plan" is a strategy.

That sentence is also the difference between platform engineering and theater.

the readiness gap is real

The internet is not moving as one clean block.

A 2026 measurement study across 32,011 domains found that modern protocols like TLS 1.3 and QUIC are spreading, but a meaningful slice of domains still rely on TLS 1.2, with banking and government called out among the sectors where the gap matters. The same paper looked at negotiated TLS parameters, key exchange, and certificates, which is exactly the sort of messy operational evidence this migration needs.

That finding matches the platform intuition. Consumer browsers and big CDNs can move quickly. Large cloud providers can move their managed endpoints. But enterprise clients, partner integrations, regulated systems, old JVMs, TLS-terminating appliances, and private PKI workflows move slowly.

So the rollout will be uneven.

Uneven rollouts are where compatibility assumptions become incidents.

This is why I dislike the framing of PQC as a security team's future project. Security should absolutely drive the risk model and migration pressure. But the work touches platform ownership: runtime images, SDK baselines, service meshes, gateway configuration, certificate automation, observability, change management, and rollback.

If the only team with a ticket is security, the migration is already under-scoped.

what I would do first

I would not start by mandating post-quantum TLS everywhere.

I would start by making the platform able to see it.

Pick one important but bounded path. AWS KMS is a good candidate for many teams because it is security-sensitive, heavily used, and now has concrete client configuration. Enable hybrid post-quantum TLS in a controlled environment. Record the negotiated group. Measure handshake latency and error rates. Verify that connection reuse behaves the way you think it does. Then try the same thing through your real service runtime, not a toy client.

From there, build the inventory:

• services that can offer hybrid ML-KEM today
• services blocked by old SDKs or TLS libraries
• paths that terminate at the CDN only
• edge-to-origin paths that can negotiate hybrid key agreement
• proxies and middleboxes that need explicit testing
• partner integrations that need certification or support confirmation
• certificate workflows that will be affected later by post-quantum signatures
• dashboards that can prove negotiation and fallback

That gives you a migration map instead of a slogan.

It also gives security something better than "we are waiting for the industry." It gives them dates, owners, blockers, and evidence.

the small checklist

If you want a non-dramatic starting point, this is the checklist I would put in front of a platform team:

• Inventory outbound TLS clients, SDKs, runtimes, and TLS libraries.
• Identify every TLS termination and re-origination point.
• Separate key exchange migration from certificate and signature migration.
• Pick one bounded path, such as KMS, and test hybrid ML-KEM end to end.
• Capture negotiated TLS version, key exchange group, fallback, latency, and errors.
• Test through real proxies, gateways, service meshes, CDNs, and partner paths.
• Check connection reuse assumptions before trusting benchmark numbers.
• Track old SDKs and clients that silently fall back to classical key exchange.
• Add dashboards before broad enablement.
• Treat payment, banking, KMS, HSM, secrets, and private PKI paths as first-class migration surfaces.
• Write the rollback story before turning defaults on.

None of this requires panic.

It does require refusing the comfortable story that post-quantum TLS is just a crypto library upgrade. It is not. It is a platform migration with cryptography inside it.

The teams that do the boring inventory now will have a quiet advantage later. When the defaults move, they will already know which clients can negotiate, which paths fall back, and which certificate workflows are a separate project.

Everyone else will discover their TLS architecture from error rates.

That is a lousy way to learn.

sources

• AWS: ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager
• AWS KMS: Using hybrid post-quantum TLS
• Cloudflare SSL/TLS docs: Post-quantum cryptography
• Cloudflare SSL/TLS docs: Post-quantum between Cloudflare and origin servers
• Microsoft: New Windows Features to Secure Today's Data in a Post-Quantum World
• IETF: 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.