Post-Quantum TLS: Questions for Suppliers

On 15 October 2026, the NCSC published updated advice on post-quantum TLS. For a UK business using managed hosting, cloud applications and remote-access services, the immediate work is to identify the relevant connections and ask suppliers what they support on those paths.

“Post-quantum ready” is too broad to use as a completion criterion. Ask which protocol, key-agreement mechanism, endpoint and client combination the claim describes, and whether it is available and enabled for your service.

TLS 1.3 support is the starting point

The NCSC's updated TLS guidance recommends appropriate post-quantum configurations for TLS 1.3. Merely negotiating TLS 1.3 does not establish that a connection used post-quantum key agreement. The actual supported and negotiated groups matter.

RFC 10024 defines three hybrid mechanisms combining ML-KEM with traditional elliptic-curve key exchange: X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. Use the supplier's supported configuration and evidence, rather than pasting an algorithm string into a product that may interpret it differently.

For a service still using TLS 1.2, ask for its migration route. The NCSC continues to describe appropriately configured TLS 1.2 as providing strong protection against classical attacks, while directing organisations towards TLS 1.3 for PQC adoption. Avoid an unplanned compatibility change before you know which clients would be affected.

Follow the connection through the hosting stack

A browser may connect to a content-delivery network, which then opens a separate connection to an origin server. An application may also use TLS to reach databases, partner APIs or identity services. Evidence about the public edge does not automatically describe those additional connections.

Create an inventory of the important paths, the data they carry and their operators. Prioritise connections carrying information that needs to remain confidential for a long period, then include operationally critical services whose migration will take time to coordinate.

Ask the hosting supplier for a response against each relevant path:

Request dates for planned capabilities and distinguish them from features already deployed. Keep preview or pilot status visible in the response. A supplier roadmap is useful planning information, but it should not be recorded as current protection.

Separate key agreement from authentication

The updated NCSC guidance distinguishes post-quantum key exchange from post-quantum authentication and the wider public certificate ecosystem. Work on one does not mean the other has been completed.

Ask what the supplier means by a “quantum-safe certificate” or similar label. Does the claim describe the certificate signature, the key agreement used for a session, a private PKI experiment or a future product capability? Require enough detail to connect the statement to the actual service.

Keep ordinary certificate operation in the review: hostname validation, trust chains, renewal and deployment still need owners. A migration that introduces a new group but breaks reliable certificate renewal has not completed the operational job.

Ask VPN suppliers about their actual protocol

Do not apply a TLS configuration claim automatically to every VPN. Establish whether the product uses TLS, IPsec, WireGuard or another arrangement, and which part of the product the supplier is discussing. A TLS-protected management portal and the tunnel carrying business traffic may have different designs.

The NCSC's October announcement says further IPsec guidance and TLS authentication recommendations are planned. That is a reason to request protocol-specific evidence now and track the relevant guidance, rather than infer that this TLS update certifies a separate VPN protocol.

Pilot before changing the whole estate

Choose a representative service and client group. Agree success criteria for negotiation, normal application work, connection reliability and performance. Include older supported clients, proxies and monitoring tools that inspect or terminate TLS.

Record the existing configuration and a supported rollback route. Test the migration during a controlled window, then compare observed connections with the supplier's claim. Investigate fallback instead of counting every successful TLS connection as a post-quantum result.

Keep the resulting plan short: service path, current capability, owner, required change, target date and verification evidence. Review it when hosting, network or application suppliers change. That gives the business a practical migration programme tied to the connections it actually uses.

References

• NCSC, Post-quantum updates to our TLS guidance, published 15 October 2026. Accessed 17 October 2026.
• NCSC, Using TLS to protect data, updated 15 October 2026. Accessed 17 October 2026.
• IETF, RFC 10024: Post-Quantum Traditional Hybrid Key Agreement Mechanisms for TLS 1.3, August 2026. Accessed 17 October 2026.