SSL/TLS in 2026: what's changed and what still breaks

TLS 1.3 has been the current standard since 2018. Eight years later, adoption is still uneven — some industries are at 95%+, others are still running TLS 1.1 in production because of legacy systems nobody wants to touch. Meanwhile, certificate lifespans are getting shorter, QUIC is changing the transport layer, and the first post-quantum cipher suites are starting to appear in production configs.

This is the state of SSL/TLS in 2026: what matters, what's obsolete, and what you need to actually check on your own systems.

TLS 1.3 adoption by industry

These figures come from aggregated scan data across 500,000+ publicly accessible HTTPS endpoints, categorized by industry vertical, Q1 2026:

Developer tooling and SaaS lead adoption — they're almost universally on TLS 1.3. Banking and government lag significantly due to regulatory requirements that move slowly and legacy systems that are expensive to update. If you're building an API that financial institutions will call, you may need to support TLS 1.2 for the foreseeable future.

What changed in TLS 1.3

TLS 1.3 isn't just a version bump — it's a significant redesign:

• Handshake is faster — 1-RTT instead of 2-RTT. For HTTPS connections, this saves one round trip. At 50ms latency, that's 50ms off every new connection.
• Removed weak cipher suites — RSA key exchange, CBC mode ciphers, SHA-1, MD5, and RC4 are all gone. You can't accidentally configure them.
• Forward secrecy is mandatory — all cipher suites use ephemeral key exchange, so recording encrypted traffic today doesn't help decrypt it later even if you get the private key.
• 0-RTT (early data) for session resumption — returning connections can send data in the first packet. Useful for mobile apps with frequent reconnects.

Cipher suites: what to allow in 2026

TLS 1.3 defines exactly five cipher suites and all of them are secure. The choice is straightforward: enable all five, prefer CHACHA20 on mobile clients (better performance without hardware AES acceleration), prefer AES-GCM on server-to-server.

# TLS 1.3 cipher suite preference (nginx)
ssl_conf_command Ciphersuites TLS_AES_128_GCM_SHA256:TLS_AES_256_GCM_SHA384:TLS_CHACHA20_POLY1305_SHA256;

# If you must support TLS 1.2 for legacy clients
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;
ssl_prefer_server_ciphers off;

Certificate lifespans are getting shorter

In 2015, certificates could be valid for 3 years. In 2020, that dropped to 398 days. There's active discussion in the CA/Browser Forum to reduce this further to 90 days — and Apple has already announced it will enforce 90-day maximum validity for certificates trusted by Safari from 2027.

The practical implication: manual certificate management is becoming untenable. If you're not using automated renewal (Let's Encrypt + certbot, or Vercel/Cloudflare handling it automatically), you need to set that up now before 90-day certs become mandatory.

Grade your SSL configuration

Check your configuration against the current best practices. Toggle the items that apply to your setup:

Post-quantum TLS: what to know now

NIST finalized its first post-quantum cryptography standards in 2024 (ML-KEM, formerly CRYSTALS-Kyber). Chrome and Firefox have been running hybrid key exchange (X25519 + Kyber768) in experiments. Cloudflare enabled it by default in 2025.

For most developers, you don't need to do anything today — the TLS implementation in your server (OpenSSL, BoringSSL) will handle this at the library level when the standards are fully adopted. What you should avoid is pinning to specific cipher suites in your code, which would break when post-quantum suites are added.

The one action item: if you're storing encrypted data that must remain confidential for 10+ years, consider implementing post-quantum encryption now. Data encrypted with RSA-2048 today could theoretically be decrypted by a sufficiently powerful quantum computer in the future. Financial records, medical data, or state secrets are the primary concern — standard web traffic is not.