Defaults.Exposed › Reports

Cipher Suites in 2026: What Strong Encryption Really Means

Published 2026-08-18

Figures as of 16 August 2026 · methodology v9. This is a recurring report; each edition re-measures the same population so the numbers can be tracked over time. All figures are aggregate — we never publish an individual business’s grade or name an individual registrant’s domain.

The headline: two cipher suites carry 94.3% of the encrypted web

Across the 212 million cipher-suite records in our August 2026 census, just two cipher suites — TLS_AES_256_GCM_SHA384 and TLS_AES_128_GCM_SHA256 — accounted for 94.33% of everything we saw. Add one more, the TLS 1.2 workhorse ECDHE-RSA-AES256-GCM-SHA384, and three suites cover 96.40% of the encrypted web.

That is a remarkable ending to a messy story. TLS used to be a bazaar. Hundreds of registered cipher suites, export-grade downgrades, RC4 hanging on for a decade past its expiry, servers offering forty options and hoping the client picked a good one. In 2026 the bazaar is gone. What replaced it is close to a monoculture, and for once the monoculture is the good outcome.

Key numbers

• Two cipher suites carried 94.33% of measured TLS handshakes in the August 2026 census (TLS_AES_256_GCM_SHA384 at 59.21%, TLS_AES_128_GCM_SHA256 at 35.12%).
• 94.87% of all cert-presenting domains negotiated TLS 1.3 (219,593,564 of 231,455,163); TLS 1.2 carried the remaining 5.1%.
• By encryption family: AES-256-GCM 61.51%, AES-128-GCM 37.69%, ChaCha20-Poly1305 0.68% — everything else combined is 0.12%.
• 99.88% of handshakes used a modern AEAD cipher; legacy CBC-mode suites accounted for just 251,450 handshakes (0.119%).
• 99.98% of handshakes had forward secrecy; only 44,404 used static-RSA key exchange with no forward secrecy at all.
• RC4, 3DES, export-grade and NULL ciphers: zero. Not one handshake negotiated any of them.

What did we actually count?

Every domain in our census that completed a TLS handshake during scanning has the negotiated protocol and cipher suite on record. The cipher-suite distribution covers 212,025,865 handshakes — essentially the population of graded domains where TLS completed and a suite was captured. One handshake per domain, from our scanner, in August 2026.

That last sentence matters more than it looks, so here it is plainly: a cipher suite is negotiated, not published. The server offers what it supports, our client offers what it supports, and the recorded suite is the intersection they agreed on. These numbers describe what a modern, well-configured client gets from today’s servers. They do not enumerate every suite each server would accept from a weaker client. A server that would happily fall back to a CBC suite for an ancient client still shows up here with its best answer. The full caveat set is in the methodology section below.

With that framing fixed, the distribution is stark.

Thirty-nine distinct suites appeared in total. The bottom thirty-three of them together carry half a percent of the web. The tail includes genuine curiosities: 17 handshakes negotiated ARIA, South Korea’s national block cipher, and a single handshake in 212 million used DSS authentication. Someone, somewhere, is running that server.

Why did the web converge on so few suites?

Because TLS 1.3 forced the issue, and TLS 1.3 won. The protocol — standardised as RFC 8446 in August 2018, which is industry context, not census data — threw out the combinatorial suite zoo of earlier versions. TLS 1.3 defines only five suites, all of them AEAD, all of them forward-secret by construction, and mainstream implementations ship three: AES-128-GCM, AES-256-GCM, and ChaCha20-Poly1305. There is no way to configure a TLS 1.3 server badly at the cipher layer. The bad options no longer exist in the protocol.

So the convergence story is mostly the TLS 1.3 adoption story wearing a different hat: 94.87% of cert-presenting domains in our census landed on TLS 1.3, and TLS 1.3 offers three suites, so of course three-ish suites dominate. We covered the version-adoption race in detail in our TLS 1.3 adoption report; this piece is about what happens inside the tunnel once the version is picked.

The second driver is defaults. Almost nobody hand-tunes cipher preference in 2026. Servers run whatever their web server or CDN ships, and those defaults have quietly standardised on the same short, sane list. The 59/35 split between AES-256-GCM and AES-128-GCM at the top is largely an artifact of server-side preference orders in popular stacks — again industry context — rather than millions of administrators making a deliberate 256-versus-128 choice. Convergence through apathy, with a good default underneath. It worked.

Is AES-256 actually stronger than AES-128 here?

This is the question the top of the table begs, and the honest answer is: on paper yes, in practice it makes no measurable difference to anyone’s risk.

By encryption family, the census splits like this:

