TLS (Transport Layer Security) Explained: Why TLS 1.3 is the New Standard

TLS 1.3 is the current version of the Transport Layer Security protocol, standardized in RFC 8446. It reduces handshake latency by 50%, removes outdated cipher suites, and mandates forward secrecy, making it the strongest and fastest TLS version available. This guide covers how TLS 1.3 works, what changed from TLS 1.2, and why it matters for enterprise network authentication.

The TLS 1.3 protocol secures nearly every encrypted connection on the internet, from HTTPS page loads to VPN tunnels, email delivery over SMTP, and enterprise Wi-Fi authentication through RADIUS. Published by the IETF in August 2018 as RFC 8446, TLS 1.3 replaced TLS 1.2 as the recommended standard after eight years of incremental vulnerability discoveries in the older protocol.

 The upgrade is a significant improvement. TLS 1.3 strips out every cipher suite and key exchange method that contributed to attacks against TLS 1.2, including RSA key transport, CBC-mode ciphers, RC4, SHA-1, and static Diffie-Hellman. What remains is a streamlined protocol with five AEAD cipher suites, mandatory forward secrecy through ephemeral key exchange, and a handshake that completes in a single round trip.

 For IT teams managing enterprise networks, TLS 1.3 has direct operational impact. It underpins EAP-TLS — the strongest 802.1X authentication method — and enables RadSec, which replaces the legacy RADIUS/UDP transport with encrypted TLS tunnels. As certificate lifetimes shrink toward 47 days under the CA/Browser Forum ballot, automated certificate management becomes a requirement rather than a convenience.

What Is TLS and Why Does It Matter?

Transport Layer Security (TLS) is a cryptographic protocol that encrypts data traveling between a client and a server. It operates between the transport layer (TCP) and the application layer, wrapping application data in an encrypted envelope before transmission.

TLS provides three guarantees:

• Encryption: Converts plaintext into ciphertext, preventing eavesdropping on data in transit.
• Authentication: Verifies the identity of the server (and optionally the client) using X.509 digital certificates signed by a trusted Certificate Authority (CA).
• Integrity: Applies message authentication codes to detect tampering or modification during transmission.

The most visible implementation is HTTPS, but TLS secures far more than web traffic. Email (SMTP/TLS), DNS (DoT), file transfers (FTPS), VoIP, and enterprise network authentication (EAP-TLS over RADIUS) all depend on TLS.

From SSL to TLS: A Brief History

Netscape introduced SSL 2.0 in 1995 to encrypt web communications. SSL 3.0 followed in 1996, and the IETF standardized the protocol as TLS 1.0 in 1999 (RFC 2246). Despite the name change, “SSL” persists in everyday usage. Most references to “SSL certificates” or “SSL/TLS” describe the TLS protocol.

 SSL 2.0 and 3.0 are long deprecated. TLS 1.0 and 1.1 were formally deprecated by the IETF in RFC 8996 in 2021, and all major browsers block connections using those versions. TLS 1.2 remains widely deployed, but TLS 1.3 is now the target for new deployments and migrations.

How TLS 1.3 Works: The Handshake

The TLS handshake establishes an encrypted channel between a client and a server before any application data is exchanged. In TLS 1.3, the handshake completes in a single round trip (1-RTT), compared to two round trips in TLS 1.2.

 Here is how a TLS 1.3 handshake proceeds:

1. ClientHello — The client sends its supported TLS version (1.3), a list of supported cipher suites, and a key share (its half of the ephemeral Diffie-Hellman exchange). Unlike TLS 1.2, the client sends its key share in the first message rather than waiting for the server to select parameters. 
2. ServerHello — The server responds with its chosen cipher suite and its own key share. It also sends its digital certificate and a finished message, all encrypted with the handshake traffic key derived from the key exchange.
3. Client Finished — The client verifies the server certificate against its trust store, completes the key exchange, and sends its own finished message. 
4. Encrypted Application Data — Both sides derive symmetric session keys and begin encrypted communication.

 The 1-RTT handshake saves roughly 50-100ms per connection compared to TLS 1.2, depending on network latency. For applications making hundreds of TLS connections per page load, this adds up.

TLS and 0-RTT Session Resumption

When a client reconnects to a server it has previously communicated with, TLS 1.3 supports Zero Round Trip Time (0-RTT) resumption. The client sends encrypted application data alongside the ClientHello, using a pre-shared key (PSK) from the previous session. The server can process this data immediately, eliminating handshake latency entirely for returning connections.

The tradeoff: 0-RTT data is vulnerable to replay attacks because it is sent before the handshake completes. An attacker who captures 0-RTT data could retransmit it. 

