NCSC's new TLS guidance adds post-quantum profiles but prints no year; the blog beside it prints one, 2031

No year in the guidance, one in the blog, and the nearest NCSC milestone 443 to 808 days away

The NCSC published two pages on 15 October 2026. The first is its guidance, Using TLS to protect data, which now reads as version 1.2. The second is a blog by NCSC authors, Post-quantum updates to our TLS guidance. Counting each directive in the guidance once, version 1.2 holds 48 distinct recommendations (derived). None carries a date. 32 name a setting a scanner could check, such as a protocol version, a group name, a key size or a port. 16 name neither a date nor a checkable setting: they say to plan, consider, keep up to date, test regularly, or wait until "much later" (derived). That is a judgement count made for this briefing, not an NCSC classification. The method is set out in the second section below, and every row is listed in the calculation output so that it can be disputed.

The only year printed across the two pages is 2031, and it is in the blog, not the guidance. The NCSC authors write that the NCSC's published timelines recommend high priority migration activities be carried out by 2031, and that for many organisations protecting data in transit will be one of them. The timelines page itself, published on 20 March 2025, gives three years: 2028, 2031 and 2035. The nearest, 2028, is 443 to 808 days from today, 15 October 2026 (derived), depending on whether "by 2028" is read as the first or the last day of that year.

What that does not establish matters as much. It does not show the guidance is deficient: a configuration page can reasonably leave dates to the timelines page, and it links to that page twice. It does not say which recommendations are mandatory. The page does not define must and should, and none of its seven sentences containing "must" concerns post-quantum cryptography (derived). It does not say whom the guidance binds, whether Cyber Essentials, the Government Cyber Security Standard, GovAssure or a NIS regulator expects it, what inventory an organisation needs before it can follow it, whether any UK government service meets it, or whether hybrid key exchange is on by default where an organisation actually sits. The sections below take each in turn.

How this was read. Both NCSC pages and their PDF versions were fetched on 15 October 2026 and read in full. The previous version, 1.1, was read from an Internet Archive capture taken at 02:27 UTC on 7 October 2026, because the live page keeps no history and gives no statement of changes. The standards were read from the RFC Editor, IANA, the IETF Datatracker and NIST. What libraries and browsers switch on by default was read from public source code where it exists (OpenSSL, BoringSSL, Go release notes) and otherwise from each maker's own documentation, which is a maker describing its own product. One interest, stated once: the NCSC is a UK government body writing guidance, and it sells nothing here. Vendors that sell TLS or post-quantum products are used only where named and flagged, and only once, for a measurement of the top million websites.

What changed from version 1.1 to version 1.2

The page has no history section and no statement of changes, so the comparison below was made by reading the 7 October capture (version 1.1) against the live page (version 1.2), sentence by sentence. The version line itself moved. The capture reads Published 21 July 2021, Reviewed 10 December 2025, Version 1.1. The live page reads Published 15 October 2026, Reviewed 15 October 2026, Version 1.2. The NCSC does not say why the Published date changed from 2021 to 2026.

Version 1.1 (Internet Archive capture, 7 October 2026) against version 1.2 (live page and PDF, 15 October 2026). Counts are derived from the saved page text in calc.py.

Item	Version 1.1	Version 1.2
Version line	Published 21 July 2021, Reviewed 10 December 2025, Version 1.1	Published 15 October 2026, Reviewed 15 October 2026, Version 1.2
Headline list	"Summary": 7 bullets	"Key recommendations": 6 bullets, none with a year
TLS 1.3 profiles	2 (key exchange ECDHE P-256; ECDSA or RSA signature)	3: hybrid, pure post-quantum, traditional; each with an ECDSA or RSA signature choice
Group names printed	None; "ECDHE using P-256 curve"	7: X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024, MLKEM768, MLKEM1024, secp256r1, secp384r1
Symmetric cipher suite	TLS_AES_128_GCM_SHA256	Unchanged: "The recommended symmetric cipher suites are unchanged"
Authentication	ECDSA P-256 or RSA 2048	Unchanged in every profile; post-quantum authentication left until standards are final
TLS 1.2	"not expected to receive any new features"	No new features apart from critical security updates, citing RFC 9851
Body length	2,583 words	2,986 words (+403), derived
Mentions of quantum	8	23, derived
Sentences with "must"	7	7, none about post-quantum, derived
Sentence dropped	"configuring TLS can be difficult, and if configured incorrectly, it can lead to a false sense of security"	Absent
The promise	NCSC "will update this guidance to include TLS PQC profile(s)" once RFCs mature and support is broad enough	Delivered, after RFC 10024 (August 2026)

