1. Executive summary
The NCSC has published revised guidance on configuring TLS, covering recommended cryptographic profiles for TLS 1.3 and TLS 1.2, the deprecation of SSL and TLS 1.0/1.1, certificate management, and migration to post-quantum cryptography (PQC). There is no vulnerability, no exploited CVE, and no threat actor in this item: it is configuration guidance, and no CISA KEV entry or CVSS score applies. The risk to EMEA financial services clients is not a new attack but the estate-wide exposure that comes from running deprecated protocol versions, insecure TLS features, and unpatched TLS implementations, all of which the guidance states can be exploited if security updates are not applied promptly. The material change for planning is the PQC migration path: the NCSC states that only TLS 1.3, correctly configured, provides protection against quantum attacks, and that TLS 1.2 users should plan to move to TLS 1.3 to adopt PQC.
2. Regulatory framing
No specific DORA/NIS2 article is directly engaged by this item. This is published configuration guidance, not an incident, a threat, or a third-party event, so no reporting or classification obligation is triggered by its publication. The table below records the articles that become relevant only if a client's own TLS estate is found to be misconfigured or exploited as a result of acting on (or ignoring) this guidance.
| Article | Trigger (the fact in this item) | Practical impact |
|---|---|---|
| DORA Art. 17: ICT-related incident management process | Engaged only if a deprecated protocol or unpatched TLS implementation in the client's estate is later exploited. The guidance itself is not an incident. | No action on this item alone. If exploitation occurs, the client's incident management process applies. |
| DORA Art. 24: digital operational resilience testing — general requirements | Engaged only where a client uses this guidance as the basis for TLS configuration testing across its estate. | Testing scope and evidence should be recorded if the client folds TLS profile validation into its resilience testing programme. |
| NIS2 Art. 21(2)(d): supply chain security measures | Engaged only where TLS configuration is imposed on, or inherited from, an ICT third-party provider. | Contractual and assurance checks on third-party TLS configuration, if the client relies on a provider to terminate TLS. |
3. Technical analysis & attack chain
There is no attack chain in this item. The source is configuration guidance, and no exploitation, actor, or campaign is described. What follows is the technical content a defender needs to act on it.
Supported versions. TLS 1.3 is the latest version and the only one that will receive new features, including PQC support. TLS 1.2 is still considered to provide strong protection against classical attacks when configured with the recommended cryptographic profiles, but it will not receive new features beyond critical security updates, as set out in RFC 9851. The NCSC advises that organisations using TLS 1.2 plan a transition to TLS 1.3 as part of PQC migration.
Deprecated protocols. SSL was the predecessor to TLS. All versions of SSL are deprecated and considered insecure, and the guidance states they must not be used. TLS 1.1 and TLS 1.0 have been deprecated by the IETF under RFC 8996 and should not be used. The NCSC recommends government systems do not support deprecated protocol versions and are upgraded to support TLS 1.3 instead. The guidance also states that TLS features known to be insecure must be disabled, though the source excerpt provided does not enumerate which features.
Post-quantum key exchange. A cryptographically-relevant quantum computer would threaten the key exchange and digital signature algorithms currently used to secure TLS. RFC 10024 standardises three post-quantum/traditional hybrid key agreement mechanisms in TLS 1.3:
- SecP256r1MLKEM768
- SepP384r1MLKEM1024
- X25519MLKEM768
All three are suitable for protecting personal, enterprise and OFFICIAL-tier government information. They combine the post-quantum ML-KEM algorithm with a traditional elliptic curve algorithm, and the NCSC recommends hybrid schemes as an interim measure during PQC migration. The IETF is also developing standards for non-hybrid ML-KEM (ML-KEM Post-Quantum Key Agreement for TLS 1.3), which will standardise MLKEM768 and MLKEM1024 as TLS options. The NCSC considers these acceptable for TLS and notes they are already available in many common TLS implementations.
Post-quantum authentication. The IETF has so far standardised post-quantum algorithms only for key exchange in TLS. Work on post-quantum authentication in TLS and the wider Web PKI is ongoing, with drafts at different levels of maturity. Organisations operating private PKIs may be able to adopt post-quantum authentication sooner than services relying on the public Web PKI. The source excerpt provided is truncated at this point, so the remainder of the authentication guidance is not available to this advisory.
Implementation currency. The guidance states that servers and client software must be kept up to date, because implementation flaws can introduce vulnerabilities that may be exploited if security updates are not applied promptly. No specific implementation flaw, CVE, or affected product is named in the source.
Confidence note. All of the above rests on a single source, the NCSC guidance page. The cryptographic profile details, the RFC references, and the PQC algorithm names are as published by the NCSC and have not been corroborated against a second source in this advisory. Verify against the live guidance page before making configuration changes.
4. Mitigation & containment
P1 (within 24 hours)
- Inventory every TLS endpoint in the estate and record the protocol versions and cipher suites each one offers. You cannot prioritise what you have not enumerated.
- Disable all versions of SSL on every listener. The guidance is unambiguous that these must not be used.
- Disable TLS 1.0 and TLS 1.1 on every listener, per RFC 8996.
- Disable TLS features known to be insecure. The source excerpt does not list them; consult the full NCSC guidance page for the current list before closing this item.
P2 (within 72 hours)
- Apply the NCSC recommended cryptographic profiles to all TLS 1.3 and TLS 1.2 listeners. The profiles themselves are on the guidance page and are not reproduced in the source excerpt provided here.
- Confirm that TLS 1.2 listeners are configured with the recommended profiles. The guidance treats TLS 1.2 as strong against classical attacks only when configured this way.
- Patch TLS implementations on servers and clients. The guidance attributes exploitable implementation flaws to delayed security updates.
P3 (within 7 days)
- Produce a written TLS 1.2 to TLS 1.3 migration plan with dates and owners. The guidance requires the plan as the precondition for PQC adoption.
- Assess PQC readiness for key exchange. The three RFC 10024 hybrid mechanisms (SecP256r1MLKEM768, SepP384r1MLKEM1024, X25519MLKEM768) are the recommended interim options and are already available in many common TLS implementations.
- For any private PKI you operate, begin scoping post-quantum authentication. The guidance notes private PKI operators may be able to move sooner than services dependent on the public Web PKI.
- Test the deployment. The guidance covers testing TLS deployments; use that section of the page as the test basis.
5. Indicators of compromise
No indicators of compromise available in the source material. This item is configuration guidance and contains no hashes, domains, IP addresses, file paths, or other atomic indicators.
6. Detection
Insufficient indicators to author detection rules. The source contains no threat artefacts: no strings, command lines, mutexes, scheduled tasks, file names, registry keys, or hard-coded values belonging to a malicious file or traffic. Any rule built from this item would detect reporting about TLS configuration, not a threat.
The one detection-adjacent action the guidance supports is a configuration check rather than a rule: enumerate listeners and alert on any that still offer SSL, TLS 1.0, or TLS 1.1. That is an inventory and compliance control, and it should be built from your own endpoint and network telemetry rather than from this advisory.
7. Sources
- National Cyber Security Centre, "Using TLS to protect data", https://www.ncsc.gov.uk/guidance/using-tls-to-protect-data, published 2026-10-15.
Single source. No corroborating vendor report, CVE record, or CISA KEV entry was available for this item, and none was resolved in the verified reference data.
8. Adverse Trace position
Adverse Trace assesses this as informational guidance with no associated vulnerability, exploitation, or attribution, and we have not assigned it a severity. The client impact is indirect and slow-moving: estates that still offer SSL, TLS 1.0, or TLS 1.1, or that run unpatched TLS implementations, carry exposure the NCSC states is exploitable, and the PQC migration requirement adds a planning obligation that will not resolve itself. We will track the full NCSC guidance page for the insecure-feature list and the recommended profile values, since the source excerpt provided to us is truncated before both, and we will reissue this note if the NCSC publishes a material revision. Clients should treat the P1 inventory step as the immediate action and route any TLS 1.2 to 1.3 migration planning through their existing resilience testing and third-party assurance processes.
Published via PulseTrace — Adverse Trace threat intelligence.