For this reason, 0-RTT should be restricted to idempotent operations (like loading a cached page) and disabled for sensitive transactions like payment processing or authentication events. Many enterprise deployments disable 0-RTT entirely or limit it to non-sensitive request types.

TLS 1.3 vs. TLS 1.2: What Changed

TLS 1.3 is not an incremental update to TLS 1.2. The IETF redesigned the protocol from the ground up. Here are the differences that matter:

Comparison: TLS 1.2 vs. TLS 1.3

Feature	TLS 1.2	TLS 1.3 (RFC 8446)
Handshake Latency	2-RTT: Requires two round trips to establish a secure connection.	1-RTT: Standardizes a single round trip; supports 0-RTT for session resumption.
Forward Secrecy	Optional: Vulnerable static RSA key exchange is still allowed.	Mandatory: Only ephemeral key exchanges (DHE/ECDHE) are permitted.
Cipher Suites	Broad (37+): Includes complex and historically weak options.	Streamlined (5): Supports only AEAD cipher suites (e.g., AES-GCM, ChaCha20-Poly1305).
RSA Key Transport	Supported: Static RSA exchange is a common point of failure.	Removed: Replaced by ephemeral key exchange to protect future sessions.
CBC-Mode Ciphers	Supported: Prone to padding oracle attacks (e.g., Lucky13).	Removed: Block ciphers in CBC mode are no longer permitted.
Legacy Algorithms	Supported: Compatibility for RC4, 3DES, MD5, and SHA-1.	Removed: All insecure or outmoded legacy algorithms are prohibited.
Handshake Encryption	Partial: Most of the handshake (including certificates) is in plaintext.	Encrypted: Almost the entire handshake is encrypted after the ServerHello.
Session Resumption	Ticket-based: Relies on Session IDs and Session Tickets.	PSK-based: Uses a unified Pre-Shared Key (PSK) mode for faster reconnects.
Downgrade Protection	Limited: Vulnerable to version-fallback attacks.	Built-in: Uses “sentinel values” in the handshake to prevent malicious downgrades.

Forward Secrecy Is No Longer Optional with TLS 1.3

In TLS 1.2, servers could use RSA key transport, where the client encrypts a pre-master secret with the server’s public key. If that private key is later compromised — through a breach, a court order, or key mismanagement — an attacker can decrypt every previously recorded session.

TLS 1.3 eliminates this risk by requiring ephemeral key exchange (ECDHE or DHE) for every connection. Each session generates a unique set of keys that are discarded after the session ends. Compromising the server’s long-term private key does not expose past traffic. This property — forward secrecy — is mandatory in TLS 1.3.

TLS 1.3 Provides a Smaller Cipher Suite Surface Area

TLS 1.2 supported over 37 cipher suites, many of which had known weaknesses. Misconfigured servers could negotiate CBC-mode ciphers vulnerable to padding oracle attacks (POODLE, Lucky13) or use RC4, which has well-documented biases.

 TLS 1.3 narrows the field to five AEAD (Authenticated Encryption with Associated Data) cipher suites:

• TLS_AES_128_GCM_SHA256
• TLS_AES_256_GCM_SHA384
• TLS_CHACHA20_POLY1305_SHA256
• TLS_AES_128_CCM_SHA256
• TLS_AES_128_CCM_8_SHA256

 AEAD ciphers handle encryption and integrity verification in a single operation, removing the encrypt-then-MAC composition that introduced vulnerabilities in TLS 1.2. The reduced cipher suite list also eliminates misconfiguration risk, so that there is no weak option to accidentally select.

Encrypted Handshake and Privacy Improvements with TLS 1.3

In TLS 1.2, the handshake is largely unencrypted. Server certificates, extensions, and negotiation parameters are visible to anyone observing the connection. This leaks metadata — including the server’s identity — to ISPs, middleboxes, and network monitors.

TLS 1.3 encrypts the handshake after the ServerHello message. The server certificate and subsequent handshake messages travel inside an encrypted envelope, preventing passive observers from identifying which server the client is connecting to.

The protocol also introduced Encrypted ClientHello (ECH), a successor to the earlier Encrypted Server Name Indication (ESNI) proposal. ECH encrypts the entire ClientHello message,  including the Server Name Indication (SNI) field, preventing network observers from determining the destination hostname. As of 2026, ECH is supported in Chrome and Firefox and is deployed on Cloudflare’s network.

TLS 1.3 in Enterprise Network Authentication

