Managing Digital Certificates for EAP-TLS WiFi Authentication

Speak in British English with a confident, authoritative, and conversational tone - like a senior consultant briefing a client. Measured pace, clear diction, warm but direct. Occasional natural pauses for emphasis: Welcome to the Purple technical briefing series. Today we are talking about EAP-TLS certificate management - specifically, how to run a certificate-based WiFi authentication programme at scale without it becoming a full-time operational burden. [medium pause] If you are responsible for corporate or staff WiFi across multiple sites - whether that is a hotel group, a retail estate, a university campus, or a public-sector estate - this briefing is for you. We are going to cover the full certificate lifecycle: from setting up your CA hierarchy, through automated deployment via SCEP and MDM, to renewal and revocation. And we will talk about where things go wrong, because they do go wrong, and how to avoid the most common traps. [medium pause] Let us start with the fundamentals. EAP-TLS - that is Extensible Authentication Protocol with Transport Layer Security - is the gold standard for 802.1X WiFi authentication. Unlike PEAP, which relies on a username and password, EAP-TLS uses mutual certificate-based authentication. The device proves its identity with a client certificate. The RADIUS server proves its identity with a server certificate. Both sides verify the other. No password to phish. No credential to steal. That is why PCI DSS 4.0 and the NCSC's zero-trust guidance both point towards certificate-based authentication for staff networks. [medium pause] Now, the architecture. You need three things to make EAP-TLS work. First, a Public Key Infrastructure - your CA hierarchy. Second, a mechanism to get certificates onto devices - that is SCEP or your MDM platform. Third, a RADIUS server that trusts your CA and can validate client certificates in real time. [medium pause] The CA hierarchy is where most organisations get into trouble early. The correct pattern is a three-tier model. You have a Root CA at the top - this should be offline, air-gapped, and only brought online to sign your Intermediate CA certificate. The Intermediate CA - sometimes called the Issuing CA - is the one that actually signs day-to-day certificates. It is online, but its private key is well protected. Below that, you issue two types of certificate: server certificates for your RADIUS infrastructure, and client certificates for your devices and users. [medium pause] Why does this matter? Because if your Root CA is compromised, you have to rebuild your entire PKI from scratch and re-enrol every device. Keeping it offline eliminates that risk. The Intermediate CA can be replaced without touching the Root. That is the operational resilience argument for the three-tier model. [medium pause] Let us talk about certificate validity periods. There has been a significant industry shift here. Apple, Google, and Mozilla have all moved to enforce shorter maximum certificate lifetimes. For TLS server certificates, the maximum is now 398 days. For client certificates in enterprise WiFi, you have more flexibility - one to two years is common - but the trend is towards shorter lifetimes and automated renewal rather than long-lived certificates managed manually. The reason is simple: a shorter lifetime limits the window of exposure if a certificate is compromised. [medium pause] This brings us to automation. Manual certificate management does not scale. If you have 500 devices, you can just about manage renewals by hand. If you have 5,000 devices across 50 sites, you cannot. You need SCEP - the Simple Certificate Enrolment Protocol - or its modern successor, EST. SCEP integrates directly with MDM platforms including Microsoft Intune, Jamf Pro, and VMware Workspace ONE. The MDM pushes a SCEP configuration profile to the device. The device generates a key pair, sends a certificate signing request to your SCEP server, and receives a signed certificate back - all without any user interaction. [medium pause] For Windows devices in an Active Directory environment, you have an alternative: Group Policy-driven auto-enrolment via Active Directory Certificate Services. The device authenticates to the domain, the CA issues a certificate automatically, and the certificate is renewed before expiry without any manual intervention. This is the most seamless path for Windows-heavy estates. [medium pause] Now, revocation. This is the piece that organisations most often underinvest in, and it is the piece that matters most when something goes wrong. If a device is lost, stolen, or an employee leaves, you need to revoke their certificate immediately. There are two mechanisms: CRL - Certificate Revocation Lists - and OCSP - Online Certificate Status Protocol. [medium pause] CRL is the older mechanism. Your CA publishes a list of revoked certificate serial numbers at a known URL. The RADIUS server downloads this list periodically and checks against it. The problem with CRL is latency - if your CRL has a 24-hour validity period, a revoked certificate can still authenticate for up to 24 hours after revocation. [medium pause] OCSP is the real-time alternative. The RADIUS server sends a query to the OCSP responder for each authentication attempt, and gets a live good or revoked response. The trade-off is that your OCSP responder becomes a critical dependency - if it is unavailable, you need to decide whether to fail open or fail closed. For high-security environments, fail closed is the right answer. For operational environments where availability matters, you may configure a short OCSP grace period. [medium pause] Let me give you two concrete scenarios to make this real. [medium pause] First: a 150-property hotel group. They were running PEAP with a shared password for staff WiFi. Password rotation was quarterly, which meant a two-week window every quarter where staff were locked out or using the old password. They moved to EAP-TLS using Microsoft Intune for certificate deployment. SCEP profiles pushed to all Windows and iOS devices. Active Directory Certificate Services as the CA. The result: zero password rotation events, certificate renewal handled automatically 30 days before expiry, and when a member of staff left, their certificate was revoked in the MDM within minutes of their account being disabled in Microsoft Entra ID. The IT team estimated they saved approximately 40 hours per quarter in password reset and helpdesk tickets. [medium pause] Second: a multi-site retail chain with 3,000 staff devices across 200 stores. The challenge here was device diversity - a mix of Windows laptops, Android handhelds, and iOS devices. They used Jamf Pro for Apple devices and Microsoft Intune for Windows and Android, both pointing at the same SCEP server backed by a Microsoft ADCS Intermediate CA. The WiFi infrastructure was Cisco Meraki, with RADIUS authentication handled by a cloud-hosted RADIUS service integrated with Purple. The key design decision was to issue certificates with a 12-month validity and configure automatic renewal at 60 days before expiry. This gave a comfortable renewal window without creating operational overhead. [medium pause] Now, the pitfalls. There are four that I see consistently. [medium pause] First: not testing revocation. Organisations set up their PKI, deploy certificates, and never actually test whether revocation works end-to-end. Test it. Revoke a test certificate, confirm the RADIUS server picks up the revocation within your expected window, and confirm the device is denied access. [medium pause] Second: expiry cliff edges. If you issue all your certificates at the same time with the same validity period, they all expire at the same time. Stagger your issuance, or at minimum stagger your renewal triggers. A 10% renewal failure rate across 5,000 devices simultaneously is a significant incident. [medium pause] Third: not distributing the Root CA certificate to all devices before deploying EAP-TLS. If the device does not trust your Root CA, it will reject the RADIUS server's certificate and authentication will fail. This sounds obvious, but it catches organisations out when they have BYOD devices or contractor laptops that are not enrolled in the MDM. [medium pause] Fourth: OCSP responder availability. If your OCSP responder goes down and your RADIUS server is configured to fail closed on OCSP errors, your entire WiFi estate stops working. Build redundancy into your OCSP infrastructure, or configure a short grace period with appropriate monitoring. [medium pause] Right, rapid-fire questions. [medium pause] Can I use a public CA for EAP-TLS client certificates? Technically yes, but in practice no. Public CAs will not issue client certificates for arbitrary devices. You need your own CA for client certificates. For the RADIUS server certificate, a public CA is fine and simplifies trust distribution. [medium pause] What about BYOD? BYOD is the hard case. You cannot push certificates to unmanaged devices via MDM. Options include a network access control portal that issues short-lived certificates after user authentication, or simply keeping BYOD on a separate SSID with a different authentication method. [medium pause] How does this interact with WPA3? WPA3-Enterprise mandates 192-bit security mode for sensitive environments, which requires specific cipher suites. EAP-TLS is fully compatible with WPA3-Enterprise and is in fact the recommended authentication method. [medium pause] To summarise. EAP-TLS certificate management is not simple, but it is manageable if you get the architecture right from the start. Three-tier CA hierarchy. Automated enrolment via SCEP or MDM. Short certificate lifetimes with automated renewal. Real-time revocation via OCSP. Test everything, especially revocation. And integrate your certificate lifecycle with your identity provider - Microsoft Entra ID, Okta, or Google Workspace - so that certificate revocation is triggered automatically when an account is deprovisioned. [medium pause] If you are running Purple-linked RADIUS servers, the integration points are your SCEP server URL, your RADIUS server certificate, and your CRL or OCSP endpoint. Purple's hardware-agnostic architecture means this works across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, and the rest of the canonical hardware list - you are not locked into a single vendor's PKI tooling. [medium pause] Next steps: audit your current certificate inventory. If you do not know how many certificates you have, when they expire, and who issued them, that is the first thing to fix. From there, the path to full automation is well-defined. Thanks for listening.