TLS 1.0 and TLS 1.1 enabled
Deprecated versions increase attack surface and should not be negotiated.
Disable them and document any temporary exception with a deadline.
TLS migration guide
TLS 1.2 Downgrade Risk and PQC Migration
TLS 1.2 can still be strong when configured carefully, but TLS 1.3 is the practical foundation for post-quantum TLS. If a website or API still depends on TLS 1.2-only clients, that compatibility path needs a migration plan before hybrid ML-KEM can protect the traffic.
Updated: 19 June 2026|12 min read
TLS 1.2 only
TLS 1.2 can still be strong when configured well, but NCSC says TLS 1.2 will not be updated to support PQC.
Enable TLS 1.3 and plan client migration before relying on hybrid ML-KEM TLS.
Weak TLS 1.2 ciphers
CBC, static key exchange, old curves or weak signatures can preserve legacy risk even if TLS 1.2 is allowed.
Use recommended TLS 1.2 profiles only while moving eligible traffic to TLS 1.3.
Fallback and compatibility paths
Load balancers, origin paths, API gateways or old clients can silently negotiate weaker configurations.
Scan every public hostname and API path, not only the homepage.
The Practical Problem
TLS 1.2 is not the same problem as TLS 1.0 or TLS 1.1. The old versions are deprecated and should be disabled. TLS 1.2 remains widely deployed and can be configured securely for classical threats, but it carries more configuration complexity than TLS 1.3.
For post-quantum migration, the issue is more direct: current web PQC deployment is built around TLS 1.3 hybrid key agreement. NCSC guidance says TLS 1.2 will not be updated to support PQC and that organisations using only TLS 1.2 need a plan to move to TLS 1.3.
That means a TLS 1.2-only estate is not just a legacy configuration issue. It is a migration blocker for future quantum-safe key establishment.
Endpoint Checklist
- -TLS 1.3 is enabled and preferred over TLS 1.2 where supported.
- -TLS 1.0, TLS 1.1, SSLv2 and SSLv3 are disabled.
- -TLS 1.2 remains only for identified clients that still need it.
- -TLS 1.2 cipher suites are limited to recommended AEAD/ECDHE profiles where possible.
- -Known downgrade and fallback paths are documented and monitored.
- -CDN, load balancer, API gateway and origin policies match each other.
- -Client teams have a retirement plan for TLS 1.2-only runtimes.
- -PQC testing is run over TLS 1.3 paths with current browser or SDK support.
Why Downgrade Paths Matter
TLS downgrade risk is rarely a single setting. It can come from a CDN edge, an origin server, an API gateway, a partner callback endpoint, an old mobile runtime or a temporary compatibility exception that became permanent.
RFC 9325 recommends that implementations support TLS 1.3 and prefer it over earlier versions when available. It also explicitly encourages migration of most TLS 1.2 use to TLS 1.3 and warns that TLS 1.2 environments must still follow detailed hardening rules.
A useful PQC migration plan therefore treats TLS 1.2 as a managed compatibility layer, not the future state. Keep it where evidence says it is needed; remove it where it is only historical inertia.
Migration Steps
- 1. Measure every endpoint. Scan websites, APIs, VPN portals, admin consoles, partner callbacks and non-standard HTTPS ports for supported TLS versions and cipher suites.
- 2. Disable deprecated versions. Remove TLS 1.0 and TLS 1.1 unless a documented, time-bounded exception exists for a legacy client.
- 3. Harden TLS 1.2 while it remains. Keep TLS 1.2 only with recommended profiles, forward secrecy and strong AEAD cipher suites where client compatibility allows.
- 4. Make TLS 1.3 the default path. Enable and prefer TLS 1.3 at the CDN, load balancer, API gateway and origin, then test real client populations.
- 5. Pilot hybrid ML-KEM. Test X25519MLKEM768 or provider-supported hybrid ML-KEM on TLS 1.3 paths, measuring compatibility, latency and operational evidence.
What Good Evidence Looks Like
For an audit or migration backlog, "we use a modern CDN" is not enough. Good evidence includes a live scan result, TLS policy export, provider documentation, client compatibility data and an owner-approved retirement date for legacy paths.
Public scans are a fast first pass, but they only cover visible hostnames. Internal mTLS, service mesh, managed service APIs, mobile apps and partner integrations need their own discovery and testing.
Primary References
FAQ
Is TLS 1.2 insecure?
TLS 1.2 can still be strong when configured with recommended profiles, but it carries more configuration risk and is not the practical foundation for future post-quantum TLS migration.
Why does PQC migration depend on TLS 1.3?
Current deployed hybrid post-quantum key agreement for web traffic is based on TLS 1.3. NCSC guidance says organisations using only TLS 1.2 need a plan to move to TLS 1.3 to use PQC in future.
Should I disable TLS 1.2 today?
Not always. Many environments still need TLS 1.2 for compatibility. The safer path is to enable and prefer TLS 1.3, harden TLS 1.2, then retire TLS 1.2 where client evidence allows.
Can a scanner find every TLS downgrade path?
No. A public scan can find visible endpoint configuration, but internal service paths, mobile clients, partner APIs, origin bypasses and non-standard ports still need inventory and testing.
Check Your TLS Migration Starting Point
Run a free external scan to capture visible TLS posture, then use the result as the first item in your broader cryptographic inventory.
Free readiness account
Keep This Guide Connected to a Real Website Scan
A PQC guide is more useful when it is attached to current evidence. Create a free account, add a public domain now or later, and keep a repeatable baseline for TLS, security headers and visible post-quantum readiness.
No cardStart the free evidence path without a paid plan.
Saved scanKeep the public endpoint result after the browser session.
Rescan laterRerun after TLS, header or provider changes.
Prefer to scan first? Open the free quantum security scanner.