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

Post-quantum TLS stopped being a cryptography conference topic and became ordinary platform work some time in 2026.

Most engineering teams did not notice, because it arrived the way most infrastructure changes arrive: as defaults.

A cloud SDK bump. A CDN flag flipped at the edge. A KMS endpoint that negotiates something different than it did last quarter. A browser quietly preferring a hybrid group on every TLS 1.3 handshake. Nobody got a migration project. Everybody got a migration surface.

The quantum-timeline argument is a distraction here. Whether RSA falls in 2030, 2035, or later than anyone alive cares about is a legitimate research question and a completely useless planning input for a platform team. The engineering problem is not “when does quantum break RSA?” The problem is:

Do we know which of our services, SDKs, middleboxes, payment integrations, and certificate workflows actually tolerate larger handshakes, hybrid key exchange, ML-KEM defaults, and eventually post-quantum signatures?

That question has a boring, testable answer. That is what makes it a platform problem.

the narrow technical shift nobody explained clearly

Let me compress the crypto down to the part platform engineers need.

TLS 1.3 has two cryptographic jobs:

1. Key agreement — both sides derive a shared secret so the rest of the session can be encrypted.
2. Authentication — the server proves who it is, usually with an RSA or ECDSA certificate signature.

Post-quantum work is hitting these two at different times, with different maturity, and different operational blast radius. Conflating them is how teams end up with a two-year plan that should have been a two-week test.

Key agreement is the part already shipping. The dominant approach is hybrid: keep the classical X25519 exchange and add an ML-KEM (formerly Kyber) component alongside it. The session secret stays safe as long as either component holds. Cloudflare’s implementation is the one most people will meet first — X25519MLKEM768 is now a standard group in TLS 1.3, supported at the edge and documented for edge-to-origin paths.

The practically relevant property of hybrid key exchange? Nothing breaks because it’s post-quantum. It breaks because it’s bigger.

Signatures and certificates are the slower half. ML-DSA exists and is being integrated, but post-quantum certificate authentication touches CA hierarchies, trust stores, client compatibility, device firmware, and the whole certification lifecycle. That is a genuinely multi-year migration. It is also not what most of the “we support PQC” announcements are about, which is why reading them carefully matters.

IETF work on ML-KEM for TLS 1.3 is active through 2026, so the wire format is close to settled. Good news: you can test now.

why this is already on your platform, whether you planned it or not

The reason I think platform teams should care right now is not standards activity. It is that the defaults are moving underneath you.

• AWS already supports ML-KEM hybrid post-quantum TLS for KMS, ACM, and Secrets Manager, and has signaled that older CRYSTALS-Kyber support will be removed across AWS service endpoints in 2026. That is a deprecation with a date, which is the most reliable form of “you will deal with this.”
• Cloudflare documents PQC across its TLS stack, including X25519MLKEM768 and ML-DSA for origin authentication.
• Microsoft has shipped Windows platform support for ML-KEM hybrid TLS groups and is talking publicly about accelerating migration of critical products toward 2029.
• Measurement work from mid-2026 across tens of thousands of domains shows readiness is deeply uneven — banking and government endpoints lagging, post-quantum certificate adoption near zero.

That last point is the most useful one for anyone building fintech infrastructure. The interesting question is never “does PQC work?” It obviously works in a lab. The interesting question is where in your call graph it stops working, because that is where your production traffic goes.

translate it into platform work

Here is the honest version of the migration.

inventory outbound clients and TLS stacks

Every service that opens a TLS connection is a client, and most of them are invisible. Go’s crypto/tls, Java’s JSSE, Node’s OpenSSL bindings, Python’s ssl, Rust’s rustls, plus every vendor SDK that bundles its own stack. Count the language runtimes, then count the SDKs that don’t respect the runtime’s defaults.

That second number is usually the surprise.

test service-to-service paths through every middlebox

This is where the migration actually gets hard, because the interesting failures live in components nobody considers TLS clients:

