State of TLS on the public web

TLS configuration is one of the clearer signals of an organization's security maturity. It changes slowly, requires deliberate effort, and exposes choices that operators sometimes forget to revisit. Here is what the most recent scan per host looks like in our dataset.

The encryption layer is largely solved. The application layer is not.

Across the dataset, the average TLS sub-score is 94.0 out of 100, while the average security-header sub-score is 58.8. That gap is the single clearest pattern in our data. A decade of browser pressure, free automated certificates, and hosting-provider defaults has made good TLS nearly automatic. Nothing equivalent happened for HTTP security headers, which still require a deliberate decision by each site operator. The result: most sites in our sample encrypt well and defend the application layer poorly.

About 1 in 5 sites still allow TLS 1.0 or 1.1

952 of 4,393 sites (21.7%) accept connections over TLS 1.0 or TLS 1.1. Both protocols were formally deprecated by RFC 8996 in 2021. Most major browsers refuse them by default, but many libraries, devices, and back-end clients will accept them if the server offers them, which means leaving them enabled keeps the historical attack surface alive without any benefit.

The fix is usually a one-line server-config change.

The TLS 1.3 holdouts

303 sites (6.9%) do not offer TLS 1.3 at all, seven years after its standardization in RFC 8446. TLS 1.2 with strong ciphers is still considered secure, so this is not an emergency. But TLS 1.3 removes every legacy cipher construction that produced the last decade of named attacks, cuts a round trip from the handshake, and encrypts more of the negotiation. For most stacks it arrives with an ordinary software update, which makes a missing TLS 1.3 a reasonable proxy for a server that nobody has touched in years.

Cipher hygiene is mixed

924 sites (21.0%) still negotiate at least one CBC-mode cipher suite. The CBC implementations in TLS 1.0 and 1.1 are vulnerable to BEAST and related padding-oracle attacks, which is why TLS 1.3 dropped CBC entirely. Modern configs default to AEAD ciphers (AES-GCM or ChaCha20-Poly1305).

And for the archaeology file: 2 hosts in the dataset still serve a certificate signed with SHA-1 or MD5, algorithms that browsers stopped trusting for certificates in 2017 and 2012 respectively.

ECDSA has pulled even with RSA

2,175 sites use ECDSA certificates (49.5%) against 2,134 on RSA (48.6%), a statistical dead heat. Twenty years ago this would have been a rounding error in favor of RSA, and the single most common key type in the dataset is now ECDSA P-256. The shift is driven by Let's Encrypt issuing ECDSA chains by default for accounts that request them, faster handshakes on mobile, and smaller signature sizes on every request.

Within the RSA population, 1,802 of 2,134 certificates (84.4%) still use 2048-bit keys. That remains acceptable under current guidance, but the certificates being issued today will outlive some of the margin, and the operational cost of choosing a stronger key at the next renewal is close to zero.

The short-lived certificate has already won

3,473 of 4,309 certificates (80.6%) have a total validity of 95 days or less, the signature of ACME-automated issuance. This is where the whole ecosystem is heading by rule, not just by habit: the CA/Browser Forum's ballot SC-081v3, passed unanimously in April 2025, caps new certificate lifetimes at 200 days as of March 2026, 100 days in March 2027, and 47 days in March 2029.

The practical takeaway is blunt. If certificate renewal at your organization is still a calendar reminder and a manual procedure, the rules of the ecosystem you depend on have already scheduled that procedure's funeral. Automate now, on your own timeline, rather than in 2029 on someone else's.

OCSP stapling never happened, and now it never will

Only 690 of 4,393 sites (15.7%) staple OCSP responses. Adoption stayed low for years because the gain is invisible to the operator: the site loads either way, and the saved round trip goes uncelebrated.

This particular race is now over. Let's Encrypt, the ecosystem's largest CA, shut down its OCSP infrastructure entirely on August 6, 2025, citing the privacy cost of CAs observing individual visitors' browsing, and moved revocation to CRLs. Our scanner still reports stapling as an informational finding on hosts that offer it, but the industry has effectively decided that the future of revocation does not involve a per-visitor OCSP lookup at all.

Where the certificates come from

The five most common issuer common-names in the dataset are all Let's Encrypt intermediates. Let's Encrypt is the dominant CA across our sample by a wide margin. DigiCert, Sectigo, GeoTrust, and Amazon Trust Services round out the long tail.

Sources

• IETF, RFC 8996: Deprecating TLS 1.0 and TLS 1.1 (formal deprecation of both protocols, March 2021).
• IETF, RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3 (TLS 1.3 standardization, August 2018).
• CA/Browser Forum, Ballot SC-081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods (200-day, 100-day, and 47-day certificate lifetime schedule, April 2025).
• Let's Encrypt, Ending OCSP Support in 2025 and OCSP Service Has Reached End of Life (OCSP shutdown rationale and August 6, 2025 end date).
• All percentages and counts: live aggregates from the SecureMonk scan corpus, recomputed on each page load from the most recent scan per hostname.

Methodology

Numbers above use the most recent scan per hostname. The dataset is 4,393 unique hostnames scanned through SecureMonk between 2026-03-07 and 2026-08-26. This is not a random sample of the internet. Sites scanned through SecureMonk skew toward developer-curiosity targets and the homelabs and personal projects of the people running the scans. Treat the absolute percentages as a snapshot of this corner of the web, not a global figure. Sub-scores referenced above are computed by the scoring process described in how the SecureMonk score works.