How the count was made. The headline lists as printed give 7 bullets in version 1.1 (Summary) and 6 in version 1.2 (Key recommendations), and none of the six carries a year. A fuller count reads each page top to bottom and writes one row for every distinct directive: a sentence or list item telling the reader to do, use, enable, disable, avoid, plan, consider or check something. A directive repeated later, such as use the recommended profiles in the web and mail sections or the Key recommendations repeating the body, counts once. List items that name different settings, such as the four insecure features, count separately. Each row then goes into one of four classes: it carries a date or a year; it names a setting an outside party could check (a version, a named group or suite, a key size, a port, a header); it leaves the date to the reader ("time-bounded", "before your expected migration date"); or it says plan, consider, keep up to date, regularly or consult. That gives 42 rows for version 1.1 and 48 for version 1.2 (derived), of which 8 are new, 2 were dropped and 40 carry over. The 8 new rows are the hybrid recommendation, the client key shares, preferring TLS 1.3, enabling at least one post-quantum group "as soon as your implementation supports them", keeping traditional key exchange for compatibility, combining the two moves, not disabling traditional cryptography until "much later", and keeping ECDSA and RSA until post-quantum authentication standards exist. The 2 dropped are the advice to allow for services removing TLS 1.2 early, and the line suggesting the TLS 1.2 compatibility profile for a wide variety of clients. A mechanical cross-check, counting sentences with must, should, shall or recommend, gives 36 and 34. The classification is a judgement; the claim that nothing carries a date does not depend on it.

Two changes deserve a close read. The old page made the promise in the last row of the table, and version 1.2 fulfils it, 45 to 75 days after RFC 10024's August 2026 date (derived). The second is a deletion. The old About TLS section warned that badly configured TLS "can lead to a false sense of security". That sentence is gone from version 1.2, which instead says in its key recommendations that only TLS 1.3 protects against quantum attacks "when configured correctly". Nothing in the record says the deletion was deliberate. It is noted because the phrase described the gap between a label and a control, and the new page has no replacement for it.

The blog adds three things the guidance does not. It says what to do: its strapline is "Now is time to migrate", and it says organisations "should be aiming to make this move now". It ties TLS to the 2031 milestone. And it makes two undated promises: updates to the IPsec guidance and post-quantum authentication recommendations for TLS, both "in the coming months". It says the configurations suit general use and protecting government OFFICIAL information. It is written for cyber security professionals, large organisations and the public sector; the guidance adds small and medium sized organisations to that list.

What the guidance leans on, and where each standard stood on 15 October 2026

The profile rests on a stack of standards of different ages and different status. Reading each at source gives this.

Standards behind the new profiles, as read from NIST, the RFC Editor, the IETF Datatracker and the IANA registries on 15 October 2026.

Standard	Status as read	Why it matters here
FIPS 203 (ML-KEM)	Final 13 August 2024. NIST planning note of 17 November 2025: an issue "will be corrected in a future update/revision"	The algorithm inside every post-quantum group. Final, and still being corrected.
FIPS 204 (ML-DSA), FIPS 205 (SLH-DSA)	Final 13 August 2024. FIPS 204 note of 31 July 2026 lists "several minor issues" for a future revision	Signature standards. The profiles do not use them: authentication stays ECDSA or RSA.
RFC 10024	Standards Track, August 2026. Defines X25519MLKEM768, SecP256r1MLKEM768 and SecP384r1MLKEM1024. IANA marks only the first Recommended: Y	The basis for the hybrid profile.
RFC 9954 and RFC 9794	RFC 9954 (Informational, July 2026): the hybrid key exchange framework. RFC 9794 (June 2025): terminology, co-written by the NCSC	Define what "hybrid" means in TLS.
ML-KEM for TLS 1.3, draft-ietf-tls-mlkem-11	Active draft in the RFC Editor queue. Datatracker intended status: Informational. IANA marks MLKEM768 and MLKEM1024 Recommended: N	The basis for the pure post-quantum profile.
RFC 9851	Standards Track, July 2026: TLS 1.2 feature freeze. "PQC for TLS 1.2 will not be specified"	Why the guidance says TLS 1.3 only.
Post-quantum authentication in TLS	Not final. IANA lists mldsa44, mldsa65 and mldsa87 as Recommended: N, pointing at a draft	Why the NCSC says to keep ECDSA and RSA for now.