TLS 1.3 has implications beyond web servers. For IT teams managing Wi-Fi, VPN, and network access infrastructure, two implementations matter most: EAP-TLS and RadSec.

EAP-TLS with TLS 1.3

EAP-TLS is the strongest authentication method under the IEEE 802.1X framework. It uses mutual TLS authentication — both the client device and the RADIUS server present X.509 certificates and complete a full TLS handshake — before granting network access. No passwords are transmitted or stored.

 TLS 1.3 support for EAP-TLS is defined in RFC 9190 (EAP-TLS 1.3). Key platform support milestones include:

• Windows 11 enabled TLS 1.3 system-wide, including EAP-TLS.
• iOS 17, iPadOS 17, and macOS 14 added EAP-TLS 1.3 support for 802.1X network connections.
• Android 14+ supports TLS 1.3 for EAP-TLS when the supplicant and RADIUS server both advertise it.

EAP-TLS 1.3 introduces one behavioral change that affects enterprise deployments: post-handshake authentication messages are encrypted, meaning the client certificate is no longer visible to passive observers on the network. This improves user privacy but requires RADIUS servers that support the updated message flow.

RadSec: RADIUS Over TLS

Traditional RADIUS traffic runs over UDP (ports 1812/1813) with limited packet-level protection. Shared secrets protect individual attributes, but the overall transport is unencrypted. For RADIUS traffic crossing WAN links, cloud connections, or multi-site Eduroam federations, this is a security gap.

RadSec (RFC 6614) solves this by wrapping RADIUS messages inside a mutually authenticated TLS tunnel over TCP. With TLS 1.3, RadSec connections benefit from the same forward secrecy, reduced cipher suite surface, and handshake speed improvements that protect web traffic.

RadSec is particularly relevant for:

• Multi-site deployments where RADIUS requests travel between campus locations or data centers over the public internet.
• Cloud RADIUS architectures where authentication traffic routes from on-premise access points to a cloud-hosted RADIUS service.
• Eduroam and OpenRoaming federations that rely on inter-institutional RADIUS proxying.

The 47-Day Certificate Lifecycle and TLS 1.3

In April 2025, the CA/Browser Forum voted to progressively shorten TLS certificate lifetimes, as follows:

Effective Date	Max. Certificate Lifetime	DCV (Domain Validation) Reuse Period
Current (Post-March 15, 2026)	200 days	200 days
March 15, 2027	100 days	100 days
March 15, 2029	47 days	10 days

The rationale: shorter certificate lifetimes reduce the window during which a compromised or misissued certificate can be exploited. They also force organizations to adopt automated issuance and renewal workflows — manual certificate management becomes unsustainable at 47-day intervals.

This shift aligns with the security principles built into TLS 1.3. Forward secrecy protects session data even if a certificate is later compromised. Shorter lifetimes reduce the blast radius of any single certificate compromise. Together, they create a defense-in-depth model for TLS-secured communications.

For enterprise networks using EAP-TLS, the impact is direct. Client and server certificates used in 802.1X authentication need automated lifecycle management — issuance, renewal, and revocation — through a managed PKI that integrates with identity providers and MDM platforms.

TLS 1.3 Browser and Platform Support

TLS 1.3 is supported by every major browser and operating system in active use.

Platform Category	Platform / Software	Minimum Version for TLS 1.3 Support
Web Browsers	Google Chrome	Version 70+ (October 2018)
	Mozilla Firefox	Version 63+ (October 2018)
	Apple Safari	Version 12.1+ (March 2019)
	Microsoft Edge	Version 76+ (Chromium-based, July 2019)
Operating Systems	Windows	Windows 10 (Build 1903+) or Windows 11
	macOS	macOS 10.15 (Catalina) or newer
	iOS / iPadOS	iOS 12.2 or newer
	Android	Android 10 or newer
Libraries & Servers	OpenSSL	Version 1.1.1 or higher
	Nginx	Version 1.13.0 or higher
	Apache HTTPD	Version 2.4.36 or higher

Over 70% of web connections now use TLS 1.3. In fact, AWS reports that over 80% of its service API endpoints support TLS 1.3 as of 2024. 

The primary compatibility challenge remains legacy applications, embedded systems, and IoT devices still locked to TLS 1.2 or older. Most organizations run TLS 1.2 and 1.3 in parallel during migration, phasing out 1.2 as client support reaches full coverage.

TLS 1.3 and Compliance

Regulatory frameworks are moving toward TLS 1.3 as the expected standard:

