TLS 1.0 and 1.1 are dead in browsers and annoyingly alive in infrastructure.

That split is the whole story.

If you look at the web through the browser’s eyes, the migration mostly looks finished. If you look at the server and appliance long tail, it looks like one of those technologies that will continue rattling around the internet years after everyone agreed it should be gone. Deprecation is a policy event. Removal is a cleanup project. Those are not synchronized.

The Browser Story Is Over

RFC 8996 formally deprecated TLS 1.0 and TLS 1.1 in March 2021. Browser vendors had already moved: Chrome, Firefox, Safari, and Edge all dropped the old versions around 2020. A TLS 1.0-only site doesn’t get a nostalgic handshake. It gets an error page.

That part is settled. From the user’s perspective, old TLS is gone.

The Server Story Isn’t

Qualys SSL Pulse, which tracks roughly 150,000 popular HTTPS sites, has charted the decline of TLS 1.0 and 1.1 for years, and SSL Labs caps any server that still offers them at grade B. Popular sites are the easy part. A wider look is less flattering: Jan Kopriva’s year-end analysis of Shodan data for the SANS Internet Storm Center found support for TLS 1.0 and 1.1 essentially flat through 2024, at around 22% of the servers answering on port 443 — in a year when no mainstream browser would negotiate either version.

So the answer to “who’s still serving?” is: not the big sites. The long tail of the internet — the smaller servers, the forgotten infrastructure, the appliances nobody updates — is where old TLS hides.

Many of these servers aren’t serving web pages to browsers anymore. They’re serving APIs to legacy clients, handling machine-to-machine communication with hardcoded protocol versions, or sitting behind load balancers that haven’t been reconfigured since 2018.

Why They Persist

Payment terminals. Older POS devices and payment hardware can have firmware that speaks TLS 1.0 and nothing newer. Updating firmware on thousands of distributed devices is a capital expense that gets deferred year after year. PCI DSS required migrating off SSL and early TLS by June 30, 2018, but it carved out an exception for point-of-sale terminals that could be shown not to be susceptible to known exploits — and for the servers they connect to. Exceptions like that have a way of outliving their reasons.

Embedded and industrial systems. SCADA controllers, medical devices, building management systems — hardware with 10-20 year lifecycles and no OTA update mechanism. The TLS library was baked in at manufacturing time. Replacing the library means replacing the device.

“It works, don’t touch it.” Probably the most common reason. A server has been running for years. Nobody knows exactly what connects to it. Disabling TLS 1.0 might break an unknown client. The risk of breaking something outweighs the perceived risk of leaving it enabled. So it stays.

Forgotten servers. Virtual machines spun up years ago, still running, still reachable, maintained by nobody. They have old TLS enabled because that was the default when they were configured. Nobody has logged into them since.

Compliance that mandates specific versions. Some regulatory environments specify protocol versions in their requirements. If a 2015 compliance document says “use TLS 1.0 or higher,” lazy interpretation means 1.0 stays enabled alongside newer versions.

The Risk of Leaving It Enabled

TLS 1.0 has known vulnerabilities. BEAST (2011) exploits the predictable CBC initialization vectors in TLS 1.0 to decrypt data. POODLE (2014) was primarily an SSL 3.0 attack, though a variant later hit TLS implementations that skipped padding checks. Neither 1.0 nor 1.1 supports AEAD cipher suites like AES-GCM or ChaCha20-Poly1305, and both lean on MD5 and SHA-1 inside the handshake — the core of RFC 8996’s case for retiring them.

TLS 1.1 fixed BEAST’s initialization-vector problem but still lacks modern cipher suites and the stronger handshake hashing that TLS 1.2 introduced.

Who is actually at risk? Not modern browsers: they refuse anything below TLS 1.2, and TLS 1.3 carries a built-in downgrade check, on top of the older TLS_FALLBACK_SCSV signal. The exposure is the clients that still do connect with 1.0 or 1.1 — the old terminal, the forgotten script, the embedded device. Their traffic rides a protocol with known weaknesses, and as long as the server keeps accepting them, nobody learns they exist. Auditors notice, even if nobody else does: PCI scans and SSL Labs grades both flag it.

The counterargument is usually: “but our clients all negotiate 1.2 or 1.3 anyway.” If that’s true, turning 1.0 off costs you nothing. If it isn’t, you’ve just learned something important about your clients.

The Gap Between Deprecation and Removal

Browsers moved fast. A few major releases and old TLS was gone from the client side. The decision was centralized — a few browser vendors control the entire ecosystem.

Servers move glacially. There are millions of independent server operators, each making their own configuration decisions (or not making them, which is worse). There’s no central authority that can disable TLS 1.0 across all servers. It happens one configuration file at a time, when someone remembers, if they have access.

This asymmetry — fast client deprecation, slow server removal — means old TLS will be detectable on the internet for years after it stopped being usable by mainstream browsers. The protocol is deprecated. The cleanup will take a decade.

What You Should Do

If your server still offers TLS 1.0 or 1.1, disable it today. Check your config:

For nginx: ssl_protocols TLSv1.2 TLSv1.3; For Apache: SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1

No legitimate modern client needs TLS 1.0 or 1.1. If something breaks when you disable it, that something was already a security liability. Finding it now is better than finding it during an incident.

The standard deprecated it. The browsers rejected it. The only thing keeping TLS 1.0 alive is inertia. And inertia is not a security strategy.