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

Every few months someone asks me when quantum computers will break RSA.

I have stopped answering that question, because it is not the question engineering teams actually have.

The question they have is much less glamorous: do we know which of our services, SDKs, middleboxes, payment integrations, and certificate workflows will tolerate a bigger handshake, a hybrid key exchange, and eventually post-quantum signatures? Most teams cannot answer that today. And 2026 is the year the cloud providers started answering it for them, by changing the defaults.

That is the whole story. The quantum timeline is a distraction. The migration is already arriving through the boring doors: managed TLS endpoints, SDK defaults, CDN edge configuration, OS crypto libraries, and certificate tooling.

the narrow technical shift

Strip away the hype and the change is small and specific.

TLS 1.3 key exchange is currently dominated by X25519, an elliptic-curve Diffie-Hellman variant. It is fast, small, and well understood. The post-quantum concern is not that someone recorded your traffic and can decrypt it now. It is that a future quantum computer could decrypt recorded traffic later, which is exactly why anything with a long confidentiality lifetime, like a banking session log or a signed document, gets uncomfortable first.

The industry response was never "replace X25519 with something quantum-safe." It was hybrid: run the classical curve and the post-quantum key encapsulation together, and combine the results. If either holds, the session holds. That is what ML-KEM (FIPS 203, the standardized descendant of CRYSTALS-Kyber) provides, and it is why the IETF draft on ML-KEM for TLS 1.3 exists in the first place.

The practical consequence is size. A hybrid key share is much larger than an X25519 key share. That means:

• bigger ClientHello messages
• more bytes before the handshake completes
• more chances to hit fragmentation, MTU limits, or middleboxes that "helpfully" drop what they do not recognize
• more chances for an old client to negotiate a fallback group and nobody notice

And here is the part people conflate: key exchange and signatures are different problems with different timelines. ML-KEM protects the session key. Post-quantum signatures and how they land in certificates and code signing is a separate migration with its own compatibility and trust-chain pain. You can ship the first without having solved the second, and you probably should, because the first is already being turned on for you.

what changed in 2026

This stopped being a standards-track slide deck this year.

AWS shipped ML-KEM hybrid post-quantum TLS support across KMS, ACM, and Secrets Manager, and it is explicit that the older CRYSTALS-Kyber support will be removed across AWS service endpoints in 2026. That second sentence is the one to underline. This is not an opt-in curiosity anymore. It is a controlled API surface with a deprecation calendar attached.

Cloudflare documents post-quantum support for edge-to-origin TLS, including X25519MLKEM768 for key agreement and ML-DSA for origin authentication, with clear notes about where it is supported and where it is constrained. Microsoft shipped Windows platform support for ML-KEM hybrid TLS groups and is openly talking about an accelerated migration path for critical products and services toward 2029. The IETF draft for ML-KEM in TLS 1.3 is active.

And then there is the measurement reality. A June 2026 measurement paper looking at post-quantum readiness across more than 32,000 domains found the internet is not uniformly ready, with particular lag around banking and government TLS 1.2 endpoints and post-quantum certificate adoption. I find that more useful than any roadmap slide, because it says the failure modes will be uneven and depend on what your specific clients do.

translate it into platform work

Here is where I push back on how most teams are framing this.

If PQC lives only in a security-owned ticket, it will get treated as a cryptography review that produces a PDF and no changes. That is a mistake. The actual work is platform work, and it looks a lot like every other platform migration you have done badly before.

Inventory your outbound clients and TLS stacks. Not your externally facing load balancers, which are usually the easy part, but everything that makes an outbound TLS connection. Application runtimes, language crypto libraries, JDK versions, Go and Rust toolchains, database drivers, message bus clients, cron jobs, batch exports, and the one internal tool that has not been rebuilt since a migration ago. Different stacks gain hybrid group support at different times, and some old ones never will.

Test service-to-service paths end to end. A handshake does not happen between two applications. It happens through whatever is in the middle: proxies, API gateways, service meshes with their own TLS origination, CDNs, WAFs, egress filters, and vendor middleboxes that terminate and re-establish TLS. Those are where the surprises live. Payment and fintech integrations are the highest-stakes version of this, because a partner that pins groups, inspects traffic, or terminates in something old will fail in a way that looks like "the vendor is down."

Watch the right signals. This migration is observable, which is the only good news in the story. Track negotiated group, not just protocol version. Track handshake size and handshake latency, because hybrid key exchange changes both. Track fallback and retry counts, because a silent fall back to a classical group is the most likely failure mode and it will look like success unless you instrument it. Track TLS error rates by client version and by dependency.

Split certificates and code signing from key exchange. Do not let an ML-KEM rollout turn into an ML-DSA certificate plan. Hybrid key exchange is mostly a library-and-config change. Post-quantum certificates and code signing involve CA support, trust stores, chain sizes, and signing infrastructure that your build pipeline may not tolerate yet. Separate owners, separate timelines, separate proof.

Do not hand it to security alone. Security should define the standard and the target state. Platform should own the inventory, the rollout mechanics, the fallback policy, and the observability. Application teams own their own clients. If nobody owns the list of things that must still work, the list will be incomplete at exactly the wrong moment.

"turn it on" is not a strategy

My biggest skepticism about how this is being sold is the implied simplicity. Enable hybrid groups, prefer PQC, done.

That is not a strategy, because it cannot answer three questions:

What actually negotiated? If you cannot show, per path, which group was used, you do not know whether you are post-quantum or whether a proxy quietly negotiated something classical on your behalf.

What fell back, and why? Fallback is not automatically a failure, but an unobserved fallback is. Browsers and clients will happily downgrade. If you are not measuring it, you are guessing.

What broke? Bigger handshakes hit real constraints: MTU and fragmentation, connection setup latency budgets, throughput on high-connection-count services, and any queue or timeout that was tuned against a smaller handshake. You will find these in a canary, or you will find them in production.

A migration you cannot observe is a migration you cannot finish. You will end up with a partial rollout, a permanent exception list, and a security posture that only exists on the diagram.

a small checklist to start without panic

You do not need to rewrite anything this quarter. You need to know things you currently do not know.

1. List every TLS client you operate, with the runtime and crypto library version behind each one.
2. Pick three paths: one internal service-to-service, one through a proxy or mesh, one to an external partner or payment integration.
3. Turn on hybrid key exchange in a non-production environment and capture what negotiated, what fell back, and how big the handshake got.
4. Add negotiated group and handshake metrics to your existing TLS observability before you roll anything out.
5. Write down your fallback policy explicitly: are silent classical fallbacks acceptable, and for how long?
6. Track the AWS CRYSTALS-Kyber removal timeline and any provider deprecation notices for the endpoints you depend on.
7. Keep certificate and code-signing PQC work in a separate track with its own owner.
8. Give the whole thing a name, an owner, and a date. A migration without an owner is a rumor.

None of this requires predicting quantum computing timelines. It requires knowing your own system, which is the same work that makes every other migration survivable.

The teams that treat post-quantum TLS as a platform inventory problem will barely notice when the defaults flip. The teams that wait for the cryptography debate to resolve will discover, under pressure, that the change already shipped in a dependency they do not control.

sources

• ML-KEM post-quantum TLS now supported in AWS KMS, ACM, and Secrets Manager
• AWS KMS post-quantum TLS client configuration
• Cloudflare post-quantum cryptography documentation
• Cloudflare PQC to origin
• New Windows features to secure today's data in a post-quantum world
• IETF draft: ML-KEM for TLS 1.3
• Measurement of post-quantum readiness across the web (arXiv)

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