Hybrid Post-Quantum TLS Reaches Production: Early Bank Pilots

The post-quantum migration spent years as a planning exercise — standards being drafted, timelines being argued, risk being modelled. As of early 2026, it has a production foothold. A number of banks and financial-infrastructure operators have begun piloting hybrid key exchange in TLS 1.3 for their cloud-facing APIs, combining the classical X25519 elliptic-curve exchange with the lattice-based ML-KEM mechanism standardized by NIST. It is a modest-sounding change — a different key-agreement algorithm inside an existing protocol — but it marks the point at which post-quantum cryptography stopped being a future obligation and started being deployed traffic.

Why “Hybrid” and Not Just Post-Quantum

The instinct, on hearing that quantum computers will eventually threaten today’s public-key cryptography, is to rip out the old algorithms and replace them with the new ones. Hybrid key exchange deliberately does not do that. Instead, it runs a classical algorithm and a post-quantum algorithm side by side in the same handshake, and derives the session key from both. The connection is secure as long as at least one of the two remains unbroken.

The reasoning is straightforward risk management. The classical algorithms (X25519 and its relatives) have decades of cryptanalysis behind them and are extremely well understood. The post-quantum algorithms are newly standardized and, while subjected to intense scrutiny during the standardization process, have a far shorter track record. A flaw discovered in a young algorithm would be catastrophic if it were the sole protection; in a hybrid construction it is merely an inconvenience, because the classical algorithm still stands. Conversely, the post-quantum component protects against the future quantum threat that the classical algorithm cannot. Hybrid gives you the union of both guarantees and the failure of neither, at the modest cost of a larger handshake.

That larger handshake is the main practical cost. ML-KEM public keys and ciphertexts are substantially bigger than elliptic-curve equivalents, which inflates the TLS handshake by a few kilobytes and can push it across packet boundaries it previously fit within. For high-volume API endpoints this is measurable, which is precisely why production pilots — rather than lab benchmarks — are the right way to learn whether it matters for a given workload.

The Standards Foundation

This deployment wave rests on cryptographic standards that landed over the preceding eighteen months. In August 2024, NIST finalized its first post-quantum standards — FIPS 203 (ML-KEM, the key-encapsulation mechanism derived from CRYSTALS-Kyber), FIPS 204 (ML-DSA, a signature scheme), and FIPS 205 (SLH-DSA, a hash-based signature scheme). ML-KEM is the relevant one for TLS key exchange, and it is the post-quantum half of the hybrid constructions banks are now piloting.

In March 2025, NIST selected HQC as a backup key-encapsulation mechanism, based on a different mathematical foundation (error-correcting codes rather than structured lattices). HQC is intended as algorithmic insurance: if a structural weakness were ever found in the lattice family, HQC offers a fallback that does not share the same underlying assumptions. The HQC standard itself is still being finalized, so the current pilots are built on ML-KEM, with HQC representing the diversity option for the longer term.

For TLS specifically, the relevant engineering work is the specification of hybrid key-exchange groups for TLS 1.3 — combining X25519 with ML-KEM-768 into a single negotiated group. Major TLS libraries and the network stacks of large content and cloud providers have supported these hybrid groups for some time, which is why a bank can pilot them today against cloud APIs without building cryptography from scratch.

Why Banks Moved First

Financial institutions are not usually the first to adopt new infrastructure, so their early move here is worth explaining. Three factors converge.

The first is the “harvest now, decrypt later” threat model. An adversary can capture encrypted traffic today and store it, waiting for a future quantum computer capable of breaking the key exchange retroactively. For data with a long confidentiality lifetime — and financial and personal data often must remain confidential for many years or decades — the quantum threat is effectively a present threat, because today’s captured traffic is tomorrow’s decrypted breach. Banks hold exactly this kind of long-lived sensitive data.

The second is regulatory and supervisory pressure. Financial regulators and central banks have been signalling for some time that institutions should have post-quantum migration plans, and that signalling has sharpened into expectations. Cryptographic agility — the ability to change algorithms without re-architecting systems — has become a supervisory talking point. Piloting hybrid TLS is a concrete demonstration that an institution is acting on those expectations rather than merely documenting them.

The third is the maturity of cloud-facing APIs as the natural starting point. A bank’s externally exposed API gateway is a well-bounded, heavily monitored surface where a TLS change can be piloted, measured, and rolled back without touching core systems. It is the lowest-risk place to gain operational experience with post-quantum key exchange, which is why it is where the pilots are concentrated rather than in internal service meshes or storage encryption.

What the Pilots Are Actually Measuring

These are pilots, not migrations, and the distinction matters. The questions they are designed to answer are operational, not cryptographic:

Handshake latency and throughput. Does the larger ML-KEM handshake measurably affect connection establishment time and endpoint capacity under real traffic, and if so, by how much?
Middlebox and client compatibility. Network appliances, load balancers, and older clients sometimes mishandle TLS handshakes that exceed expected sizes. Production traffic surfaces these incompatibilities in ways lab testing does not.
Operational tooling. Do monitoring, logging, and certificate-management systems correctly understand and report on hybrid key exchange? Cryptographic changes that confuse the observability stack create their own operational risk.
Crypto-agility in practice. Can the institution change the negotiated group across its fleet quickly and safely? The pilot is as much a test of the deployment and rollback machinery as of the algorithm itself.

The note of caution worth sounding: the signature side of the post-quantum migration — authenticating connections and verifying certificates — is harder and further behind than the key-exchange side. Post-quantum signatures are larger and more disruptive to certificate ecosystems, and the pilots described here address confidentiality (key exchange) rather than authentication (signatures). The full migration is a longer road; hybrid key exchange in TLS is the first well-paved stretch of it.

Implications for Cloud-Facing Systems

For teams running cloud APIs and services beyond financial services, the bank pilots are a useful leading indicator. The practical takeaways:

Inventory your long-lived secrets. The harvest-now-decrypt-later threat is real for any data that must stay confidential for years. Identify which of your traffic carries such data; that is where hybrid key exchange matters most and soonest.
Prioritize crypto-agility. The specific algorithms will continue to evolve. Systems that can change negotiated TLS groups through configuration rather than re-engineering are positioned to adopt improvements as they arrive — and to respond if a weakness is found.
Test handshake size assumptions. If any part of your network path assumes TLS handshakes fit within a particular size, post-quantum key exchange will challenge that assumption. Find out now, on a pilot endpoint, rather than during a fleet-wide rollout.
Treat the migration as multi-year. Key exchange first, signatures later. Plan the program in stages rather than expecting a single cutover.

Conclusion

The arrival of hybrid post-quantum TLS in bank pilots is the concrete first step of a migration that has been theoretical for years. The hybrid approach — classical plus post-quantum, secure if either holds — is the pragmatic bridge that lets institutions adopt new cryptography without betting everything on its untested track record. Finance moved first because it holds long-lived sensitive data and faces supervisory pressure, but the path it is mapping applies to any organization running cloud-facing services. The standards are finalized, the libraries support it, and the production experience is starting to accumulate. The migration has left the planning document.