• PCI DSS 4.0 requires TLS 1.2 or higher. TLS 1.3 exceeds the minimum and satisfies forward secrecy requirements without additional configuration.
• HIPAA security rules require encryption in transit. TLS 1.3 meets this with mandatory AEAD ciphers.
• NIST SP 800-52 Rev. 2 recommends TLS 1.3 and explicitly discourages TLS 1.2 configurations that lack forward secrecy.
• FedRAMP aligned environments benefit from TLS 1.3’s built-in protections against downgrade attacks and weak cipher negotiation.

Because TLS 1.3 enforces forward secrecy and removes all weak cipher options by default, organizations gain compliance coverage without custom configuration or cipher suite tuning — a common source of misconfiguration in TLS 1.2 deployments.

How SecureW2 Strengthens TLS-Based Authentication

TLS 1.3 secures the transport layer and protects the privacy of the handshake itself. But for enterprise networks, the certificates used in that TLS handshake — for EAP-TLS authentication, RADIUS server validation, and RadSec tunnels — need a managed PKI and automated lifecycle management.

SecureW2 JoinNow Dynamic PKI provides the certificate infrastructure that makes TLS 1.3 deployments operationally sustainable:

• Automated certificate issuance and renewal through ACME Device Attestation and Dynamic SCEP, integrated with Intune, Jamf, Google Workspace, and Kandji. As certificate lifetimes shrink toward 47 days, automated enrollment eliminates the manual renewal burden.
• Cloud RADIUS with RadSec support, delivering 99.999% uptime for EAP-TLS authentication without on-premise RADIUS servers. Every authentication checks the Identity Provider in real time — if a user is disabled or a device falls out of compliance, access is revoked immediately.
• [JoinNow MultiOS] for BYOD onboarding — end users self-provision certificates on Windows, macOS, iOS, Android, and ChromeOS in a few clicks. No IT intervention. No helpdesk tickets.
• CertIQ ML Anomaly Detection monitors certificate activity across the fleet and flags spoofed, cloned, or anomalous certificates before they are used to authenticate.

The combination of TLS 1.3 on the wire and automated certificate management through a cloud-native PKI gives IT teams the transport security, identity verification, and operational efficiency to support modern network access at scale.

Schedule a demo to see how SecureW2 automates certificate-based authentication for Wi-Fi, VPN, and network access.

---

Frequently Asked Questions

What is TLS 1.3?

TLS 1.3 is the latest version of the Transport Layer Security protocol, published by the IETF as RFC 8446 in August 2018. It provides encrypted, authenticated communication between clients and servers with a faster handshake (1-RTT), mandatory forward secrecy, and a reduced set of AEAD-only cipher suites. TLS 1.3 is used across HTTPS, email, VPN, DNS, and enterprise network authentication (EAP-TLS).

What is the difference between TLS 1.2 and TLS 1.3?

TLS 1.3 removes all legacy cipher suites (RC4, CBC-mode, 3DES, SHA-1), mandates forward secrecy through ephemeral key exchange (ECDHE), and completes the handshake in one round trip instead of two. TLS 1.2 supports over 37 cipher suites — including weak options — and allows RSA key transport, which does not provide forward secrecy. TLS 1.3 also encrypts the handshake after the ServerHello, protecting server certificate metadata from passive observers.

Is TLS 1.3 faster than TLS 1.2?

Yes. The TLS 1.3 handshake requires one round trip (1-RTT) compared to two in TLS 1.2, reducing connection setup time by roughly 50%. For returning connections, TLS 1.3 supports 0-RTT session resumption, where the client sends encrypted application data with the first packet. This improvement is particularly noticeable in high-latency environments and applications that establish many short-lived connections.

Does TLS 1.3 affect enterprise Wi-Fi authentication?

Yes. EAP-TLS — the strongest 802.1X authentication method — runs over a TLS handshake between the client device and the RADIUS server. TLS 1.3 support for EAP-TLS is defined in RFC 9190 and is now supported on Windows 11, iOS 17+, macOS 14+, and Android 14+. TLS 1.3 also enables RadSec, which encrypts RADIUS traffic in a TLS tunnel instead of sending it over unprotected UDP.

How does the 47-day certificate mandate relate to TLS 1.3?

The CA/Browser Forum voted in April 2025 to reduce maximum TLS certificate lifetimes to 47 days by March 2029 (with interim steps of 200 days in 2026 and 100 days in 2027). 

Shorter lifetimes limit the exposure window for compromised certificates, complementing TLS 1.3's forward secrecy, which protects past sessions even if a current certificate is compromised. Organizations running EAP-TLS or HTTPS with TLS 1.3 need automated certificate lifecycle management to sustain this cadence.