Two readings follow. The blog calls the final RFC for pure post-quantum options "equivalent to a standard". The Datatracker lists its intended status as Informational, not Standards Track, so it will not be a Standards Track RFC when it publishes. And the NCSC's hybrid profile names SecP256r1MLKEM768 as an alternative to X25519MLKEM768. IANA's registry marks the first N, which under RFC 9847 means the IETF has made no statement about its suitability, not that it is flawed. The NCSC says all three RFC 10024 groups suit personal, enterprise and OFFICIAL information, so this is a difference in who is recommending, not a contradiction.

Two printed names do not match the registries. The list of RFC 10024 groups prints one as SepP384r1MLKEM1024; the registered name, and the spelling in the page's own OpenSSL string, is SecP384r1MLKEM1024. The TLS 1.2 profile prints TLS_ECDHA_RSA_WITH_AES_128_GCM_SHA256; the registered name is TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256. Both appear in the HTML and in the PDF. The page also contains the sentence "You must not be use them." These are small slips, and in a page whose readers copy names into configuration files a wrong name matters more than it would elsewhere: check any printed name against the IANA registry before using it. The legacy profile, which the NCSC confines to cases where TLS 1.0 and 1.1 cannot be disabled, includes a suite that IANA marks D, discouraged.

The NCSC dates beside the American ones

Milestones as printed by each source, with days from 15 October 2026 to the first and last day of the year (derived). The NSA document was read from an Internet Archive copy of the NSA-hosted PDF, version 1.0 of September 2022; a later revision may differ and was not checked.

Source and what it covers	Milestone as printed	Days from today (derived)
NCSC timelines page, 20 March 2025	By 2028: discovery done, initial plan	443 to 808
NCSC timelines page	By 2031: highest-priority migration done	1,539 to 1,903
NCSC timelines page	By 2035: migration complete	3,000 to 3,364
NSA CNSA 2.0, web browsers and servers, cloud services	Support and prefer by 2025; exclusively use by 2033	2025 has passed; 2,270 to 2,634
NSA CNSA 2.0, traditional networking equipment	Support and prefer by 2026; exclusively use by 2030	77 days to the end of 2026; 1,174 to 1,538 for 2030
NIST IR 8547, initial public draft, 12 November 2024	112-bit strength deprecated after 2030; all quantum-vulnerable algorithms disallowed after 2035	Draft only; no final version found on the NIST page

Who each binds differs. The NSA dates are for National Security Systems. NIST IR 8547 is a draft for federal agencies. CISA's product categories list, published 23 January 2026, says that, in the categories it calls widely available, organisations should acquire only post-quantum capable products. It answers a US executive order and is aimed at federal agencies. Web software, meaning browsers and web servers, is on that list. Networking hardware, including proxy servers, routers and firewalls, is in the table of categories still transitioning. The NCSC timelines bind nobody by law, and they are written "primarily" for large organisations, operators of critical national infrastructure and companies with bespoke IT.

The parameters differ too. The NSA advisory says to use Level V parameters, which is ML-KEM-1024, FIPS 203 security category 5, and AES with 256-bit keys. The NCSC's recommended profiles use ML-KEM-768, category 3, and AES-128-GCM, with the symmetric suite "unchanged". ML-KEM-1024 appears in the NCSC page only in SecP384r1MLKEM1024 and MLKEM1024, which it calls acceptable but does not put in a recommended profile. Neither approach is wrong for its audience. The point is that an organisation that has to satisfy both cannot do it with one printed profile.

