Deprecating TLS 1.0 and 1.1 exposes lingering protocol risk

At a glance

What this is: This is an analysis of why TLS 1.0 and 1.1 deprecation is overdue and what the remaining support tail means for HTTPS security.

Why it matters: It matters to IAM and security teams because protocol deprecation affects certificate lifecycle, API clients, and the access paths that still rely on outdated cryptography.

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.

👉 Read DigiCert's analysis of TLS 1.0 and 1.1 deprecation

Context

TLS deprecation is the process of removing support for older protocol versions that are still technically usable but no longer appropriate for modern security requirements. In practice, the problem is not only cryptographic weakness, but also the operational dependency chain that keeps outdated clients, APIs, and infrastructure alive longer than policy intends.

For identity and access teams, this is a lifecycle issue as much as a transport issue. Certificate management, API compatibility, and third-party integrations all depend on secure protocol negotiation, so keeping TLS 1.0 or 1.1 enabled can preserve legacy access at the cost of wider exposure and weaker control assurance.

The article's starting position is typical: many organisations know the older protocols should go, but defer shutdown because the breakage risk is hard to inventory. That tension is familiar across IAM, NHI, and platform security programmes.

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 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. Legacy clients, vendor dependencies, and poor inventory coverage make removal hard, so teams leave old support in place unless they have clear visibility and an owner for every connection path.

Q: What breaks when organisations remove support for older TLS versions too quickly?

A: Non-browser clients are usually the first to fail. Old libraries, embedded tools, and automation scripts may not support TLS 1.2, so teams can trigger outages in integrations that were never fully documented or tested against protocol changes.

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.

Technical breakdown

Why TLS 1.0 and 1.1 remain a security liability

TLS 1.0 is nearly two decades old and has known weaknesses such as BEAST and POODLE, alongside support for older cryptographic suites that no longer meet modern expectations. TLS 1.1 removes some protocol issues but still inherits weak cryptography and limited adoption. The security problem is not just whether a protocol still works, but whether it keeps downgrade paths alive that attackers can exploit when clients or servers negotiate weaker settings.

Practical implication: inventory every endpoint that still negotiates old TLS versions and treat them as remediation blockers.

How legacy clients keep deprecated TLS alive

Deprecated TLS often survives because non-browser clients, embedded tools, old libraries, and downstream dependencies still require it. That means the real control boundary is not the website banner, but the full set of applications, scripts, and APIs that must connect successfully. When a server turns off TLS 1.0 or 1.1, previously hidden breakage appears in integration flows, which is why protocol deprecation frequently exposes dependency debt rather than purely security debt.

Practical implication: test protocol removal against all machine-to-machine consumers before you set an enforcement date.

TLS 1.2 as the practical floor for modern HTTPS

TLS 1.2 is the current recommended baseline in the article because it is broadly supported by modern browsers and software while avoiding the weaknesses that keep older versions acceptable only as stopgaps. The important architectural point is that protocol version is part of the trust path. If the handshake can fall back to older versions, then policy, user agent compatibility, and security posture all become coupled in ways that are difficult to govern cleanly.

Practical implication: make TLS 1.2 the minimum accepted version in policy, monitoring, and vendor requirements.

NHI Mgmt Group analysis

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.

Weak protocol support creates hidden lifecycle debt. Organisations leave TLS 1.0 and 1.1 enabled because they have not fully mapped downstream dependencies, and that is the same visibility problem that shows up in NHI management. When the environment cannot identify every consumer, deprecation becomes guesswork. The implication is that lifecycle control for certificates and clients has to precede protocol removal.

Deprecated TLS is a standing privilege problem in transport form. Older protocol support exists for compatibility, but compatibility becomes a persistent exception state if it is never revoked. That exception state is familiar across IAM and NHI governance, where temporary allowances become permanent. Practitioners should see protocol retirement as a privilege cleanup exercise with security consequences.

Protocol version policy should be enforced as a minimum trust boundary. Allowing old TLS versions means the organisation accepts weaker assurance for a subset of connections, even when most traffic has already moved on. The article shows why “just in case” support often outlives its justification. Security teams should make protocol floors explicit in standards, monitoring, and vendor contracts.

Weak cryptography: was designed for compatibility, not modern threat conditions. That assumption fails when the environment still contains clients and services that can be coerced into older negotiation paths. The implication is that modern identity and access programmes cannot treat transport security as a static baseline once legacy compatibility becomes part of the threat surface.

From our research:

• 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.
• That same lifecycle gap connects directly to NHI Lifecycle Management Guide, where ownership, rotation, and offboarding are treated as linked controls rather than separate tasks.

What this signals

Protocol deprecation will increasingly be governed like machine identity change control. The organisations that succeed will be the ones that can trace every dependent client, not just every external website. The work is shifting from blanket policy statements to connection-level inventory and exception management, and that is a familiar pattern for teams managing workload identity and other machine access paths.

With 57% of organisations lacking a complete inventory of their machine identities, weak visibility is the same operational problem that makes TLS shutdowns difficult and makes access governance brittle. That is why protocol floors, dependency maps, and certificate governance belong in the same programme conversation.

For teams building maturity, the next step is not another compatibility waiver. It is to pair deprecation work with lifecycle controls, ownership mapping, and the documentation discipline outlined in the NHI Lifecycle Management Guide.

For practitioners

• 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. Use traffic logs and dependency discovery to build a complete list before enforcing a shutdown date.
• 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. Align monitoring and configuration checks with that floor so drift is visible quickly.
• Test deprecation against non-browser clients first Validate removal plans against curl, libraries, automation scripts, and other machine-to-machine consumers before production enforcement. Hidden failures often surface there before they affect end users.
• Treat legacy protocol exceptions as time-bound risk If a business-critical system still requires old TLS temporarily, record the exception owner, expiry, and remediation plan. Do not allow indefinite compatibility just because the traffic volume is low.

Key takeaways

• Older TLS versions survive less because they are needed and more because organisations have not fully mapped the systems that still depend on them.
• The main risk of leaving TLS 1.0 and 1.1 enabled is not theoretical weakness, but the downgrade and compatibility paths they keep alive for machine traffic.
• Practical deprecation requires dependency inventory, TLS 1.2 enforcement, and a controlled exception process for the few systems that still cannot move.

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.
• Certificate lifecycle management: Certificate lifecycle management is the governance of issuance, renewal, rotation, validation, and retirement for digital certificates and the systems that depend on them. It matters because transport security, client compatibility, and service continuity all depend on certificates being managed as a controlled identity asset.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or operational governance, it is worth exploring.

This post draws on content published by DigiCert: Deprecating TLS 1.0 and 1.1. Read the original.