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

The least useful question in post-quantum cryptography is "when does the quantum computer arrive?"

Nobody in a platform team can answer it, nobody in a standards body will commit to it, and whatever number you get will be wrong. Meanwhile, the migration has already started arriving in the places that actually run your traffic: cloud provider defaults, TLS libraries, browser negotiation, CDNs, and SDK versions you upgrade without reading release notes.

That is the part worth paying attention to.

Post-quantum TLS stopped being a research topic and became platform work. And platform work has a familiar shape: inventory, compatibility testing, observability, rollback. Not a decision about whether lattice cryptography is beautiful.

The technical change is narrower than the marketing

Worth being precise about what is actually changing, because the vendor noise blurs two different problems.

TLS 1.3 key agreement is moving to hybrid modes. The widely deployed one is X25519MLKEM768: a classic elliptic-curve exchange combined with ML-KEM, so the session stays safe if either component holds up. This is the part that is shipping now, in browsers, CDNs, cloud SDKs, and operating systems.

The other problem is authentication: post-quantum signatures and certificates, ML-DSA and friends, which change your PKI, your certificate authorities, your code signing, and your hardware security modules. That part is much earlier, much messier, and mostly not your 2026 problem.

Keeping those two apart is the first useful thing a platform team can do, because they have completely different risk profiles and timelines. Hybrid key exchange is a configuration and compatibility question. Post-quantum signatures are a PKI program with procurement attached.

Why it shows up as platform work

Here is the pattern that makes this concrete rather than philosophical.

AWS supports ML-KEM hybrid post-quantum TLS in KMS, ACM, and Secrets Manager, and has said older CRYSTALS-Kyber support is being removed from AWS service endpoints during 2026. That is not a research preview. That is a default that moves under your feet while your code stays the same.

Cloudflare documents post-quantum key agreement for TLS 1.3, plus edge-to-origin guidance where the interesting constraints live: what your origin supports, what your proxy negotiates on your behalf, and where a hybrid handshake quietly falls back to something classical because a middlebox or an old client could not cope.

Microsoft has shipped Windows platform support for ML-KEM hybrid TLS groups and ML-DSA APIs, and talks about accelerating migration of critical products toward 2029.

The IETF work for ML-KEM in TLS 1.3 is active and already close enough to operational reality that vendors are building against it, not merely citing it in slide decks.

And the measurement work is sobering. A June 2026 paper looked at post-quantum readiness across more than 32,000 domains and found adoption uneven in exactly the places you would expect: older TLS 1.2 endpoints in banking and government, weak post-quantum certificate support, and readiness that does not track neatly with how security-critical the service is.

Read those together and the conclusion is not "learn post-quantum cryptography." It is: within the next year or two, a meaningful fraction of your outbound connections will negotiate a different key exchange than they do today, some will fall back, a few will break, and you will find out either from your own telemetry or from an incident.

The migration surface nobody has inventoried

Ask a team which of their applications make outbound TLS connections and you will get an approximate answer covering the services somebody remembers.

That is not an inventory. It is a memory.

The real list includes JVM keystores with their own TLS provider, Go and Rust binaries with statically linked crypto, Node services on whatever OpenSSL the base image shipped, Python clients behind a requests library nobody has upgraded since 2023, database drivers, message brokers, Kafka and Redis and Postgres clients, service mesh sidecars with their own TLS stack, egress gateways, forward proxies, customer-managed load balancers, vendor payment SDKs, webhook callbacks, and that one cron job on a VM that talks to a partner API.

Then add the paths those clients traverse. A handshake does not happen between two services. It happens through whatever sits between them, and middleboxes have opinions about packet sizes, TLS extensions, connection reuse, and session resumption. A hybrid post-quantum ClientHello is larger than a classical one, which is precisely the kind of change that historically finds the appliance that was only ever tested against one vendor's stack.

Fintech integrations deserve their own column in the spreadsheet. Partner-facing APIs are the connections where you have the least control, the longest change windows, and the highest cost of a surprise, and where the other side's readiness is a dependency you cannot schedule.

What to actually measure

The instinct is to turn the thing on and see if anything breaks. That works right up until it breaks quietly.

The useful signals are the boring ones, and most of them are not on a dashboard yet:

• Negotiated key exchange group per path. Not the library version. The actual group that came out of the handshake, broken down by client, destination, and time. Without this you cannot answer "did it hybridize or silently fall back?"
• Handshake size and completion rate. Track handshake bytes, not just latency. Some failures show up as retries and timeouts rather than errors, and a retry storm at 3 AM looks nothing like a TLS regression until you go looking.
• CPU cost on the crypto path. ML-KEM is not free, and session establishment is where it lands. AWS measured roughly 80 to 150 microseconds of additional cryptographic compute for ML-KEM operations. That is small, but small costs can still matter when your workload burns through short-lived connections.
• Fallback counts, by peer. A fallback is not a failure, but it is a fact you should be able to count, attribute, and explain.
• Certificate and trust changes separately. Keep the signature migration out of the key-exchange rollout so that when something breaks, you know which change caused it.

If none of that exists today, then the first deliverable of the post-quantum program is not a TLS profile. It is telemetry that can prove what negotiated.

"turn it on" is not a strategy

Here is the skeptical part, and it is the reason I think this belongs in the platform backlog rather than only in the security backlog.

Every migration of this kind follows the same arc. A vendor enables a smart default, an SDK upgrade pulls a new TLS stack in, a CDN flips preference for hybrid key agreement, and traffic starts negotiating differently. In the best case, nothing changes and everyone moves on. In the common case, a subset of connections fall back, a smaller subset fail, and the difference between "secure" and "appears to work" is a diagnostic nobody instrumented.

That is the same failure mode we have seen with certificate expiry, cipher deprecations, and DNS changes. The change is technically small and operationally invisible, which is the worst combination, because it means the only signal is customer impact.

The teams that get through this well will not be the ones that deployed ML-KEM first. They will be the ones who could say, on any given day, which of their connections used a hybrid group, which did not, which path is responsible, and what happens if the answer changes overnight.

A checklist that does not require panic

If I were running this, I would start here, in this order.

1. Inventory outbound TLS clients by owner, not by hostname. Every service, job, and script that opens a TLS connection, with the team that owns it. Group by language runtime and TLS provider, because that is what determines upgrade cost.
2. Map the paths, not just the endpoints. For each critical dependency, list what sits in between: proxy, gateway, mesh, CDN, partner appliance. The path is where compatibility surprises live.
3. Instrument the negotiated group before you change anything. You cannot claim success or detect regression without a baseline that predates the rollout.
4. Pilot with hybrid key exchange preference enabled on one path family. Prefer the boring internal ones first, then a partner integration with a real change window.
5. Rehearse rollback. Know how to force a fallback per path, and test it while there is time to be wrong.
6. Separate the signature and trust workstream. Track it, fund it, but do not entangle it with the key-exchange rollout. It is a PKI program, and it will be slower.
7. Write down who owns it. Post-quantum TLS that belongs to "security" in general belongs to nobody in particular, and will be rediscovered during an incident.

None of that is exotic. It is the same discipline as any other cross-cutting platform change, applied to a change that is arriving through defaults instead of through a project plan.

References

• AWS Security Blog: ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager
• AWS KMS Developer Guide: Post-quantum TLS for AWS KMS
• Cloudflare Docs: Post-quantum cryptography
• Cloudflare Docs: Post-quantum cryptography to origin
• Microsoft Security Blog: New Windows features to secure today's data in a post-quantum world
• IETF: ML-KEM for TLS 1.3 draft
• 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.