Notifications
Clear all
Topic starter
25/06/2026 10:34 pm
TL;DR: Older TLS versions remain widely enabled even as client usage has dwindled, with SSL Pulse showing 88% of HTTPS-enabled sites supporting TLS 1.0 and 85% supporting TLS 1.1, according to DigiCert. The real issue is not adoption speed but the long tail of systems that still depend on deprecated protocol paths and weak cryptography.
NHIMG editorial — based on content published by DigiCert: Deprecating TLS 1.0 and 1.1
By the numbers:
- 88% support TLS 1.0 and 85% support TLS 1.1.
- Only 0.38% of traffic on Cloudflare's network uses TLS 1.1.
- About 11% of traffic on Cloudflare's network uses TLS 1.0.
Questions worth separating out
Q: How should security teams phase out TLS 1.0 and 1.1 without breaking key services?
A: Start by mapping every client that still negotiates the old protocols, especially APIs, scripts, and bundled tools.
Q: Why do deprecated TLS versions remain enabled long after they are no longer recommended?
A: They stay on because organisations fear hidden breakage more than they fear the protocol risk.
Q: What breaks when organisations remove support for older TLS versions too quickly?
A: Non-browser clients are usually the first to fail.
Practitioner guidance
- Map every TLS consumer before deprecation Identify browsers, APIs, scripts, embedded tools, and partner integrations that still depend on TLS 1.0 or 1.1.
- Set TLS 1.2 as the minimum policy floor Update web, API, and platform security standards so TLS 1.2 is the lowest permitted version.
- Test deprecation against non-browser clients first Validate removal plans against curl, libraries, automation scripts, and other machine-to-machine consumers before production enforcement.
What's in the full article
DigiCert's full blog post covers the operational detail this post intentionally leaves for the source:
- The specific browser and platform compatibility issues that made TLS 1.2 adoption uneven at the time
- Examples of major services that had already scheduled TLS 1.0 and 1.1 shutdowns across websites and APIs
- The IETF and browser support context behind TLS 1.3 adoption and why it changed the deprecation conversation
- Observed breakages in developer tools after GitHub disabled older TLS versions
👉 Read DigiCert's analysis of TLS 1.0 and 1.1 deprecation →
TLS 1.0 and 1.1 deprecation: what IAM and PKI teams face?
Explore further
25/06/2026 11:09 pm
TLS deprecation is really access governance for machine traffic. The article is about protocol versions, but the operational issue is who and what can still authenticate through legacy paths. Those paths tend to persist in APIs, scripts, and service-to-service connections long after human users have moved on. Practitioners should treat TLS shutdown as a control over machine access, not just a cipher upgrade.
A few things that frame the scale:
- 59% of companies face greater difficulties auditing machine identities, primarily due to lack of clear ownership and limited visibility, according to The Critical Gaps in Machine Identity Management report.
- Only 38% have automated certificate lifecycle management in place, which helps explain why protocol retirement and certificate governance so often lag policy.
A question worth separating out:
Q: Who is accountable when a business system still requires deprecated TLS support?
A: The system owner, security team, and application owner all share responsibility, but one person must own the exception. A protocol exception without an expiry date becomes permanent risk, so accountability should include review cadence, remediation milestones, and sign-off for continued use.
👉 Read our full editorial: Deprecating TLS 1.0 and 1.1 exposes lingering protocol risk