Seven group names printed, one of the five post-quantum ones on by default almost everywhere

The guidance prints seven group names: three hybrid, two pure ML-KEM and two traditional (derived). Version 1.1 printed none. The question for an administrator is which of the five post-quantum names the software already offers without being told. That was checked product by product, from source code where it is public and from the maker's own documentation otherwise.

Post-quantum group names on by default, by product, among the five the guidance prints. Sources: OpenSSL and BoringSSL source on GitHub, Go release notes 1.24, 1.26 and 1.27, OpenJDK JEP 527, Mozilla's administrator reference, Apple Platform Security, Microsoft Learn and its Tech Community FAQ. All read on 15 October 2026.

Product (what was read)	On by default	Supported, off by default
OpenSSL 4.0 (source)	X25519MLKEM768, SecP256r1MLKEM768	SecP384r1MLKEM1024, MLKEM768, MLKEM1024
OpenSSL 3.5 LTS (source)	X25519MLKEM768	The other four
BoringSSL, Chrome's library (source)	X25519MLKEM768	MLKEM1024
Go 1.27 (release notes)	X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024	MLKEM1024 (opt-in)
Java 27, released 15 September 2026 (JEP 527)	X25519MLKEM768	SecP256r1MLKEM768, SecP384r1MLKEM1024
Firefox (Mozilla documentation)	X25519MLKEM768	ML-KEM-1024, by policy since Firefox 154
Apple iOS and iPadOS 26 (Apple documentation)	X25519MLKEM768	Not stated
Windows Schannel (Microsoft documentation)	None	X25519MLKEM768, SecP256r1MLKEM768, SecP384r1MLKEM1024

Counted across seven products, with OpenSSL taken once at 4.0 (derived): X25519MLKEM768 is on by default in six, everything but Windows. SecP256r1MLKEM768 is on in two. SecP384r1MLKEM1024 is on in one, Go. MLKEM768 and MLKEM1024, the names in the guidance's pure profile, are on in none. So three of the five names are on by default somewhere, and two are on nowhere that was verified. The blog says stable pure options "exist in a number of major libraries". That is true of OpenSSL, which implements all five names, and partly of Go, which implements four. It was not found true of any library that turns a pure group on without being told.

The defaults stop in four places. First, Windows: Microsoft's FAQ answers whether hybrid TLS 1.3 is enabled today with "No not by default; you must enable it", and answers whether enabling TLS 1.3 gives hybrid support with "No". Second, OpenSSL: the post-quantum groups arrive in 3.5, according to OpenSSL's documentation, and OpenSSL's release strategy page lists 3.0 as no longer supported, 3.4 supported until 22 October 2026, and 3.5, a long-term support release, until 8 April 2030. The NCSC's example OpenSSL string carries no "?" prefix, and OpenSSL's documentation says unknown groups in a list otherwise cause an error, so on that reading the string fails on an older build rather than falling back. Third, Java: the hybrid group arrives in Java 27; whether earlier Java releases receive it was not checked. Fourth, middleboxes: OpenSSL's documentation warns that the larger ClientHello can stop fitting in one TCP segment and that firewall software may then disrupt the handshake.

From outside, the picture on one day looks better than the table suggests. On 15 October 2026 at 12:13 BST, one TLS 1.3 handshake from OpenSSL 3.6.4 offering only X25519MLKEM768 negotiated that group at www.ncsc.gov.uk, www.gov.uk and ico.org.uk, three of three (derived). A client offering only secp256r1 also connected to each. That is one client on one day at the edge of each service. It does not test the NCSC profile, older TLS versions or the origin servers. It also shows a difference from the printed profile: the guidance prints one TLS 1.3 suite, TLS_AES_128_GCM_SHA256, and the NCSC's own site and the ICO's chose TLS_AES_256_GCM_SHA384 when the client offered OpenSSL's default list. The guidance does not say whether other suites are acceptable.

