Post-quantum TLS: the UK publishes the settings to enable on your servers

X25519MLKEM768. This somewhat cryptic name now tops the UK's official recommendations for securing a web connection. On October 15, the National Cyber Security Centre (NCSC), the United Kingdom's cybersecurity agency and the counterpart of France's ANSSI, updated its guide "Using TLS to protect data" with post-quantum configurations. These settings are ready to copy into server configurations.

The update follows the publication of RFC 10024 by the IETF, the body that standardizes Internet protocols. The RFC defines hybrid key exchanges for TLS 1.3, which combine a classical algorithm with the post-quantum algorithm ML-KEM. According to the NCSC, these configurations are suitable for general use as well as for protecting government information classified OFFICIAL.

Which groups should you enable?

The guide recommends two families of settings for key exchange in TLS 1.3:

• Hybrid (classical and post-quantum): X25519MLKEM768, SecP256r1MLKEM768 and a variant pairing the P-384 curve with ML-KEM-1024. According to the NCSC, these are the most widely available options in common libraries.
• Pure post-quantum: MLKEM768. The NCSC notes that the corresponding RFC has not yet been published because of procedural delays, but that stable options already exist in several major libraries.

The UK agency does not pick one over the other. It recommends hybrid, which is the most widely available in common libraries today, but also configurations that prepare for a "purely" post-quantum future. This is a nuance compared with ANSSI, which insists on hybridization. The guide also asks organizations to keep classical key exchange enabled on Internet-facing services until an advanced stage of the migration, to stay compatible with older clients.

Why TLS 1.2 is becoming a bottleneck

The most concrete message concerns the protocol version. TLS 1.3 is the only version that supports post-quantum cryptography, and earlier versions "will not be upgraded", writes the author of the blog post, a principal technical director at the NCSC. TLS 1.2, when properly configured, is still considered robust against classical attacks, but it will only receive critical fixes. SSL must no longer be used, and TLS 1.0 and TLS 1.1 must be disabled, except for exceptions covered by a time-limited exit plan.

What about certificates?

On authentication, the NCSC remains cautious: post-quantum signatures are not yet standardized for TLS. In the meantime, it recommends keeping ECDSA P-256 or RSA 2048 with SHA-256. It also advises avoiding certificates whose validity period extends beyond the planned migration date, and identifying now the ones that will need to be replaced. Microsoft, for its part, is already urging companies to test post-quantum certificates.

What you can do right now

• Take inventory of servers still limited to TLS 1.2 and plan their move to TLS 1.3.
• Check whether your libraries (OpenSSL, web servers, load balancers) already offer X25519MLKEM768, and enable it alongside the classical groups.
• List certificates with long validity periods.

The UK timeline calls for priority migrations to be completed by 2031, and the NCSC believes that, for many organizations, protecting the confidentiality of data in transit falls into that category. Over the coming months, it plans to publish recommendations on post-quantum authentication in TLS and an update to its IPsec guide.