Hybrid post-quantum TLS: deploying X25519 + ML-KEM today

The safest way to migrate to post-quantum cryptography is not to flip a switch from classical to quantum-safe overnight � it is to run both at once. Hybrid key exchange combines a battle-tested classical algorithm (X25519) with a post-quantum one (ML-KEM, the standardized form of Kyber, NIST FIPS 203) so that the session key is secure as long as EITHER one holds. If a flaw is found in the young post-quantum scheme, you are still protected by X25519; if a quantum computer breaks X25519, you are still protected by ML-KEM. You are never weaker than today, and you gain quantum resistance immediately.

This matters because the threat to confidentiality is already here in the form of harvest-now-decrypt-later: an attacker records your encrypted traffic today and decrypts it once a quantum computer exists. Major deployments have already moved � hybrid X25519+ML-KEM-768 is shipping in mainstream browsers and TLS libraries. The practical cost is modest: the post-quantum key share is larger (about 1.2 KB), so you budget a little extra bandwidth in the handshake, but the cryptographic operations are fast and the rest of TLS is unchanged.

The honest scope is worth stating plainly. Hybrid TLS protects the confidentiality of data in transit against known classical and quantum attacks per NIST � it is not unbreakable, and it does not retroactively protect traffic an attacker already harvested under pure-classical crypto. It is forward protection: everything from the moment you deploy it onward. For anything with a long confidentiality lifetime, starting the hybrid migration now is the rational, low-risk move, and a simple post-quantum API lets you experiment with ML-KEM key encapsulation without re-implementing the lattice math yourself.