A wider measurement points the same way. F5 Labs, part of F5, which sells TLS and application delivery products, scanned the top million domains and reported on 22 September 2026 that 54 per cent support post-quantum key exchange, falling to 22 per cent when Cloudflare-hosted domains are removed. That is a vendor's own scan, not checked here, and it is not a UK figure. It is a pointer to the same dependency: where hybrid exchange is on, it is largely because an edge provider switched it on.

Said and not said

What the NCSC pages say, quoted or closely paraphrased, against what they do not say. Read from the guidance (version 1.2), the blog and the timelines page on 15 October 2026.

Said	Not said
Hybrid schemes are recommended "as an interim measure"	When the interim ends. Traditional support cannot be disabled until "much later"
Organisations "should be aiming to make this move now" (blog)	A deadline for the TLS move. 2031 is for high priority activities, which for "many organisations" include data in transit
Only TLS 1.3 protects against quantum attacks "when configured correctly"	How to tell it is configured correctly. No test is described
The configurations suit general use and OFFICIAL information	Anything about information above OFFICIAL
Pure post-quantum options are recommended; stable ones "exist in a number of major libraries"	Which libraries, and that none of the seven products read turns them on by default
Post-quantum authentication recommendations are coming "in the coming months"; so is an IPsec update	A date or a draft for either
Use "cryptographically agile deployments"	A definition or a test in this guidance. The timelines page defines it
Test regularly; external attack surface tools can help	How to confirm a post-quantum group was negotiated. The timelines page says to check systems are not falling back
Government systems need a "time-bounded migration plan" for deprecated TLS	The time bound
Seven sentences say "must" and 24 say "should" (derived)	What either word means, or who enforces it

Six labels, and what each one hides

A label is not a control. The NCSC's own pages are more careful than the market around them: the guidance never uses "quantum-safe" or "quantum-resistant", and neither NCSC page uses "harvest now, decrypt later" (derived counts). The labels still arrive, from vendors and from procurement documents.

Labels commonly attached to this guidance, where they appear in the record, and what each does not tell you.

Label	Where it appears	What it hides
"Post-quantum safe", "quantum-safe", "quantum-resistant"	Not in the guidance. The blog says "quantum resilience". F5 Labs' summary says headline statistics suggest over 54 per cent of top sites are "quantum-safe", then qualifies it	The profile changes key exchange only. Authentication is ECDSA or RSA in every profile, and the NCSC says a system "will not provide quantum-secure authentication" until PKI migration is complete
"Hybrid"	RFC 9794 and RFC 9954; all three RFC 10024 groups	Defined as secure while at least one component stays secure. It does not say which group, or that it is on. Pure ML-KEM is not hybrid
"Harvest now, decrypt later"	Not on either NCSC page. OpenJDK's JEP 527 uses it and Chromium's security update says "store now, decrypt later"	It concerns recorded traffic, so only key exchange. It does not tell you which data stays sensitive for years. The guidance never asks
"Crypto agility"	One sentence in the guidance; defined on the timelines page as being able to readily support alternative algorithm suites	No test and no owner. A vendor can claim it without showing a group can change without a rebuild
"TLS 1.3 compliant"	The guidance says only TLS 1.3 protects "when configured correctly". Microsoft's FAQ says enabling TLS 1.3 gives "classic" algorithms by default	The version is necessary, not sufficient. A scan that says TLS 1.3 says nothing about the group
"Suitable for OFFICIAL"	The blog and the guidance	A suitability statement for one classification band. It is not a compliance test and it says nothing about anything above OFFICIAL

The UK picture: whom the guidance binds, and where each instrument stops

Start with the guidance's own words about itself. It is "aimed at system administrators who are responsible for configuring servers or clients within their estate". Its Written for line lists four audiences, including small and medium sized organisations. The blog drops that audience, and the timelines page says that for organisations using mainly commodity IT, migration "should happen seamlessly, as services are updated by their vendors", with custom or specialised software on the same timetable as larger organisations. On force, the guidance mixes "must" for a handful of items (SSL, insecure features, TLS 1.0 and 1.1, a public CA for unknown clients, mail certificate chains) with "should" for nearly everything else, and defines neither. None of the post-quantum items uses "must": they use "should", "recommends" or a plain imperative.

