1. Executive summary
The NCSC has published updated TLS guidance that adds recommended configurations for post-quantum cryptography (PQC), following the IETF's publication of RFC 10024 for post-quantum traditional hybrid key agreement in TLS 1.3. The guidance recommends both hybrid post-quantum/traditional and pure post-quantum cipher choices, and states that TLS 1.3 is the only version that supports PQC, so organisations still running TLS 1.2 or earlier must migrate to 1.3. No CVSS score, severity rating or CISA KEV exploitation state is available for this item because it is a guidance publication, not a vulnerability; no CVE is referenced in the source material. The bottom-line risk to EMEA financial services is not an active exploit but a migration deadline: the NCSC places high-priority PQC migration activities at 2031, and data in transit confidentiality falls into that high-priority category for most institutions. The operational exposure sits in certificate and PKI dependencies, which Microsoft and Tenable both describe as the part of the estate that organisations have inventoried least.
2. Regulatory framing
| Article | Trigger (the fact in this item) | Practical impact |
|---|---|---|
| DORA Art. 24: digital operational resilience testing — general requirements | The NCSC guidance recommends migrating TLS configurations to PQC, and Microsoft's related guidance states that organisations should create non-production test environments and test interoperability before post-quantum authentication is required at scale. | PQC interoperability testing of TLS and certificate chains is a resilience-testing activity. Clients should fold PQC TLS and PKI interoperability testing into their existing resilience testing programme rather than run it as a separate project. |
| DORA Art. 28: ICT third-party risk — general principles | Microsoft states that certificates, trust anchors, PKI services, applications, devices and hardware security modules may all be affected by new algorithms and larger certificate chains, and that organisations should assess vendor roadmaps. | Clients must obtain PQC roadmaps from certificate authorities, HSM vendors, TLS library maintainers and managed PKI providers, and record them in third-party risk registers. |
| NIS2 Art. 21(2)(d): supply chain security measures | The same dependency on third-party certificate authorities, PKI services and hardware security modules, where the client cannot migrate without vendor support. | Supply chain security measures should cover the cryptographic agility of suppliers, not only their incident posture. Contractual and roadmap evidence should be requested. |
3. Technical analysis & attack chain
This is a guidance publication, not an incident. There is no observed attack chain, no exploited component and no CVE. What follows is the migration path the sources describe, and the technical dependencies that determine whether a client can execute it.
- The IETF published RFC 10024, Post-quantum traditional hybrid key agreement mechanisms for TLS 1.3. The NCSC guidance is built on that standard.
- The NCSC recommends both hybrid post-quantum/traditional and pure post-quantum cipher choices. Hybrid choices are the most widely deployed in commonly used libraries; the guidance also recommends configurations that support a pure PQC future.
- The final RFC for pure PQC options has not yet been published. The NCSC attributes this to procedural delays. Stable pure PQC options already exist in a number of major libraries and are available for use.
- TLS 1.3 is the only TLS version that supports PQC. Earlier versions will not be upgraded. Organisations on TLS 1.2 or older must move to TLS 1.3 to gain any quantum resilience.
- The NCSC's published timelines place high-priority migration activities at 2031. Confidentiality of data in transit falls into that high-priority category for many organisations, and the NCSC states the move should be made now.
- The NCSC plans to update its IPsec guidance as those RFCs are finalised, and to add post-quantum authentication recommendations for TLS in the coming months.
The migration is not a single technology upgrade. Microsoft's analysis, published a week before the NCSC guidance, sets out why authentication is the harder half of the problem. Certificates and private keys must be issued, distributed, stored, validated, renewed and managed across environments and vendors, so an algorithm change reaches into operational process and interoperability, not only cryptographic correctness. Enterprise estates contain internally managed PKI deployments, embedded devices, operational technology, security appliances, custom applications, third-party services and hardware-backed trust systems, some with long deployment lifecycles and fixed cryptographic assumptions that only surface once testing starts. Microsoft's stated goal for testing is to identify interoperability, compatibility, performance and operational challenges before post-quantum authentication is deployed at scale, and it recommends inventorying certificate dependencies, assessing vendor roadmaps, identifying long-lived infrastructure and building non-production test environments. Microsoft operates a PQC TLS Pilot Program for eligible certificate authorities to evaluate interoperability and operational readiness in controlled environments.
Tenable's analysis covers the confidentiality side and the reason the deadline is not 2031. A cryptographically relevant quantum computer capable of breaking current public-key algorithms is described as still several years away, but the harvest now, decrypt later tactic means adversaries are already collecting data encrypted under RSA and ECC for future decryption. Shor's Algorithm, published in 1994, solves integer factorisation and the discrete logarithm problem in polynomial time on a sufficiently stable quantum computer, which breaks RSA, Diffie-Hellman and ECC. Symmetric encryption fares better: Grover's Algorithm halves effective key strength, so AES-128 provides roughly 64 bits of security against a quantum attacker while AES-256 remains secure. Tenable states that organisations cannot migrate what they cannot see, and that a cryptographic inventory is the prerequisite for a phased migration. Tenable also cites Executive Order 14412, "Securing the Nation Against Advanced Cryptographic Attacks," as mandating PQC readiness for US executive-branch federal agencies. That is a US federal obligation and does not bind EMEA financial services directly; it is relevant only as a signal of vendor and standards direction.
Two caveats on sourcing. The NCSC guidance is the primary source and is authoritative for the recommended configurations and the 2031 timeline. The Microsoft and Tenable pieces are vendor analyses that corroborate the direction of travel and the certificate-inventory problem; neither is a regulator, and neither states a binding deadline for EMEA institutions. The specific cipher suite names and configuration parameters are in the NCSC guidance itself, which was not available in full to this advisory; clients should read the published guidance for the exact configuration strings rather than rely on this summary.
4. Mitigation & containment
There is no containment action for this item. It is a planned migration, and the work is inventory, testing and remediation.
P1 within 24h
- Establish whether any externally facing or data-in-transit service still negotiates TLS 1.2 or below. The NCSC states TLS 1.3 is the only version that supports PQC and that earlier versions will not be upgraded, so a TLS 1.2 endpoint is a hard blocker on any PQC path. Enumerate listeners and record the minimum and maximum protocol version each one accepts.
- Pull the NCSC guidance at https://www.ncsc.gov.uk/blogs/post-quantum-updates-to-our-tls-guidance and extract the recommended hybrid and pure PQC configuration strings. Do not implement from secondary summaries.
P2 within 72h
- Start the cryptographic inventory. Tenable's position is that organisations cannot migrate what they cannot see, and Microsoft's is that few organisations have a complete inventory of every system that issues, validates, stores, distributes or depends on certificates. Cover TLS terminators, internal PKI and certificate authorities, HSMs, load balancers, service meshes, embedded and OT devices, security appliances and custom applications.
- For each asset, record the TLS library and version, the certificate chain length, the key algorithm and size, the issuing CA, and the renewal process owner. Microsoft notes that post-quantum algorithms produce larger certificate chains, so chain length is a sizing input, not a footnote.
- Request PQC roadmaps in writing from each certificate authority, HSM vendor, TLS library maintainer and managed PKI provider. Record the responses against DORA Art. 28 third-party risk and NIS2 Art. 21(2)(d) supply chain measures.
P3 within 7 days
- Stand up a non-production test environment and run hybrid post-quantum/traditional TLS 1.3 between representative clients and servers. Microsoft's stated purpose for this testing is to surface interoperability, compatibility, performance and operational challenges before deployment at scale. Test certificate issuance, validation, storage and renewal end to end, not just the handshake.
- Identify long-lived infrastructure that cannot be re-keyed or re-flashed on a short cycle. Microsoft flags these as the assets whose fixed cryptographic assumptions only become visible during testing, and they set the realistic end date for the programme.
- If you operate a certificate authority, assess eligibility for Microsoft's PQC TLS Pilot Program for controlled-environment interoperability testing.
- Plan the TLS 1.3 migration for any remaining TLS 1.2 endpoints as a standalone workstream. The NCSC notes TLS 1.3 carries security benefits beyond quantum resilience, so this work has value independent of the PQC timeline.
5. Indicators of compromise
No indicators of compromise available in the source material. This item is a guidance publication and the sources describe no malicious activity, no infrastructure and no artefacts.
6. Detection
Insufficient indicators to author detection rules.
7. Sources
- NCSC, Post-quantum updates to our TLS guidance, https://www.ncsc.gov.uk/blogs/post-quantum-updates-to-our-tls-guidance, 2026-10-15
- NCSC, Post-quantum cryptography (PQC) migration workshop report, https://www.ncsc.gov.uk/blogs/post-quantum-cryptography-pqc-migration-workshop-report, date not stated in source
- Microsoft Threat Intelligence, Post-quantum authentication: Why organizations should start testing certificate ecosystems now, https://www.microsoft.com/en-us/security/blog/2026/10/08/post-quantum-authentication-why-organizations-should-start-testing-certificate-ecosystems-now/, 2026-10-08
- Tenable Research, Why a cryptographic inventory is key for addressing the quantum computing threat, https://www.tenable.com/blog/why-a-cryptographic-inventory-is-key-for-addressing-the-quantum-computing-threat, date not stated in source
8. Adverse Trace position
Adverse Trace assesses this as a planning item with a long horizon and no immediate exploitation risk. There is no CVE, no CVSS score, no severity rating and no CISA KEV entry to report, because nothing in the source material describes a vulnerability. The client impact is concentrated in two places: institutions still running TLS 1.2 or below have a prerequisite migration before any PQC work can start, and institutions without a cryptographic inventory cannot scope the work at all. The NCSC's 2031 date for high-priority migration is the planning anchor, but the harvest now, decrypt later tactic means data captured today under RSA or ECC is already at risk, so the confidentiality case does not wait for 2031. We will obtain the full NCSC guidance and extract the recommended hybrid and pure PQC configuration strings for client use, and we will track the pending pure PQC RFC and the NCSC's forthcoming IPsec and post-quantum authentication guidance. Clients who want support scoping a cryptographic inventory or a PQC interoperability test programme should contact their Adverse Trace account lead.
Published via PulseTrace — Adverse Trace threat intelligence.