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

An auditor has asked which TLS versions your web server will negotiate. The truthful list includes 1.2, and you want to know whether that’s a finding to remediate or the answer nearly everyone else would give. Across three census editions, TLS 1.3 was negotiated on 94.81%, 94.87% and 94.41% of completed handshakes; TLS 1.2 on 5.19%, 5.13% and 5.59%. A server that prefers 1.3 and still answers 1.2 matches most of the web, and that mix has barely moved in three months.

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 1244 TLDs present in the July, August and September lakes (IDN TLDs excluded: their partition names differ between lakes). The census scanned each TLD in that cohort in all three 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, the next month fewer of them survive the existence pass. 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, September’s by September’s. A completed handshake agreed on one version, and the scanner recorded that agreed version identically in all three 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.

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 without exception.

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 and fall back in September because the cohort’s domain population rose and fell with the source lists, and they 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 three months, and 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 212,154,494 September 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 three points that barely moved tell an auditor

Across three months 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, because 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 over the summer. 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, and 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. 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 the first you’ll hear of it is a partner’s integration failing at three in the morning.

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 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, because “we support modern TLS” invites a follow-up and “TLS 1.3 preferred, TLS 1.2 accepted, 1.1 and 1.0 disabled, verified 6 September 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 still lets a browser’s first request arrive unencrypted.

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