UK instruments read on 15 October 2026: what each says about TLS or post-quantum cryptography, and where it stops. Term counts are derived from the saved text in calc.py.

Instrument	What it says, as read	Where it stops
Cyber Essentials, Requirements for IT Infrastructure v3.3 (April 2026)	No mention of TLS, quantum, cipher, HTTPS or SSL (0 each, derived). "Cryptography" appears twice, in a definition of passkeys	A certificate says nothing about the TLS version or group in use
NCSC Cyber Assessment Framework v4.0, outcome B3.b data in transit	Achieved needs all data links identified and protected, with "justified confidence in the robustness" of the protection. Links to the TLS guidance. No mention of quantum on the page	Outcome-based: no group, no date. It also says to prefer "well-tested cryptographic suites in common use", which on one reading favours the default group over the others
Government Cyber Security Standard and GovAssure (security.gov.uk, updated 5 October and 24 September 2026)	"Shall" is mandatory and "should" advisory. Organisations shall meet the CAF outcomes under the Government CAF Profile for critical systems and shall assure them through GovAssure. No mention of TLS or post-quantum on either page	The Government CAF Profiles are behind a sign-in and were not read. The pages do not name the NCSC TLS guidance
Government Cyber Action Plan (DSIT, updated 20 March 2026)	Lists "a roadmap for transitioning to post-quantum cryptography" among the Government Cyber Unit's priority next steps	A promised roadmap. None was found on the pages read
NIS Regulations 2018, regulation 10	Operators of essential services must take appropriate and proportionate measures, "having regard to the state of the art", and "must have regard to any relevant guidance issued by the relevant competent authority"	The NCSC is not named there as the competent authority. Whether any competent authority has adopted the new guidance was not found. The Cyber Security and Resilience Bill is not an Act; its Lords report stage is listed for 26 October 2026
UK GDPR Article 32 and the ICO's encryption guidance	Article 32 asks for measures appropriate to the risk, having regard to the state of the art, including encryption as appropriate. The ICO's data transfer page endorses TLS 1.3 and 1.2 and cites the NCSC guidance; none of three ICO pages mentions quantum (0, derived)	No date and no group. "State of the art" moves, and the ICO has not said when hybrid key exchange becomes it

What inventory does the guidance assume? The timelines page says discovery "is not intended to be a formal asset register" but expects a record of key services, of the data held including "its expected lifetime and its value to an adversary", of how data is protected in transit, of managed service providers, and of version and patch levels. The TLS guidance assumes more specific knowledge: for each endpoint, which TLS versions and groups the implementation supports and offers; whether a CDN or provider lets the data owner choose a policy; which certificates exist and when they run out; which mail connections fall back to plaintext. It gives no method for finding any of that. Its testing section recommends external attack surface tools and penetration testing and does not mention checking that a post-quantum group was negotiated, although the timelines page tells readers to check that systems are "actually using them, and not falling back to traditional cryptography" and to be able to quantify how many clients use post-quantum cryptography.

The authentication half runs on a different clock. Chrome's team wrote in February 2026 that it has "no immediate plan" to add traditional X.509 certificates containing post-quantum cryptography to its root store and is developing Merkle Tree Certificates instead, a route covered in an earlier briefing on Cloudflare's post-quantum certificate authority. The device half is where an inventory is hardest to build, and the briefing on Forescout's medical device figure makes the relevant point for SSH: a version number tests what a device ships with, not whether it can be updated.

Does any UK government service meet the guidance? The record does not say. The NCSC pages name no service and report no measurement. The one-handshake probe above shows three public UK sites negotiating the hybrid group at the edge, which is evidence that whatever terminates TLS for those sites offers the hybrid group, and nothing more.

What to do, in order

The question that exposes the gap

The NCSC has done what its old page said it would: it published a profile once the RFC and the libraries were ready. It has not said by when, for whom, or how anyone would know. Without a date, a test or an owner, the guidance converts into whatever each supplier's defaults happen to be, and those defaults are on in browsers, on in some libraries, and off in Windows. So the question is this. If an auditor asked tomorrow which of your public endpoints negotiate a post-quantum group, would the answer come from a measurement you took this month, or from a supplier's statement?

Key facts