Overview
EAP-TLS (Extensible Authentication Protocol–Transport Layer Security) is an authentication method that uses digital certificates instead of passwords. The client and the server each present a certificate and verify the other, so authentication is mutual. The exchange runs inside 802.1X and is carried to the authentication server over RADIUS. RFC 5216 defines it.
Operators and enterprises turn to EAP TLS when passwords are no longer acceptable. What makes them hesitate is certificate lifecycle management. That means getting a certificate onto every device, then renewing and revoking it for as long as the device is on the network.
How EAP-TLS authentication works
The EAP-TLS authentication flow is a full TLS handshake between the device and the RADIUS (Remote Authentication Dial-In User Service) server. The switch or access point in between relays it without terminating it and keeps the port closed until both certificates check out. EAP itself is defined in RFC 3748, and the port-based framework around it in IEEE 802.1X-2020, covered in 802.1X port-based access control.
- The supplicant (the device) sends an EAP over LAN (EAPOL) Start message to the authenticator (the access point or switch).
- The authenticator requests an identity, and the device replies with an outer identity it can anonymize (for example, anonymous@realm).
- That reply travels to the RADIUS server inside a RADIUS Access-Request.
- The RADIUS server starts EAP-TLS, and the device answers with a TLS ClientHello.
- The server sends its certificate and a certificate request, and the device checks the server’s chain and name.
- The device returns its own certificate and signs the handshake with its private key; the server checks that signature, then the certificate’s validity and revocation status.
- Once the handshake finishes, the RADIUS server sends Access-Accept with EAP-Success and keying material, and the authenticator opens the port.
In practice, steps 4 to 6 take several RADIUS Access-Challenge round trips. A certificate chain rarely fits in one RADIUS packet, which tops out at 4,096 octets, so RFC 5216 fragments it.
TLS 1.3, defined for EAP-TLS in RFC 9190, encrypts the client certificate, so the device’s real identity is never disclosed. Under TLS 1.2, the certificate is sent unencrypted unless the optional privacy mode is used. RFC 9190 also adds a protected one-byte success message before EAP-Success.
What each side proves
In EAP-TLS, mutual authentication means two separate proofs, and neither relies on a password.
The server’s proof is its certificate, which must chain to a certificate authority (CA) the device trusts and match the server name the device expects. That stops a rogue or evil-twin access point from impersonating the network. The device’s proof is a signature over the handshake, made with its private key. Nothing reusable crosses the network, so there is nothing to phish, replay or crack offline.
RFC 5216 calls this “certificate-based mutual authentication and key derivation.” On a live network it only holds if supplicants actually validate the server certificate and name. Skip that check and half the proof is gone.
How RADIUS carries EAP-TLS
The access point or switch relays EAP inside RADIUS without reading the certificates. The RADIUS server terminates the TLS session and makes the access decision.
RFC 3579 defines the mechanics. Each EAP packet travels in an EAP-Message attribute, and the RADIUS packet is protected with a Message-Authenticator attribute. Authentication traffic uses User Datagram Protocol (UDP) port 1812, as set out in RFC 2865. For the transport itself, see how the RADIUS protocol works.
What the RADIUS server actually does
During an EAP-TLS exchange, the RADIUS server:
- validates the client certificate chain and validity dates
- checks revocation status through a certificate revocation list (CRL) or the Online Certificate Status Protocol (OCSP)
- maps the certificate identity to a subscriber or device record
- applies authorization policy such as virtual LAN (VLAN), quality of service (QoS) and Session-Timeout
- returns the keying material the access point uses to encrypt the session, then records the accounting start the access point sends
Classic RADIUS hides only a few attributes, such as passwords and session keys, so RADIUS protocol encryption is a fair concern. The EAP-TLS credential avoids it by staying inside its own TLS session, however the RADIUS hop is secured. Hardening that hop is covered in RADIUS security and shared secrets and RADIUS over TLS.
EAP-TLS vs PEAP and EAP-TTLS
EAP-TLS is more secure than Protected EAP (PEAP) and EAP Tunneled TLS (EAP-TTLS) because it takes the password out of the picture. PEAP and EAP-TTLS remain in use for a simpler reason: they only need a server certificate.
| Method | Client proves identity with | Server proves identity with | Mutual certificate authentication | Main operational cost |
| EAP-TLS | Certificate and private key | Certificate | Yes | Issuing and renewing a certificate per device |
| PEAP (MSCHAPv2 inside) | Password | Certificate | No | Password risk; relies on clients validating the server |
| EAP-TTLS | Password or another inner method | Certificate | No | Same password risk; flexible for legacy back ends |
Why teams still run PEAP
PEAP’s appeal is operational. It reuses the directory passwords people already have, needs no client public key infrastructure (PKI), and gets personal devices online with a username and password.
It also inherits the password’s weaknesses. A rogue access point can harvest credentials from clients that skip server validation, and MSCHAPv2 is no longer considered strong.
For most teams, the choice rests less on security than on whether they can run a PKI.
Certificates in practice
Every EAP-TLS deployment depends on a client certificate on each device, a server certificate on the RADIUS server and a CA both sides trust. All three expire, which is why certificate lifecycle, not the handshake, decides whether a deployment holds up. The EAP-TLS certificate requirements are:
- a client certificate per device or user, with the client-authentication extended key usage (EKU), from a private CA
- a RADIUS server certificate that devices can validate
- the CA trust anchors installed on every device
- private keys stored securely, ideally in hardware
- revocation data the RADIUS server can reach at authentication time
Since June 15, 2026, browser root-program rules require new public TLS certificates to carry server authentication only. EAP-TLS client certificates therefore come from a private CA.
1. Client certificate enrollment
Managed devices receive certificates through device management or the Simple Certificate Enrollment Protocol (SCEP). Unmanaged devices need network access to get the certificate that grants network access, so operators use an onboarding network or short-lived provisioning credentials.
2. Renewal
Renewal has to happen before expiry, and at scale it only works when automated. Devices enrolled in the same campaign often expire on the same day. Staggering their renewal and flagging the cohort early keeps one expiry date from turning into a mass outage.
3. Revocation
A lost device must stop authenticating at once, so the RADIUS server checks a CRL or OCSP. CRLs can go stale between downloads. OCSP is current, but it makes the responder a dependency of every login. With TLS 1.3, RFC 9190 makes revocation checking mandatory.
4. Certificate expiry mid-session
Validity is checked when the handshake runs. A session that began before expiry usually carries on until the next full authentication. That can be a Session-Timeout re-authentication, a roam without cached keys or a simple reconnect, and it is where the failure appears. The subscriber sees a connection that silently won’t come up, and the operator sees a spike in rejects. For tracing those rejects, see the 802.1X troubleshooting guide.
The table below works as a short RADIUS best practices checklist for certificate-based access. It shows who owns each stage and what the Authentication, Authorization, and Accounting (AAA) layer must do.
| Stage | What happens | Typical owner | What the AAA layer must do | If it is missed |
| Enrollment | Device receives its certificate and trust anchors | PKI and device management | Allow limited onboarding sessions | Device never connects |
| Renewal | New certificate issued before expiry | PKI automation | Accept old and new certificates during overlap | Mass rejects on expiry day |
| Revocation | Certificate withdrawn after loss or compromise | Security and PKI | Check CRL or OCSP on every authentication | Lost device keeps access |
| Expiry | Validity period ends | PKI, monitored by the AAA team | Reject cleanly and flag expiring cohorts early | Silent connection failures |
| Server certificate rotation | RADIUS server certificate replaced | AAA team | Distribute the new chain before switching | Devices refuse the new server |
Running a certificate for every device is an operations problem as much as a protocol choice. Get a technical consultation on certificate-based authentication at scale.
EAP-TLS at carrier scale
Carrier Wi-Fi authentication with EAP TLS works at scale once certificate distribution is automated. Devices with a Subscriber Identity Module (SIM) usually authenticate with EAP-SIM or EAP-AKA. Certificates mostly cover devices without one, such as laptops, tablets and Internet of Things (IoT) devices.
Roaming federations already do this. The Wireless Broadband Alliance (WBA) OpenRoaming framework accepts any Passpoint EAP method, EAP-TLS included. Its members exchange RADIUS over RadSec, secured with mutual TLS under a shared WBA PKI.
Where it breaks
Some problems only show up at carrier volume:
- Revocation at peak load: every authentication waits on a CRL or OCSP check, so the responder has to scale with the busiest hour.
- Cross-operator troubleshooting: a reject in a visited network has to be traceable back to its cause.
The Alepo AAA Server is a carrier-grade AAA server that runs EAP-TLS alongside EAP-SIM, EAP-AKA, PEAP and EAP-TTLS on one platform. Each authenticated identity is checked against a subscriber profile held on the platform or in an external directory or subscriber database. Policy applies per session and can change mid-session through RADIUS Change of Authorization (CoA). When a reject does occur, the platform’s AI Agent Assist decodes EAP failure traces and reject codes in plain language, which shortens diagnosis.
Choosing EAP-TLS for your network
For devices without a SIM, EAP-TLS gives the strongest identity proof of the common EAP methods, at the cost of a certificate for every device. To see where it sits among the other access protocols, read the AAA protocols reference. Book a demo our team of experts will demonstrate.
Frequently asked questions
Q1. Is EAP-TLS more secure than PEAP?
Yes. EAP-TLS authenticates both client and server with certificates, so there is no shared secret for an attacker to steal. The cost is operational: you need a PKI and a reliable way to issue, renew and revoke a certificate for every device.
Q2. Does EAP-TLS require a client certificate?
Yes. In standard EAP-TLS deployments, every device presents its own certificate and proves it holds the matching private key. That client certificate is what separates EAP-TLS from PEAP and EAP-TTLS, which authenticate the client with a password inside a TLS tunnel.
Q3. What happens when an EAP-TLS certificate expires?
The device’s next full authentication fails. An active session usually keeps running until a re-authentication, roam or reconnect forces a new handshake. After that, the subscriber can’t connect until the certificate is renewed. Automated renewal well before expiry avoids this.
Q4. Can EAP-TLS work without a PKI?
Not in any practical sense. Every client certificate needs an issuer the RADIUS server trusts. The minimum viable PKI is a root CA, an issuing CA and a revocation method such as CRL or OCSP. It also needs an enrollment path to devices and a RADIUS server certificate.
Q5. What RFC defines EAP-TLS?
RFC 5216 defines EAP-TLS, and RFC 3748 defines EAP itself. RFC 9190 updates EAP-TLS for TLS 1.3, while RFC 5216 still covers older TLS versions. RADIUS, which carries the exchange to the server, is RFC 2865, and the surrounding access framework is IEEE 802.1X-2020.
Q6. How does EAP-TLS relate to 802.1X?
In an 802.1X EAP-TLS deployment, 802.1X is the framework and EAP-TLS is the method that runs inside it. 802.1X controls whether a port or wireless association opens. EAP-TLS decides whether the device should be trusted. For the framework itself, see how 802.1X authentication works.
Q7. Is EAP-TLS practical for large subscriber bases?
Yes, if certificate handling is automated. Without automation it gets painful quickly. Carrier roaming federations already run EAP-TLS at scale. The work is in enrollment, renewal before expiry, revocation checks at peak load and spotting expiring cohorts before they cause mass authentication failures.
