NCSC post-quantum TLS guidance puts migration on the agenda

Britain’s National Cyber Security Centre (NCSC) now recommends post-quantum configurations for TLS, the protocol used to protect data in transit, and says organisations should start migrating. For businesses still using TLS 1.2 or earlier, the immediate implication is unambiguous: move to TLS 1.3, because older versions will not receive post-quantum support.

What happened

The NCSC has updated its TLS guidance following the Internet Engineering Task Force’s publication of RFC 10024, which specifies hybrid post-quantum and traditional key-agreement mechanisms for TLS 1.3. The agency says its recommended configurations are suitable for general use and for protecting government OFFICIAL information.

The recommendations cover two approaches. Hybrid configurations combine post-quantum and traditional cryptography; pure post-quantum configurations use the newer approach without that combination. The NCSC endorses both, rather than asking organisations to wait until one becomes the sole preferred option.

Their readiness is not identical. According to the agency, hybrid choices are the most widely deployed in commonly used libraries. Pure post-quantum options are stable and available in several major libraries, but their final RFC has yet to be published. The NCSC attributes that delay to procedure, not to a lack of usable implementations.

For buyers, this creates a distinction worth preserving in supplier discussions: published standard, available implementation and recommended configuration are separate things. Hybrid key agreement has the newly published RFC behind it. Pure options have the NCSC’s recommendation and available library support, while final publication remains outstanding. Calling both simply “post-quantum ready” would conceal information needed for a purchasing decision.

The background

Post-quantum cryptography is intended to provide resilience against quantum-computing threats. In this announcement, the practical focus is confidentiality while information moves between systems. The guidance is not a claim that every part of an organisation’s security architecture can now be made quantum-resilient through a TLS setting.

TLS 1.3 is the prerequisite, but adopting that version and selecting a post-quantum configuration are distinct steps. A supplier’s assurance that it supports TLS 1.3 therefore answers the version question, not necessarily the post-quantum one. The NCSC also points to the broader security benefits of TLS 1.3 as a reason to leave older versions behind.

The agency’s existing migration timetable recommends completing high-priority migration activities by 2031. It says protecting data in transit will fall into that category for many organisations. This is not a statement that every TLS deployment has an identical deadline; priority depends on the migration activity. Nor does the outer date contradict its advice to begin now.

The scope matters commercially. Quantum resilience for a connection does not replace work on other weaknesses, such as the credential and remote-access risks illustrated by the BeyondTrust flaw. These are different security problems. Treating a cryptographic upgrade as a general security certificate would give it a promotion it has not earned.

The announcement supplies technical recommendations, rather than announcing a new statutory requirement. UK businesses should distinguish this migration advice from the separate debate over the UK cyber bill. US companies can use the configurations as technical guidance, but this NCSC publication does not itself create a US compliance obligation.

What people are saying

The NCSC’s position is that standardised configurations and implementations in well-studied libraries provide enough support to proceed. Its argument is about deployment maturity: organisations no longer need to treat post-quantum TLS solely as a research question. The announcement does not offer a forecast for when a threatening quantum computer will arrive.

Its endorsement of hybrid and pure options also separates present practicality from longer-term direction. Hybrid configurations have the broader deployment base described in the announcement. Supporting pure configurations preserves a route towards a future without the traditional component. The agency is allowing both paths, not declaring that the more widely deployed approach must become permanent.

The treatment of the unfinished pure-PQC RFC is particularly revealing. The NCSC is prepared to recommend stable implementations before that final procedural step is complete. Organisations whose internal purchasing rules require a published final standard may still face an approval question, even where the agency considers an option suitable for use. Technical confidence and procurement permission need not arrive together.

There are no customer reactions, supplier commitments or deployment benchmarks in the source announcement. It consequently provides no basis for estimating implementation costs, performance effects or the effort required by a particular business. Library availability is evidence that implementation is possible; it is not evidence that a company’s existing products already expose the required choices.

What happens next

For an organisation on TLS 1.2 or an earlier version, the first dependency is protocol migration. The NCSC explicitly rules out waiting for those versions to acquire post-quantum support. Any replacement or renewal decision involving them therefore has a concrete technical requirement to resolve, rather than a speculative feature to place on a distant roadmap.

For organisations already using TLS 1.3, the next question is which recommended configurations their products and services actually support. A useful supplier response would distinguish hybrid from pure options and identify the implementation available today. A general promise of future quantum resilience would not establish whether the NCSC’s current recommendations can be deployed.

The funding question is one of sequencing. Security teams must accommodate cryptographic migration alongside existing operational demands, a tension also relevant to cyber-security budget pressure in US state organisations. The NCSC’s timetable gives high-priority work a planning horizon; its recommendation to move now argues against treating 2031 as the year to begin procurement.

Further guidance will broaden the technical picture. The NCSC plans to update its IPsec advice in the coming months as the relevant RFCs are finalised. It also plans to add post-quantum authentication recommendations for TLS. That forthcoming authentication work is a reason to describe the current update precisely, rather than present it as the last word on post-quantum TLS.

Those changes leave buyers with an evolving specification. Contract and product reviews should therefore distinguish support for today’s recommended TLS configurations from support promised for later protocol developments. The announcement establishes a usable starting point; it does not establish that every supplier’s migration roadmap is complete.