TLS 1.0 and 1.1: Why They're Still Running and How to Find Them
In the back office of an otherwise modern company, there is often a fax machine. It is plugged in. It is occasionally used. There is exactly one customer - a hospital, a court, a regulator, an insurance company - who still requires faxes. Nobody has replaced the fax machine because nobody wants to be the person who breaks that one customer relationship. So it sits there, drawing a small amount of power, occasionally beeping, technically functional, completely out of place in 2026.
TLS 1.0 and TLS 1.1 are the fax machines of the internet.
The IETF officially deprecated both in March 2021 (RFC 8996). PCI-DSS, HIPAA, NIST, and every other compliance framework worth mentioning require TLS 1.2 as a minimum. Modern browsers refuse to negotiate them. And yet, in a meaningful fraction of organisations, they are still enabled somewhere - usually on internal systems, occasionally on legacy public endpoints - because of "that one client" or "that one appliance" or "we'll get to it next quarter" reasoning that goes back a decade.
Here's the official status, where they actually still live, why the "one client needs it" argument is weaker than it sounds, and how to find them in your environment.
The official status
TLS 1.0 was published in 1999. TLS 1.1 in 2006. Both were superseded by TLS 1.2 (2008) and now TLS 1.3 (2018).
Their deprecation timeline:
- 2018-2020. Major browsers (Chrome, Firefox, Safari, Edge) announced and rolled out removal of TLS 1.0/1.1 support. By the end of 2020, no mainstream browser would negotiate them. March 2021. IETF formally deprecated both in RFC 8996. "Must not be used" is the language. PCI-DSS 3.2 (2018). Required TLS 1.2 minimum for systems in scope, with a grace period that ended in mid-2018. PCI-DSS 4.0 (current). TLS 1.2 minimum is non-negotiable. NIST SP 800-52 Rev. 2. TLS 1.2 minimum, 1.3 strongly preferred.
There is no legitimate, defensible reason to enable TLS 1.0 or TLS 1.1 in 2026. The only defensible position is "we're temporarily allowing it for a specific compatibility reason, and here's the plan to remove it."
Where they actually still run
In practice, the long tail lives in five places.
Internal admin tools and legacy enterprise software. A SaaS dashboard installed in 2014, never re-baselined. An internal compliance portal whose vendor went out of business. A network management tool with custom certificates that has TLS 1.0 hardcoded. These tools were never reached by the deprecation push because they're not public, so external scanners didn't flag them.
IoT and embedded devices. Printers, cameras, sensors, building management systems, industrial control systems. These often ship with whatever TLS implementation was current at manufacture and never get updated. Some are now 10-15 years old. Their TLS 1.0 support is permanent unless replaced.
Old appliances - load balancers, firewalls, VPN concentrators. Vendor patches exist; vendor patches haven't been applied. Sometimes because the patch requires a maintenance window nobody scheduled. Sometimes because the device is past end-of-life and the vendor won't patch it anymore.
Legacy mobile applications. Apps written when TLS 1.0 was the only option, still in production, still on customer phones. New customers download updated versions; existing customers might not have updated.
B2B integrations with specific partners. "Our partner integration needs TLS 1.0" is the canonical defence. Sometimes true. Sometimes a five-year-old assumption that nobody's retested. Sometimes both.
The thread connecting all five: TLS 1.0 lives where attention doesn't reach. Things that are public, monitored, audited, and central tend to be on modern TLS. Things that are internal, peripheral, vendor-managed, or specific tend to be on whatever they were configured with the day they were deployed.
The "one client needs it" argument, examined
The defence for keeping TLS 1.0 enabled is almost always "we have a customer or partner who needs it."
This argument has three weaknesses worth naming.
It's often stale. The customer who needed TLS 1.0 in 2018 may have upgraded since. Nobody re-tested. The configuration is being maintained for a problem that may not exist anymore.
It's transferring risk. Allowing TLS 1.0 for one client means the configuration is weaker for all clients. An attacker on the network of a different, modern client can force a downgrade to TLS 1.0 and exploit the older protocol's weaknesses. The "one client" justification protects the one client at the expense of every other.
It's a compliance violation regardless. PCI-DSS doesn't care that you have a legacy client. HIPAA doesn't care. The requirement is TLS 1.2 minimum, full stop. "Our partner needs older TLS" is not an accepted exception.
The honest version of "we keep TLS 1.0 enabled for compatibility" is "we have a compliance gap and a security weakness, and we're choosing to maintain both because addressing them is awkward." That's a legitimate trade-off some teams make, but it should be named honestly.
The practical alternative: isolate the legacy traffic. The single endpoint or VLAN that talks to the legacy partner can be on its own configuration. Everything else moves to TLS 1.2+. This contains the exposure to the smallest possible surface.
How to find them in your environment
Three approaches, in order of effort.
External scanning. Public endpoints are easy. Qualys SSL Labs, testssl.sh, sslyze, or a continuous monitor will flag TLS 1.0/1.1 support immediately. If you're not doing this already, do it tomorrow.
Internal scanning. Internal endpoints are where most of the long tail lives. Run testssl.sh or sslyze against every internal service that listens on a TLS port. The first time you do this, expect to find things.
Inventory walkthrough. For appliances and devices that don't respond well to network scans (some IoT, some industrial), you have to inventory by vendor and version, then check each vendor's TLS support documentation. Slower, but for some environments the only path.
A practical phasing:
- an earlier piece: External scan. Fix anything public still permitting TLS 1.0/1.1. Weeks 2-4: Internal scan. Catalogue what you find. Months 2-6: Remediation. For each old endpoint, decide: upgrade, replace, isolate, or accept-with-mitigation. Document each. Months 6-12: Re-scan. Confirm the catalogue has shrunk.
How to remove them safely
Two phases that avoid breaking things.
Phase 1: Discovery and observation. Don't change anything yet. Enable logging that records which clients are actually using TLS 1.0/1.1 to your endpoints. Most servers can log this. After two weeks, you'll have a real list - usually shorter than feared.
Phase 2: Targeted removal. For each endpoint, you can now make an informed decision. Most will show zero TLS 1.0 connections - easy to disable. Some will show a small number from specific clients - work with those clients to upgrade or move to an isolated endpoint. A few will show meaningful traffic - these are your hard cases, and they need a plan, not a defence.
One small ask
TLS 1.0 and 1.1 are the longest-running fax machines on the internet. They persist because the audit windows haven't reached them, the public scans haven't caught them, and the people who would notice are looking at other problems. The cheapest way to find them is a continuous external scan plus an internal scan when you have time. TLS Radar handles the external side and flags any TLS 1.0/1.1 support immediately. The 30-day free trial covers three domains, which is enough to find at least one fax machine.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.