Should you use hybrid post-quantum key exchange or ML-KEM alone?

Hybrid key exchange runs a classical scheme and a post-quantum scheme together, so the derived key stays safe if either one holds. It adds complexity but hedges against a flaw in the newer algorithm. NIST leaves the choice to each application, weighing cost, performance and engineering complexity.

What hybrid means

A hybrid key-establishment mode combines two or more schemes, at least one quantum-resistant and often one classical, into a composite. NIST's draft transition report says the point is that derived keys remain secure if at least one of the component schemes remains secure.

This guards against two risks: a cryptographic break in a new algorithm, and an implementation bug in new code.

What NIST says

• NIST will accommodate the use of a hybrid key-establishment mode in FIPS 140 validation when it is combined with a NIST-approved scheme.
• The same page says future experience will help decide whether hybrids can be a useful long-term solution.
• The draft IR 8547 says hybrid solutions add complexity, and are typically expected to be temporary measures leading to a second transition to pure post-quantum.

So hybrid is accepted, not required, and probably a stepping stone.

When hybrid makes sense

• You want protection against harvest now, decrypt later today, and you also want classical security as a fallback while ML-KEM implementations mature.
• Your library or protocol stack already offers a hybrid option as a software update. Cloudflare reported in October 2025 that over 50 percent of its human traffic used post-quantum key agreement, which suggests post-quantum key agreement is already common on the web.
• Your auditors or customers are more comfortable with a classical component present.

When ML-KEM alone may be enough

• A closed system where you control both ends and want a smaller code path.
• A sector or procurement requirement that points to a specific mode. Check it before you decide.

Cost of hybrid

Messages get larger because you send keys and ciphertexts for both schemes. Handshakes cost slightly more. Code paths double. Test for packet size limits, middleboxes that choke on larger handshakes, and fallback behavior. Never silently fall back to classical only without logging it.

Decision steps

1. Check what your protocol and libraries support today.
2. Check any regulator or buyer requirement.
3. Default to the option your stack supports with the fewest custom parts.
4. Document the choice, the date and the conditions for revisiting.

Whichever you choose, log it. Record which key exchange each connection or session used, so that when policy changes you can see how many peers still negotiate the classical-only path. That log is also your evidence for an auditor or a customer who asks how far along the migration is, and it costs almost nothing to collect if you add it at the start.

Quick check

Sources

• NIST PQC FAQs
• NIST IR 8547 initial public draft, full text
• Cloudflare, state of the post-quantum Internet in 2025

Last reviewed: 19 October 2026.