The post-quantum TLS conversation has moved from “which algorithm?” to “which configuration is actually running?” On October 15, the UK National Cyber Security Centre published updated recommendations for configuring post-quantum cryptography in TLS. NCSC recommends both hybrid post-quantum/traditional and pure post-quantum choices, says TLS 1.3 is the only TLS version that will support PQC, and urges organizations protecting high-priority data in transit to begin moving now.
This is concrete guidance, but it is not a universal instruction to enable every available option everywhere. NCSC says its configurations are suitable for general use and UK government OFFICIAL information. Organizations still need to test their own clients, servers, middleboxes, libraries, performance limits, and policy obligations.
A configuration baseline needs an asset population
A recommended profile becomes actionable only when a team knows where TLS is used. That population includes public endpoints, internal services, APIs, service meshes, load balancers, VPNs, mail gateways, management planes, cloud services, and embedded systems. It also includes client-side dependencies that may be less visible than servers.
For each deployment, a useful cryptographic record should connect:
- the service, owner, environment, and business function;
- the TLS implementation, library, version, and termination point;
- supported and enabled protocol versions and key-agreement groups;
- certificate and authentication dependencies;
- the clients, partners, or devices expected to interoperate;
- observed negotiation results and the observation time;
- approved exceptions, compensating controls, and retirement dates; and
- test, change, rollback, and production-verification evidence.
Without that scope, a standard can produce a policy statement but not a controlled migration.
Support, enablement, and negotiation are different facts
A library may support a post-quantum group while an application does not enable it. A server may enable it while an older client negotiates a traditional alternative. A gateway may terminate the protected connection before traffic reaches the intended workload. Each statement is valid at a different layer.
Inventory should preserve those differences. Supplier documentation is evidence of capability. Configuration is evidence of intent. A handshake observation is evidence of behavior at a particular point in time. None alone proves end-to-end coverage.
This distinction also prevents misleading readiness metrics. Counting products marked “PQC capable” can conceal a large deployment and interoperability backlog. Counting successful test handshakes can conceal untested client populations. Good reporting states both the covered population and the unknowns.
Hybrid and pure PQC profiles need separate decisions
NCSC recommends hybrid choices that are already widely deployed in common libraries and also configurations that support a pure-PQC future. Those profiles should not be collapsed into one “quantum safe” inventory value.
Teams should record the exact group or mechanism, the reason it was selected, the interoperability boundary, and any standards or implementation maturity assumptions. A hybrid design retains a traditional component alongside a post-quantum one. A pure-PQC option removes that traditional key-agreement component, but NCSC notes that the final RFC for pure options is still pending despite stable implementations being available.
That standards state is not a reason for paralysis. It is a reason to make the approval, test scope, and reevaluation trigger explicit.
Key agreement is not the whole TLS migration
Protecting confidentiality through post-quantum key agreement does not automatically migrate server authentication, client authentication, certificate chains, signing services, or the systems that issue and rotate credentials. NCSC says it plans to add post-quantum authentication recommendations later.
Organizations should therefore report cryptographic roles separately. A connection can have post-quantum protection for key establishment while still depending on a classically vulnerable signature algorithm for identity. That may be an intentional, risk-based intermediate state, but it must not be reported as complete migration.
What organizations should do next
First, identify TLS 1.2 and older deployments, because NCSC is explicit that earlier versions will not receive PQC support. Treat the move to TLS 1.3 as a prerequisite project with its own compatibility testing.
Second, map TLS termination points and client populations. Prioritize flows that carry data with a long confidentiality lifetime or support high-value services.
Third, establish approved hybrid and pure-PQC test profiles. Record exact identifiers, implementation versions, success criteria, failure behavior, and rollback paths.
Fourth, observe real negotiation after deployment. Compare production evidence with the approved target and retain exceptions for clients that cannot yet comply.
Finally, keep authentication as a visible workstream. Do not allow a key-agreement milestone to close the certificate and signature migration prematurely.
How Vista Platform helps
Vista Platform is a self-hosted cryptographic system of record. Its operating loop—discovery, canonical inventory, evaluation, action, and proof—helps organizations connect TLS observations to implementations, assets, owners, policy decisions, remediation, exceptions, and verification evidence.
Vista Platform Core is free of charge and includes discovery, inventory, compliance and PQC assessment, and CBOM generation without asset, sensor, seat, or time caps. Vista tracks and governs post-quantum migration; it does not generate PQC keys or perform every migration. Selected-asset Active Scan is targeted, not indiscriminate network scanning. Vista is not a vulnerability scanner, and discovery gaps are not proof of absence.
Learn more about Vista’s post-quantum migration and cryptographic inventory approach.
Where uncertainty remains
NCSC’s recommendations will evolve as standards finalize and authentication guidance arrives. Library support and performance will also vary across environments. The durable control is not one fixed cipher list; it is the ability to identify affected systems, approve a target, test dependencies, observe production behavior, and update the record when the target changes.
Source
- Post-quantum updates to our TLS guidance, UK National Cyber Security Centre, October 15, 2026.