How EAP-TLS Works (And Why Cert Expiry Kills WiFi Access)
The Problem Nobody Sees Coming
It’s Monday morning. 200 employees walk into the office, open their laptops, and… nothing. No WiFi. No network. No work.
The helpdesk gets flooded. The network team checks access points—all green. They check the RADIUS server—running fine. They check DHCP, DNS, VLAN configs. Everything looks healthy.
Four hours later, someone checks the machine certificates. Expired Friday at midnight.
This is what happens when enterprise WiFi authentication depends on certificates that nobody is tracking.
EAP-TLS Failure Impact by Scenario
Users affected and mean time to resolve for common cert failures
🔴 A single expired RADIUS server certificate can disconnect every wireless client in the organization simultaneously.
How EAP-TLS Authentication Actually Works
Enterprise WiFi (802.1X) with EAP-TLS is the gold standard for network access control. No passwords to phish. No credentials to steal. Machine certificates prove device identity cryptographically.
Here’s the full authentication flow:
The Four-Party Handshake
| Step | Component | Role | Action |
|---|---|---|---|
| 1 | Supplicant | Client device | Presents machine certificate |
| 2 | Authenticator | WiFi Access Point | Relays EAP frames to RADIUS |
| 3 | Authentication Server | RADIUS/NPS | Validates certificate chain |
| 4 | Certificate Authority | AD CS | Issued the certificate (offline role) |
Step-by-Step Flow
- Association: Device associates with SSID (no authentication yet)
- EAP Identity: RADIUS requests identity from supplicant
- TLS Handshake Begins: Server sends its certificate + requests client certificate
- Client Certificate Presented: Supplicant sends machine certificate from local store
- Chain Validation: RADIUS validates:
- Certificate not expired
- Certificate not revoked (CRL/OCSP check)
- Certificate chains to trusted root
- Certificate has correct EKU (Client Authentication)
- Certificate subject matches expected naming
- Access Granted: RADIUS sends Access-Accept → AP opens port → Device gets network access
Where Certificate Expiry Breaks the Chain
The validation at Step 5 is binary. If the certificate fails ANY check, authentication is denied. There’s no “grace period.” There’s no “warn and allow.”
Failure Scenarios
| Failure Point | What Happens | User Experience |
|---|---|---|
| Client cert expired | RADIUS rejects immediately | ”Can’t connect to network” |
| RADIUS cert expired | Supplicant rejects server | ”Certificate error” popup |
| Intermediate CA expired | Chain validation fails | Silent authentication failure |
| Root CA expired | Everything breaks | Complete WiFi outage |
| CRL unreachable | Revocation check fails | Intermittent connectivity |
The Cascade Effect
When machine certificates expire:
- Devices can’t authenticate to WiFi → No network access
- No network access → Can’t reach AD to get Group Policy
- Can’t reach AD → Auto-enrollment can’t request new certificate
- Can’t get new certificate → Device stays offline
This is the deadlock. The device needs network access to renew the certificate, but needs a valid certificate to get network access.
Why Auto-Enrollment Doesn’t Save You
Microsoft’s certificate auto-enrollment is designed to renew certificates before expiry. In theory, it requests a new certificate when the current one reaches 80% of its lifetime.
In practice, auto-enrollment fails when:
- Device was off during the renewal window
- Network was unavailable when renewal was attempted
- CA was unreachable due to firewall or DNS changes
- Template permissions changed blocking the renewal
- Machine account was moved to an OU without enrollment rights
For laptops that work remotely or are only in-office occasionally, the renewal window is a gamble.
The Real-World Impact
| Metric | Impact |
|---|---|
| Time to detect | 30 min - 4 hours (after users report) |
| Time to diagnose | 1 - 6 hours (often misattributed to network issues) |
| Time to remediate | 2 - 8 hours (manual re-enrollment at scale) |
| Affected users | All devices with expired certs |
| Business cost | $500-$2,000 per hour of workforce downtime |
What Should Be in Place
- Certificate inventory — Know every machine certificate, its expiry date, and which device holds it
- Expiry monitoring — Alert at 30, 14, and 7 days before expiry
- Renewal verification — Confirm auto-enrollment actually completed (issued ≠ deployed)
- Fallback authentication — PEAP-MSCHAPv2 as temporary fallback during remediation
- Offline renewal plan — Process for devices that can’t reach the CA
The Bottom Line
EAP-TLS is the most secure WiFi authentication method available. But security that depends on certificates requires certificate lifecycle management. Without visibility into what’s expiring and when, you’re one missed renewal away from a company-wide WiFi outage.
The fix isn’t abandoning EAP-TLS. It’s knowing what certificates you have and when they expire—before your users tell you.
Need visibility into your certificate landscape? QCecuring helps IT teams track, monitor, and manage internal certificates before they cause outages. Get in touch →