• reverse proxies and load balancers
• API gateways
• service meshes with mTLS everywhere
• CDN edge-to-origin links
• WAFs doing TLS inspection
• payment and banking integrations with fixed TLS profiles
• old appliances that will never get a firmware update

A middlebox that reconstructs or inspects TLS can choke on a ClientHello it doesn’t recognize. Some will reject unknown key share groups. Some will negotiate down. Some will fail in a way that only shows up under load.

watch the right signals

You cannot migrate what you cannot observe. The measurements that matter during a PQC rollout are not CPU graphs:

• handshake size on the wire
• handshake latency, especially cold connections across regions
• TLS error rates split by client version and destination
• negotiated group per connection — this is the number that tells you whether the hybrid path is actually being used
• fallback rates, because a silent fallback to classical key exchange looks identical to success if you only check for errors

That fallback point deserves emphasis. A connection that quietly negotiates X25519 instead of X25519MLKEM768 is working. It is also not post-quantum. If your only signal is “did the request succeed,” you will report a green migration that never happened.

plan certificates as a separate track

Key exchange and signatures are different projects with different timelines. Hybrid key agreement can be enabled, measured, and rolled back in weeks. Post-quantum certificate chains touch CA operations, trust stores, hardware, and code signing, and they are a genuinely long-horizon program.

Do not let the first one create fake urgency for the second, and do not let the second block the first.

don’t make this a security-team ticket

This is the mistake I’d push back on hardest. If PQC lands in the security backlog as a single ticket titled “quantum readiness,” it will sit there until a cloud provider forces the issue at a bad time.

The work is distributed by nature:

• platform owns the runtime and library inventory
• service teams own their SDKs and integration tests
• networking owns proxies, gateways, and middleboxes
• security owns the crypto policy and the deprecation timeline awareness
• SRE owns the observability and rollback path

That is a coordination problem, not a crypto problem. Treating it as crypto is how it stays unowned.

“turn it on” is not a strategy

The skeptical core of this post: enabling hybrid post-quantum TLS is a one-line config change in most stacks, and that is exactly why it is dangerous.

If you flip the flag and nobody can answer these, you haven’t migrated anything:

• Which clients negotiated the hybrid group, and which silently fell back?
• Which services failed to connect, and did they fail loudly or retry down to classical?
• What does the handshake look like through the proxy, the mesh, and the CDN?
• Can we revert without a full deploy?
• Do we know the before/after handshake size and latency numbers for our real traffic, not a benchmark?

That is the standard I’d hold a PQC rollout to. Not “we enabled it.” “We can prove what negotiated, what fell back, and what broke.”

a practical starting checklist

Small on purpose. This should be days of work, not a program.

1. List every TLS stack you ship. Runtimes, SDKs, proxies, sidecars, appliances. Note who owns each.
2. Pick one internal call path — a low-risk service-to-service link through your gateway — and enable hybrid key exchange there.
3. Instrument the negotiated group per connection. If you can’t see it, stop and fix that first.
4. Record baseline handshake size and latency before the change, and compare after. Cold connections across regions, not localhost.
5. Test the middleboxes deliberately. Force the new group, watch the proxy, mesh, and any TLS-inspecting appliance. Break it on purpose in staging.
6. Write the rollback down. One flag, one revert, one documented path back to classical.
7. Track the deprecations. Kyber removal, SDK changes, CDN defaults. These are the real deadlines; the quantum timeline is not.
8. Separate the certificate track and give it a real owner with a multi-year horizon.

Do that and you will be ahead of most of the industry for a fraction of the cost, because the industry is currently waiting for a reason to start.

The cloud providers are not waiting. They are making Post-quantum TLS the default quietly, endpoint by endpoint, and the only question that matters is whether you find out from a rollout you ran or from an incident you didn’t.

sources

• AWS: 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
• Cloudflare: post-quantum cryptography to origin
• Microsoft: new Windows features to secure today’s data in a post-quantum world
• IETF draft: ML-KEM key agreement for TLS 1.3
• Measurement of post-quantum readiness across 32,011 domains (June 2026)

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