What is Post-quantum Key Exchange?

Short answer

Post-Quantum Key Exchange is a key exchange method developed against the risk that sufficiently powerful quantum computers could break today's key exchange based on elliptic curves and RSA; the main threat is that encrypted traffic recorded today is decrypted in the future ("harvest now, decrypt later"). TLS uses a hybrid approach: the classic X25519 is combined with ML-KEM, which NIST standardized, and the session key is derived from the two components together. In TR7, when Post-Quantum Key Exchange in the TLS Security Profile is turned on, the vService offers the X25519MLKEM768 group as the first preference in TLS 1.3; clients that do not support it continue to connect with the classic groups.

Where It Is Used in TR7

Where	Field / label	What for
Certificates & PKI → TLS Security Profiles → Frontend-only Settings	Post-Quantum Key Exchange (off by default)	Offering the X25519MLKEM768 hybrid group in TLS 1.3; the profile is selected in the SSL Security field of the HTTP or L7 TCP vService
HTTP and L7 TCP vService → Details → QOS	Core Engine	Whether the setting is applied depends on the ML-KEM support of the selected Core engine; if there is no support, a record that starts with The selected core engine does not support is seen in the vService notifications

How Does It Work?

• ML-KEM (Module-Lattice-Based Key-Encapsulation Mechanism) is the key encapsulation algorithm that NIST standardized with FIPS 203 and that is considered resistant to quantum computers.
• In the X25519MLKEM768 group, the client and the server perform both an X25519 and an ML-KEM-768 exchange; because the session key is derived from the two together, security is preserved as long as one of the two algorithms remains unbroken.
• Only the key exchange is post-quantum; certificate signatures and authentication continue to be performed with classic algorithms (RSA, ECDSA).

Common Misconceptions

• "Turning on post-quantum requires the certificates to be changed." It affects only the key exchange; the certificate and authentication stay the same.
• "Clients that do not support it cannot connect." Because the classic groups are offered as a fallback, these clients connect with a classic group; connections are not forced to post-quantum only.
• "The setting also protects the Backend Service connections." The setting is under Frontend-only Settings; it is applied only to the TLS 1.3 connection between the client and the vService (Is post-quantum key exchange supported?).

How it is done in the documentation

• TLS Security Profiles · Post-Quantum Key Exchange
• HTTP (L7) vService · Core Engine

Related questions

• Is post-quantum key exchange supported?
• What are Perfect Forward Secrecy (PFS) and ECDHE?
• What is the difference between the TLS versions (TLS 1.0, 1.1, 1.2, 1.3)?