AES-128 has a 128-bit key; brute-forcing it is beyond any plausible computing effort, classical or otherwise, for the foreseeable future (industry consensus, not our measurement). AES-256’s larger key buys margin against far-future threats and satisfies certain compliance regimes that mandate 256-bit keys. Both, in GCM mode, are authenticated encryption: they encrypt and integrity-protect in one construction, which is the property that actually separates modern suites from the legacy ones.

So when 61.5% of the web says AES-256 and 37.7% says AES-128, neither cohort is meaningfully “at risk” versus the other. The 99.88% on any AEAD suite is the number that describes the web’s health. The 256/128 split describes its defaults.

ChaCha20-Poly1305 deserves its own sentence, because 0.68% understates it. ChaCha20 exists mainly for clients without AES hardware acceleration — cheaper mobile chips especially — and it is the client that steers negotiation toward it (industry context). Our scanner is a desktop-class client with AES acceleration, so servers had little reason to pick ChaCha20 for us. The 1.4 million handshakes where they did anyway tell you those servers prefer it; they tell you nothing about how much ChaCha20 real phone traffic uses, which is certainly higher. Treat our ChaCha20 figure as a server-preference floor, not a traffic share.

What happened to the bad ciphers?

They died, and this census can put numbers on the corpse.

RC4: zero handshakes. Prohibited for TLS by RFC 7465 back in 2015 (industry context). A decade later, not one server in 212 million negotiated it with us.

3DES: zero. The Sweet32 birthday-bound attacks made 64-bit block ciphers untenable in 2016 (industry context). Gone.

Export-grade and NULL suites: zero. The deliberately weakened ciphers of 1990s crypto policy do not appear once.

What survives of the old world is CBC mode: 251,450 handshakes (0.119%) on AES-CBC suites, the kind that powered the Lucky13 and padding-oracle era. A quarter of a million domains is not nothing — it is a small city of servers that have not been touched in many years — but as a share of the web it is a rounding error, and every one of those handshakes still used AES, not a broken cipher.

The forward-secrecy picture is even cleaner. TLS 1.3 makes forward secrecy mandatory; on TLS 1.2, ECDHE and DHE key exchange provide it. Only 44,404 handshakes — 0.021% — used static-RSA key exchange, where a future compromise of the server’s private key would retroactively decrypt recorded traffic. In 2013 that failure mode described most of the internet. In this census, 99.98% of handshakes are forward-secret.

One near-extinction worth logging for future editions: classic finite-field DHE, the pre-elliptic-curve Diffie-Hellman, is down to 92,914 handshakes — 0.85% of the TLS 1.2 population and 0.04% of the whole. The Logjam-era worry about weak DH groups now applies to a population smaller than a mid-sized TLD.

So is “weak encryption” still a thing to worry about?

At the cipher-suite layer, on the measured population, barely. This is the rare census section where the data is genuinely reassuring, and we say so because we spend most editions saying the opposite about email authentication and DNS.

But three qualifiers keep it honest.

First, this table only contains domains where TLS completed at all. The census graded more than 376 million domains; the cipher table covers the 212 million with a completed handshake. Domains with no HTTPS, or with TLS so broken the handshake fails, are the real weak-encryption story, and they are invisible here by construction. We covered that failing cohort in weak and outdated TLS.

Second, a good negotiated suite does not certify a good configuration. A server can hand us TLS_AES_256_GCM_SHA384 and still accept TLS 1.0 from an old client, serve an expired certificate, or skip HSTS. Suite choice is one layer of a stack that mostly still fails elsewhere.

Third, the monoculture cuts both ways. Near-total convergence on AES-GCM means a future practical break in one construction would hit essentially the whole web at once. That is not a prediction — no such break is on the horizon (industry context) — but it is the structural trade the web has made: uniform strength today against concentrated exposure in some hypothetical tomorrow. The 0.68% on ChaCha20 is, in that light, the web’s entire deployed crypto-diversity at the symmetric layer.

How we measured this

