What Is PKI? How Public Key Infrastructure Powers WiFi Security

Welcome to the Purple Technical Briefing. I'm your host, and today we are tackling a fundamental component of enterprise network security: Public Key Infrastructure, or PKI, and specifically how it powers secure WiFi through certificate-based authentication. If you are an IT manager, a network architect, or a venue operations director managing connectivity across hotels, retail chains, or large public venues, you know that the traditional pre-shared key — the password taped to the wall or shared on a whiteboard — is dead. It is a massive security liability. It provides no individual accountability, and rotating it is an operational nightmare. So, what is the alternative? The answer is IEEE 802.1X paired with PKI. Let's start with the basics. What is PKI? Public Key Infrastructure is the comprehensive framework of hardware, software, policies, and procedures required to create, manage, distribute, use, store, and revoke digital certificates. In plain English, it is the system that allows you to issue digital passports to every device and user on your network. Instead of a user typing in a password, their device presents a digital certificate — a cryptographic document formatted to the X.509 standard. This certificate binds a public key to an identity, like a device's MAC address or an employee's email address. The central authority in this system is the Certificate Authority, or CA. Think of the CA as the government issuing that passport. If your network trusts the CA, it trusts the certificates issued by that CA. Now, how does this apply to WiFi? This brings us to 802.1X and EAP-TLS. 802.1X is the IEEE standard for port-based network access control. It essentially acts as a bouncer at the door of your network — the access point. It blocks all traffic until the device proves who it is. EAP-TLS, which stands for Extensible Authentication Protocol with Transport Layer Security, is the gold standard method for this proof. It requires mutual authentication. This is absolutely critical. In EAP-TLS, the client device presents its certificate to the RADIUS server to say, I am a valid corporate device. But then, the RADIUS server presents its own certificate back to the client to say, And I am the legitimate corporate network, not a rogue access point. This mutual trust prevents what security professionals call Evil Twin attacks, where a bad actor sets up a rogue access point with the same network name to steal credentials. Because the bad actor doesn't have a valid certificate from your internal Certificate Authority, the client device will refuse to connect. Full stop. Let's talk about the components in more detail. The Certificate Authority hierarchy typically has three tiers. At the top, you have the Root CA. This is the ultimate source of trust. In a well-designed deployment, the Root CA is kept completely offline — physically secured, air-gapped. It only ever signs Intermediate CA certificates. Below that, you have one or more Intermediate CAs. These are online and handle the day-to-day signing of Issuing CA certificates. The separation of the Root CA from the Intermediate CAs means that even if an Intermediate CA is compromised, you can revoke it without destroying your entire PKI. At the bottom of the hierarchy, the Issuing CA is what actually signs the end-entity certificates — the ones that go onto your laptops, tablets, and smartphones. Each certificate contains several key fields: the Subject, which identifies the certificate holder; the Issuer, which identifies the CA that signed it; the Public Key; the Validity Period, defining the start and end dates; and the Digital Signature of the issuing CA. Now, let's walk through a real-world implementation scenario. Imagine a retail chain with five hundred stores. They're currently running WPA2-PSK — a single shared password across all locations. The IT team knows this is a problem. Staff turnover means the password gets shared externally. There's no way to audit who is on the network. And if one store's password is compromised, the attacker has access to the entire estate. The migration path to PKI looks like this. First, select a cloud-managed PKI provider and integrate it with the existing Mobile Device Management solution. Second, configure SCEP — the Simple Certificate Enrollment Protocol — to automatically push unique, device-bound certificates to every corporate device. Third, deploy a cloud RADIUS service and configure it to validate certificates against the PKI. Fourth, reconfigure the wireless controllers at each store to enforce 802.1X authentication on the corporate SSID. Finally, retire the PSK network. The result? Every device has a unique cryptographic identity. If a tablet is stolen, its certificate is revoked in the PKI, and within minutes, that device can no longer access any network in any store. No password rotation. No downtime. No operational chaos. Now, let's talk about some common pitfalls, because this is where many deployments run into trouble. The first and most common issue is poor revocation management. Issuing certificates is the easy part. Revoking them reliably is where teams often fall short. Your RADIUS server must be configured to actively check the Certificate Revocation List, or CRL, or use the Online Certificate Status Protocol, known as OCSP, on every single authentication attempt. Not just once a day. Every time. If a device is compromised and its certificate is revoked, but your RADIUS server is only checking the CRL once every twenty-four hours, you have a twenty-four-hour window of exposure. The second pitfall is time synchronisation. This catches teams out more often than you'd expect. Digital certificates are extremely sensitive to time. If a client device's clock is more than a few minutes off — due to an NTP failure, for example — the certificate validation will fail. The certificate will appear to be either not yet valid or already expired. Ensure robust NTP configuration across your entire network infrastructure. The third pitfall is trust chain distribution. For EAP-TLS mutual authentication to work, the client device must trust the Root CA that issued the RADIUS server's certificate. On Windows devices joined to Active Directory, this is typically handled automatically via Group Policy. But for Android devices, iOS devices, or BYOD equipment, you must push the Root CA certificate via MDM. If you miss this step, those devices will reject the RADIUS server's certificate and fail to connect. Let's move on to the rapid-fire questions I get asked most often. Can I use EAP-TLS for guest WiFi? Technically yes, but practically no. Guest devices are unmanaged, so you cannot push certificates to them. Guest networks should use a captive portal with social login or email authentication, while the corporate SSID uses EAP-TLS. Platforms like Purple handle this separation cleanly. What is OpenRoaming and how does PKI relate to it? OpenRoaming is a federated WiFi standard that allows users to seamlessly and securely connect to participating networks using a pre-provisioned profile — essentially a certificate-based credential. Purple acts as a free identity provider for OpenRoaming under the Connect licence, meaning users provisioned through Purple can connect to any OpenRoaming-enabled venue without a captive portal or password. How often should certificates be renewed? Best practice is to set certificate lifetimes to one year for end-entity certificates and automate renewal at the sixty percent mark of the validity period. This gives you a substantial buffer if the renewal process fails. To summarise today's briefing. PKI replaces vulnerable shared secrets with cryptographic identity. Every device gets a unique, unforgeable digital certificate. EAP-TLS provides mutual authentication, ensuring the device trusts the network and the network trusts the device. Automated provisioning via MDM is non-negotiable for scalable deployments. Robust revocation checking is the difference between a secure deployment and a false sense of security. And for public-facing venues, embracing PKI-backed standards like OpenRoaming delivers a seamless, secure guest experience at scale. If you are planning a migration to certificate-based WiFi, the full technical reference guide is available on the Purple website, complete with architecture diagrams, deployment checklists, and worked examples for hospitality, retail, and healthcare environments. Thank you for joining this briefing. Until next time.