TLS 1.3 across four census editions: what moved and what didn't

When an auditor asks which TLS (Transport Layer Security) versions a web server will negotiate, a truthful list that includes 1.2 raises one question. Is that a finding to remediate, or the answer nearly everyone else would give? Across four census editions, TLS 1.3 was negotiated on 94.81%, 94.87%, 94.41% and 94.56% of completed handshakes. TLS 1.2 was negotiated on 5.19%, 5.13%, 5.59% and 5.44%. A server that prefers 1.3 and still answers 1.2 matches most of the web, and that mix has barely moved from July to October.

How the comparison is built

The numbers only mean something once you know what they’re divided by, so the method comes first. The census scans the registered internet once a month, and this comparison runs over the 1243 TLDs (Top-Level Domains) present in the July, August, September and October lakes (IDN TLDs excluded: their partition names differ between lakes). The census scanned each TLD in that cohort in all four rounds and computed the TLS outcome the same way from the raw evidence each time. Grades and dispositions play no part in it.

The number of domains inside a TLD moves between editions because the source lists differ. One month a zone file arrives with more names in it, and the next month fewer of them turn out to exist. Up to September, a pass before the scan removed the names that no longer exist. From October, names that answer NXDOMAIN (Non-Existent Domain) are removed after the scan. If you divided “domains that negotiated 1.3” by “domains in the cohort”, you’d be measuring the size of the source lists as much as the protocol, so that ratio isn’t published here as a trend.

What’s compared instead is the share within each edition’s own completed handshakes. July’s numerator is divided by July’s handshakes, August’s by August’s, and so on through October. A completed handshake agreed on one version, and the scanner recorded that agreed version identically in all four rounds. Some domains complete no handshake at all in a given edition, because nothing answers on port 443 or the connection fails before a version is settled, and those domains are left out of the denominator. A name that doesn’t exist completes no handshake either, so it never enters these shares.

The full rule for what does and doesn’t get compared across editions is written up in what we compare, and this piece follows it.

The series

The table gives each edition its own denominator, so the shares can be read down the column.

The column to read is the share. The counts rise in August, fall back in September and rise again in October. Over the same months the number of cohort domains answering HTTP (Hypertext Transfer Protocol) rose in every edition, as the HSTS and CSP page shows. So fewer handshakes completed in September for reasons this data doesn’t separate, from changes in the source lists to connections that failed on scan day. Either way the counts say nothing about sites adopting or abandoning 1.3. Only the share compares from one row to the next.

Read that way, TLS 1.3 stayed between 94.41% and 94.87% of the cohort’s completed handshakes across the four editions. TLS 1.2 never left the band between 5.13% and 5.59%.

The older versions are absent from that spine because they’d add nothing. Of the 220,264,382 October domains where a TLS handshake completed, TLS 1.1 was negotiated on 0 (0.00%) and TLS 1.0 on 0 (0.00%). The scanner offers modern versions first and takes what the server gives, as a browser does, so a server that would still accept 1.0 from an old client doesn’t show here. The zero does tell you that no server in the edition dropped below 1.2 for a current client.

What four points that barely moved tell an auditor

Across four editions the mix shifted by fractions of a percentage point in either direction. That’s the finding, and it’s the one a vendor’s adoption page won’t give you. A single “95% of sites now support TLS 1.3” line with no date and no denominator can’t tell you whether the number is climbing, flat or slipping.

Read it from the 1.2 side and it says the same thing. The 1.2 share of completed handshakes didn’t shrink between July and October. The clients and servers that negotiate 1.2 are a stable population, and they aren’t going away between one audit cycle and the next.

For a builder answering a questionnaire, that gives you two sentences you can defend. A server that prefers 1.3 is doing what the large majority of completed handshakes on the web already do. One that still accepts 1.2 is serving a stable minority that the census shows holding steady.

Why 1.2 stays enabled and 1.0 and 1.1 don’t

TLS 1.2 with modern cipher suites is a supported protocol. It’s the floor that payment-card rules, browser vendors and the IETF settled on, and the versions that were formally retired are 1.0 and 1.1, in RFC 8996 (Request for Comments). An audit that flags 1.2 as a weakness on its own, with no comment on cipher suites or key exchange, is applying a stricter standard than the standards bodies did.

The clients that still need 1.2 are the ones you’d expect. Embedded devices with firmware that’s years old, monitoring agents and uptime checkers built on older TLS libraries, corporate proxies that terminate and re-originate connections, and long-lived integrations someone wrote against your API in 2019 and hasn’t touched since. Switch 1.2 off and those clients stop connecting, and a failing partner integration is often the first sign.

The sensible configuration is the one the census shows in practice. Offer 1.3 first, keep 1.2 available, restrict 1.2 to ECDHE key exchange and AEAD (Authenticated Encryption with Associated Data) ciphers (the AES-GCM and ChaCha20-Poly1305 suites), and disable 1.0 and 1.1 outright. Most of the census line for 1.2 is servers doing exactly this and meeting a client that couldn’t go higher.

What to write in the questionnaire box

The answer that satisfies an auditor is a version list with a date on it. “We support modern TLS” invites a follow-up. “TLS 1.3 preferred, TLS 1.2 accepted, 1.1 and 1.0 disabled, verified 13 October 2026” closes the item. Add the cipher-suite restriction on 1.2 in a second line, since that’s the follow-up an auditor usually asks next.

Verify it yourself before you write it down, from a machine outside your own network. This asks your server for 1.3 and prints the version it agreed:

openssl s_client -connect yourdomain.example:443 -tls1_3 </dev/null 2>/dev/null | grep Protocol

You want Protocol : TLSv1.3 back. Then run the same command with -tls1_1 and with -tls1 in place of -tls1_3. From a server that has retired the old versions you’ll get a handshake failure or a protocol version alert and no Protocol line at all. If either of those comes back with a version string, the old protocol is still answering, and you’ll want to fix that before the audit turns it up.

Write the date of that check into the answer. Version lists drift when a load balancer is replaced or a hosting plan migrates, and an auditor reading “verified last week” will treat it differently from one reading “policy says”.

Where your own host falls in the series

Whatever the census says about the cohort, the audit is about one host, and the version your own host negotiates is one line in a scan. The scanner does the same handshake described above, records the version and the certificate, and reads the response headers the same audit will ask about next. Run the free scan on your domain and read the TLS line before you fill in the box.

If the line says 1.3 with a valid certificate, the questionnaire answer is written for you. If it says 1.2 as the best your host will do, you’ve got a configuration to update and no compliance problem: the TLS pillar walks through the change for the common web servers. Once the version is settled, the headers result on the same scan is where the next audit question lands, because a host that negotiates 1.3 and then serves without HSTS (HTTP Strict Transport Security) still lets a browser’s first request arrive unencrypted.

Figures from the defaults.exposed census, data as of 12 October 2026. Census numbers move every month; the current values are on the census data page.