Hybrid cryptography runs a classical algorithm and a post-quantum algorithm together and combines their outputs, so the session stays protected unless both are broken. It is a transition tool. It hedges against flaws in new algorithms while guarding against future quantum computers that could break today's key exchange.
Why not just switch to the new algorithms?
NIST finalized its first post-quantum standards in 2024. FIPS 203 specifies ML-KEM, a key-encapsulation mechanism whose security rests on the Module Learning with Errors problem. NIST describes ML-KEM as believed secure, even against adversaries with a quantum computer. The word "believed" matters. These algorithms are younger than RSA and elliptic curves, and cryptography has a history of surprises.
Hybrid designs answer that. If the new algorithm turns out to have a flaw, the classical one still protects you against today's attackers. If a quantum machine arrives, the post-quantum half still holds.
What does a hybrid key exchange actually do?
A key-encapsulation mechanism lets two parties establish a shared secret over a public channel. NIST SP 800-227, published in September 2025, covers the definitions, properties and recommendations for using KEMs.
In a hybrid exchange, the client and server run two key exchanges at once, for example an elliptic curve exchange plus ML-KEM. The two shared secrets are joined and fed into the key schedule. RFC 9954, published in July 2026, defines hybrid key exchange in TLS 1.3. Its stated goal is security even if a way is found to defeat all but one of the component algorithms. It names combinations such as X25519MLKEM768 and SecP256r1MLKEM768 as examples.
What are the costs?
Two practical ones. Handshake messages grow, because the client sends a post-quantum public key alongside the classical one. The RFC notes that offering two combinations means sending two ML-KEM-768 keys, since each combination carries its own copy. Larger first flights can hit middleboxes and old devices that mishandle big packets.
The second cost is negotiation. RFC 9954 describes what happens when only one side understands hybrids: they should fall back to a non-hybrid secret, if the hybrid-aware party is willing to downgrade. That is a policy choice. If you allow the fallback, an old peer still connects, and you also keep a classical-only path alive.
Why bother before quantum computers exist?
Because recorded traffic can be attacked later. Someone who stores encrypted sessions today could try to open them when a capable machine exists. Data that must stay secret for many years is the exposed group. NIST's post-quantum project says quantum machines may be years or decades away, and it advises organizations to begin applying the new standards now.
A constructed example
An archive service keeps medical-style records that must stay confidential for 25 years. Its internal API gateway terminates TLS 1.3. The team first inventories every place it uses key exchange: public TLS, service to service calls, VPN tunnels, and signed software updates. They enable a hybrid group on the gateway, watch handshake failures for two weeks, and find one old batch client that chokes on the larger handshake. They upgrade that client instead of switching hybrids off.
Note that key exchange and signatures are separate problems. Hybrid key exchange protects confidentiality of recorded traffic. Signature migration is a different job with its own timeline.
How to check or apply this
- Inventory where your systems use public-key cryptography: TLS, VPN, SSH, code signing, certificates, embedded devices.
- Rank by how long the data must stay secret. Start with the longest.
- Enable hybrid TLS key exchange on endpoints you control, then monitor handshake errors and latency.
- Decide your downgrade policy in writing, and log when fallback happens.
- Ask suppliers which libraries and appliances support ML-KEM, and when.
- Keep a cryptographic bill of materials so the next algorithm change is cheaper.
Quick check
Does hybrid mean weaker security?
No. The goal is that the combined secret is safe if at least one component holds. It adds size and complexity, not a weaker floor.
Is hybrid permanent?
Not necessarily. It is a transition approach. NIST continues to develop further standards as backups and alternatives, so plan for change.
Sources
- NIST FIPS 203, ML-KEM standard
- NIST SP 800-227, Recommendations for Key-Encapsulation Mechanisms
- RFC 9954, Hybrid Key Exchange in TLS 1.3
- NIST Post-Quantum Cryptography project
Last reviewed: 18 October 2026.