• Source: the August 2026 census round (figures as of 16 August 2026, methodology v9), cipher-suite and protocol records from completed TLS handshakes.
• Denominator: 212,025,865 handshakes with a recorded negotiated suite — one per domain. This is the completed cipher-suite handshake population; domains without working TLS are excluded by construction and covered in our TLS-failure reporting instead.
• TLS version figures are from the full graded population: 219,593,564 domains (94.87% of 231,455,163 cert-presenting domains) negotiated TLS 1.3; 11,861,583 (5.1%) negotiated TLS 1.2.
• Negotiation, not capability: every figure reflects what the server negotiated with our scanner — a modern, AES-accelerated client with a standard contemporary offer list. Servers may support additional (including weaker) suites we never saw, because negotiation surfaces one suite per handshake. This census cannot count what a server would do for an old client; it counts what a current client actually gets.
• Single vantage: scans ran from our EU measurement infrastructure. CDNs and load balancers can vary behaviour by region and client; a different vantage or client profile could shift the split at the margins — the ChaCha20 share in particular is client-sensitive and should be read as a server-preference floor.
• One handshake per domain, one round: no retries across days; a transient misconfiguration on scan day is recorded as-is.
• Industry context is labelled. RFC dates (8446, 7465), the mechanics of AEAD, hardware-acceleration effects on ChaCha20 negotiation, and default preference orders in server software are public industry knowledge, not census measurements, and are flagged as such where used.
• Aggregate only. We publish distributions, never the configuration of a named individual domain.
• Data is stored and processed within the EU.

FAQ

What is the most common cipher suite in 2026? TLS_AES_256_GCM_SHA384 — the TLS 1.3 suite pairing AES-256 in GCM mode with SHA-384. It carried 125,535,856 of the 212,025,865 cipher-suite handshakes in our August 2026 census, a 59.21% share. Together with TLS_AES_128_GCM_SHA256 (35.12%), it covers 94.33% of the measured web.

Is AES-128 less secure than AES-256? Not in any way that matters operationally. Both are unbroken, and in GCM mode both provide authenticated encryption; AES-256’s longer key adds theoretical margin and satisfies some compliance mandates (industry context). In our census 61.51% of handshakes used AES-256-GCM and 37.69% used AES-128-GCM, and we would not grade either cohort as weaker than the other on that basis alone.

Is TLS 1.2 still safe to use? A well-configured TLS 1.2 deployment — ECDHE key exchange with AES-GCM or ChaCha20 — remains sound, and that describes most of the 5.1% of handshakes still on 1.2 in our data: its top suites are all ECDHE-GCM. The risk on 1.2 is misconfiguration, which 1.3 makes impossible at this layer. The 251,450 CBC-mode handshakes we saw are all, by definition, TLS 1.2.

Did anyone still use RC4 or 3DES in 2026? Not with us. Across 212,025,865 completed handshakes, RC4, 3DES, export-grade and NULL ciphers each appeared exactly zero times. The weakest thing we observed was AES in CBC mode, at 0.119% of handshakes. One caveat: we count what servers negotiated with a modern client, so a server that would fall back to an old cipher for an old client could still evade this count.

Why is ChaCha20’s share so small? Because share here reflects negotiation with our AES-accelerated scanner. ChaCha20-Poly1305 mainly wins when the client lacks AES hardware — typical of budget mobile devices (industry context) — so servers had little reason to choose it for us. The 1,440,347 handshakes (0.68%) where they chose it anyway indicate server-side preference; real-world phone traffic uses ChaCha20 far more than this figure suggests.

What should I do if my server is still using CBC-mode or TLS 1.2? If your server is among the 251,450 still negotiating CBC-mode cipher suites, or the ~5% still on TLS 1.2, the fix is a configuration update rather than a software change in most cases. Enable TLS 1.3 in your web server (nginx, Apache, IIS, Caddy — all support it in current releases), disable TLS 1.0 and 1.1 explicitly, and restrict your TLS 1.2 cipher list to ECDHE-GCM suites only. Most modern hosting panels have a “modern TLS” toggle that handles this in one step. Check your result with a free TLS scanner — or run your domain through defaults.exposed to see whether your cipher and protocol configuration passes alongside your other DNS and certificate checks.

How does cipher suite health compare to the July 2026 census? Our July 2026 census was the prior measurement round. The direction of travel is consistently positive at the cipher layer: TLS 1.3 adoption has grown steadily since the protocol’s standardisation in 2018, and legacy cipher use has declined in step. The August 2026 figures represent a near-complete erasure of broken ciphers from the measured web. The 0% figures for RC4, 3DES, and export-grade are new lows and reflect a decade of deprecation work landing in the data. CBC mode’s 0.119% share will likely be lower still in our next round.

Why does cipher suite choice matter for compliance teams? Regulatory frameworks including PCI DSS v4.0, NIST SP 800-52 Rev 2, and the UK NCSC TLS profile all specify minimum cipher suite requirements — and most now mandate TLS 1.3 or a restricted TLS 1.2 profile. A server still negotiating CBC-mode suites or offering static-RSA key exchange will fail a PCI DSS 4.0 assessment. The 99.88% AEAD and 99.98% forward-secrecy figures mean the measurable web is broadly compliant at this layer, but the 251,450 CBC-mode and 44,404 static-RSA holdouts are exactly the kind of legacy configuration that shows up as a finding in a penetration test or audit. If your organisation is in scope for any of these frameworks, a cipher audit is a routine check — defaults.exposed can tell you in 30 seconds where your domain stands.

