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.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on DigiCert's blog post: TLS 1.0 and 1.1 remain a risk even as client use has dwindled, because broad server-side support and legacy protocol drag keep them alive.
Why it matters: IAM, PKI, and platform teams need to treat protocol deprecation as a lifecycle problem because dormant TLS paths still create downgrade exposure, integration breakage, and compliance pressure.
Context
TLS 1.0 and 1.1 are older HTTPS transport protocols that remain enabled in many environments long after most clients have moved on. The governance problem is that server-side support often outlives operational need, which leaves downgrade exposure in place and makes deprecation harder than the usage data suggests.
For identity and access teams, this is a certificate lifecycle and platform compatibility issue as much as a cryptography issue. Deprecated TLS versions persist because teams leave them enabled for compatibility, not because they are still preferred, and that creates a long tail of weak trust paths across web, API, and infrastructure traffic.
Key questions
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. Then test removal in non-production, fix dependencies, and enforce TLS 1.2 as the minimum version with an exception process for any remaining critical systems.
Q: Why do older TLS versions remain risky even when few clients use them?
A: Because risk comes from continued acceptance, not just traffic volume. If servers still permit TLS 1.0 or 1.1, attackers can try to force weaker negotiation paths, and the protocol remains part of the trust boundary whether or not most users ever select it.
Q: How do security teams know whether TLS deprecation is actually complete?
A: They know it is complete when no production endpoint, integration, or dependency can successfully negotiate TLS 1.0 or 1.1. Validation has to include APIs, developer tools, libraries, and non-browser clients, otherwise a hidden fallback path can survive after the main web estate is already updated.
Q: What is the difference between TLS preference and TLS enforcement?
A: Preference means a server will try to use the strongest protocol first, but still accepts older versions if a client asks. Enforcement removes the older versions entirely, which is the only state that actually closes the downgrade path and makes deprecated TLS unavailable in practice.
Technical breakdown
Why legacy TLS versions keep surviving in production
TLS 1.0 and 1.1 often remain enabled because protocol retirement requires coordinated change across servers, clients, libraries, and embedded dependencies. Even when browser use is low, non-browser traffic such as scripts, APIs, and older tooling may still negotiate older versions. The weak point is not the protocol alone, but the assumption that enabling newer TLS automatically eliminates older fallback paths. In practice, the older protocols stay available “just in case,” which turns deprecation into an inventory and compatibility problem.
Practical implication: inventory every client and integration that still negotiates TLS 1.0 or 1.1 before turning off support.
How downgrade risk persists after stronger TLS is available
Downgrade attacks work by forcing a connection onto a weaker protocol version when both sides still accept it. That means the security boundary is not simply which protocol a server prefers, but which versions it continues to tolerate. TLS 1.0 is especially problematic because it has known weaknesses and weaker cryptography, while TLS 1.1 inherits cryptographic limitations even without the same headline protocol flaws. Leaving either enabled keeps the weaker handshake option alive for an attacker to exploit.
Practical implication: remove protocol fallback behavior, not just promote TLS 1.2 in configuration.
Why deprecation breaks more than browser traffic
The article makes clear that the hardest failures appear outside ordinary browsing, especially in APIs, developer tools, and bundled dependencies like older curl builds. These dependencies are easy to overlook because they are often invisible to end users and may only surface when a service disables legacy protocols. That is why protocol deprecation behaves like an identity lifecycle problem: the affected parties are not just people using browsers, but services and machines with stale trust assumptions baked into their runtime.
Practical implication: test API clients, automation scripts, and packaged tooling separately from browser testing before enforcing deprecation.
Threat narrative
Attacker objective: The attacker objective is to force communication onto a weaker protocol path that is easier to intercept, manipulate, or abuse.
- Entry occurs when a client or dependency still accepts TLS 1.0 or 1.1 and negotiates a weaker connection path.
- Credential or session exposure follows when the weaker protocol allows a downgrade to cryptography the attacker can more easily exploit.
- Impact is the loss of transport security for HTTPS traffic, with legacy trust paths remaining available even after stronger TLS exists.
Breaches seen in the wild
- GitHub code signing certificate theft 2022: A machine account's compromised token cloned GitHub's Desktop and Atom repos, exposing encrypted signing certificates later revoked.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Legacy protocol support is a lifecycle failure, not a feature flag problem: TLS 1.0 and 1.1 remain exposed because organisations often treat protocol deprecation as a one-time configuration change instead of an inventory, dependency, and retirement process. That mindset leaves long-tail clients, APIs, and bundled libraries untouched. The practitioner lesson is that protocol shutdown needs governance, not just a configuration ticket.
Downgrade exposure is created by tolerance, not usage: A protocol can be technically rare and still remain operationally dangerous if servers continue to accept it. That is why low client adoption does not eliminate risk when 88% and 85% of sites still advertise support. The implication is that residual compatibility becomes the attack surface, not the traffic share.
Certificate and transport governance now overlap: TLS retirement is not just about cryptography strength, it is about how certificate-managed services, APIs, and machine clients negotiate trust over time. When older TLS stays enabled for convenience, organisations preserve brittle paths that undercut modern trust posture. Practitioners should treat protocol support as part of the identity and certificate lifecycle, not as an isolated network setting.
Legacy TLS fallback window: The real issue is the continued presence of fallback negotiation paths that survive after stronger standards are available. Those paths create an avoidable trust gap between policy and runtime behaviour. For teams managing PKI and access, the control question is whether old protocols are still accepted anywhere a machine can reach them.
Deprecation pressure now comes from ecosystem convergence: The article shows that major providers are removing TLS 1.0 and 1.1 support at roughly the same time, which means lagging systems will encounter breakage across many services rather than one isolated endpoint. That accelerates the need to map dependencies before change windows close. The practical conclusion is to align protocol retirement with full client and service discovery.
What this signals
Protocol deprecation is now a dependency-management problem: Teams cannot treat TLS retirement as a banner change on a load balancer. The hidden work is finding which APIs, scripts, and packaged tools still rely on legacy negotiation and then removing those dependencies before support is switched off.
PKI and transport policy need to move together: When an organisation keeps older TLS alive for compatibility, it preserves a weaker trust path that sits underneath certificate governance and endpoint hardening. The practical signal is that protocol support should be reviewed alongside certificate renewal and service ownership, not in isolation.
For practitioners
- Inventory every TLS endpoint and client dependency Build a complete list of web properties, APIs, automation scripts, libraries, and embedded clients that still negotiate TLS 1.0 or 1.1. Include non-browser traffic and bundled tooling because those are the systems most likely to fail first when support is removed.
- Disable legacy protocol fallback paths Remove TLS 1.0 and 1.1 support from servers after confirming that no required client still depends on them. The goal is not preference for TLS 1.2, but elimination of weaker negotiation paths that could be forced during a downgrade attempt.
- Test machine clients separately from browsers Validate API consumers, developer utilities, scheduled jobs, and dependency bundles in isolation so hidden compatibility issues surface before production changes. Browser testing alone will miss the services and scripts that often carry the oldest protocol assumptions.
- Tie protocol retirement to certificate lifecycle change Coordinate deprecation windows with certificate and endpoint renewal work so legacy protocol support is removed as part of the same controlled change. That keeps transport policy aligned with the systems that terminate TLS.
- Maintain an exception register for unavoidable legacy clients Where TLS 1.0 or 1.1 cannot yet be removed, document the business owner, the affected dependency, and the planned retirement date. Unowned exceptions become permanent fallback paths.
Key takeaways
- Older TLS support can remain a live security issue even when client usage has largely disappeared, because servers often continue to advertise weak fallback paths.
- The main exposure is downgrade risk and hidden compatibility debt across APIs, automation, and legacy tooling, not everyday browser traffic.
- The corrective action is to inventory dependencies, remove legacy protocol acceptance, and coordinate TLS retirement with certificate and service lifecycle changes.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-06 — Insecure Cloud Deployment Configurations | Legacy TLS exposure is a runtime configuration issue on services that continue to accept weak protocols. |
| Recommendation — Remove legacy protocol acceptance from exposed services and verify that only modern TLS is negotiated. | ||
| NIST SP 800-53 Rev 5 | SC-13 — Cryptographic Protection | TLS version retirement directly affects the cryptographic protection of network communications. |
| Recommendation — Enforce approved cryptographic protections and eliminate deprecated protocol support from production endpoints. | ||
| NIST CSF 2.0 | PR.DS-02 — Data-in-Transit is Protected | The article concerns transport security for HTTPS traffic and the risks of weak protocol fallback. |
| Recommendation — Verify that all data in transit uses approved modern protocols and no deprecated versions remain enabled. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | Keeping TLS 1.0 and 1.1 enabled is a configuration hygiene problem across services and clients. |
| Recommendation — Harden endpoint configurations to disable obsolete TLS versions across every exposed service. | ||
| MITRE ATT&CK | TA0006 — Credential Access | Downgrade paths increase the chance that traffic protection can be weakened for credential-bearing sessions. |
| Recommendation — Map legacy TLS exposure to credential access risk and prioritise systems that carry sensitive sessions. | ||
Key terms
- TLS deprecation: TLS deprecation is the planned removal of support for older transport security protocol versions that are still functional but no longer acceptable for modern security requirements. It usually happens when a version has known weaknesses, poor cryptographic properties, or creates excessive compatibility risk for safer environments.
- Downgrade attack: A downgrade attack forces a connection to use a weaker protocol or cipher than both sides could otherwise support. In practice, it turns legacy compatibility into a security weakness by increasing the chance that known flaws or weaker cryptography can be exploited during negotiation.
- Protocol Fallback Path: A protocol fallback path is the behaviour that allows a client and server to try an older or weaker version when the preferred version fails. In identity and transport governance, fallback paths are risky because they preserve legacy trust conditions that are easy to forget and hard to notice in production.
- Certificate Lifecycle Management: The governance of digital certificates from issuance through renewal and revocation, ensuring certificates are valid, monitored, and rotated before expiry. Expired certificates are a leading cause of outages and unplanned security gaps.
Deepen your knowledge
NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 25, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org