Read this first
For TLS 1.3 hybrid key exchange, use X25519MLKEM768 (the X-Wing-style construction that has become the de facto default). Lattice confidence is earned, not assumed — keeping a classical component is cheap insurance, and the real risk in hybrids is implementation complexity.
A hybrid combines a classical primitive with a post-quantum one so the result is secure as long as either component holds. For key exchange this is attractive: the classical part protects you if a weakness is found in the lattice assumption, and the post-quantum part protects you against harvest-now-decrypt-later.
Hybrid KEMs are not hybrid signatures
It is tempting to reason about “going hybrid” uniformly. Don't. A hybrid KEM combines two shared secrets through a key-derivation step; a hybrid signature scheme has to decide what it means for a message to be signed by two schemes at once, and how a verifier treats partial validity. They are different problems with different pitfalls.
Use the TLS group, not a bespoke combiner
Adopt X25519MLKEM768 as exposed by your TLS library rather than designing your own KEM combiner. It has had cryptographic review, an assigned named group, and broad deployment. A custom combiner is surface area you do not need.
The real risk in hybrid construction is not that the cryptography is weak — it is that the construction is complex, and complexity is where bugs live. Concatenation order, domain separation in the KDF, and how downgrade is handled are all places where a plausible-looking hybrid can quietly fail.
Lattice confidence is earned, not assumed
The lattice assumptions behind ML-KEM are well studied but younger than the classical ones. Keeping a classical component in the hybrid is inexpensive and removes a single point of failure — there is little reason to drop to a PQ-only KEM for general traffic today.
Have a system that needs this?
Secure my organization