What this means

For IT managers and security teams, the cipher suite picture in 2026 is the rare good-news story in domain security — with one important caveat about what it does and does not cover. The convergence of 94.33% of the encrypted web onto two modern TLS 1.3 cipher suites means that most servers are effectively delivering state-of-the-art symmetric encryption by default, without administrators making any deliberate choice. If your server is running a current web server release with default settings, there is a high probability your cipher configuration is fine. The action item from this data is not to change what is working; it is to identify whether you are in the 0.119% still using CBC mode or the 0.021% still using static-RSA, because those configurations are the ones generating audit findings and compliance failures in 2026.

The forward secrecy number deserves specific attention from security teams managing long-lived services. In 2013, the majority of TLS traffic was static-RSA — meaning a copy of that traffic, recorded today, could be decrypted if the server’s private key was ever compromised in the future. The 99.98% forward-secrecy figure means that risk has been almost entirely retired from current traffic. But almost is not entirely: 44,404 domains are still negotiating static-RSA. If any of those domains handle sensitive data — health records, financial transactions, legal documents — the retroactive decryption risk is real and ongoing. Those servers need an upgrade, not a configuration tweak.

For business owners, the practical takeaway is more straightforward. The cipher layer is the one part of your TLS stack that is likely to be correct if you are running any reasonably modern hosting. Where domain security still fails — as the broader census shows repeatedly — is in email authentication, DNS hardening, and the DNS-level controls like CAA that require explicit action. The cipher findings are a reason for confidence in what the web’s defaults deliver; they are not a reason to stop checking the controls that defaults do not handle.

Data to cite

“Two cipher suites — TLS_AES_256_GCM_SHA384 and TLS_AES_128_GCM_SHA256 — carried 94.33% of all measured TLS handshakes in the August 2026 census of 212 million connections.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“94.87% of certificate-presenting domains negotiated TLS 1.3 in the August 2026 census — 219,593,564 of 231,455,163 domains.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“RC4, 3DES, export-grade and NULL cipher suites appeared zero times across 212,025,865 completed TLS handshakes in August 2026.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“99.98% of TLS handshakes in the August 2026 census used forward-secret key exchange; only 44,404 handshakes (0.021%) used static-RSA with no forward secrecy.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“Legacy CBC-mode cipher suites accounted for just 251,450 handshakes — 0.119% of all measured TLS connections — in the August 2026 census.” — defaults.exposed August 2026 Domain Security Census (432M domains)

“99.88% of TLS handshakes measured in August 2026 used a modern AEAD cipher, leaving just 0.12% on legacy symmetric constructions across a population of 212 million connections.” — defaults.exposed August 2026 Domain Security Census (432M domains)

See where your own domain stands

The cipher layer is the part of domain security the web fixed through good defaults. Most of the other 33 checks in our census still fail through absence, and most of what a failing domain is missing is free and quick to fix — the barrier is almost never cost, it’s that nobody told the owner it mattered. You can check your domain privately and free, and see exactly which checks you pass.

Check your domain free at defaults.exposed — see exactly how your domain scores on TLS version, cipher suite, forward secrecy, and all 34 DNS and encryption checks in the census. Takes 30 seconds. No account needed. Read the flagship census report: The State of Domain Security 2026 →.

Aggregate data only. Data stored and processed in the EU.

How to cite this report

Press / blog: defaults.exposed (2026). Cipher Suites in 2026: What Strong Encryption Really Means. defaults.exposed August 2026 Domain Security Census (432,127,908 domains scanned, asOf 2026-08-16). Retrieved from https://defaults.exposed/en/articles/cipher-suite-census-2026

Academic: defaults.exposed. (2026, August 18). Cipher Suites in 2026: What Strong Encryption Really Means. In defaults.exposed Domain Security Census: August 2026. https://defaults.exposed/en/articles/cipher-suite-census-2026

In-line citation: (defaults.exposed, August 2026 Domain Security Census, n=212,025,865)

About the defaults.exposed August 2026 Census

The defaults.exposed Domain Security Census is a recurring independent measurement of the public domain namespace. The August 2026 edition scanned 432,127,908 domains between 1–16 August 2026 and graded 376,928,781 of them using methodology v9. Scans are conducted from EU infrastructure. No individual domain, registrant, or business is named in any report. All figures are aggregate distributions. Data is stored and processed within the EU.

Methodology: defaults.exposed/en/articles/domain-security-scoring-methodology-v9 Full census report: defaults.exposed/en/articles/the-state-of-domain-security-2026