Enterprise SCEP Setup Guide: Certificate-Based WiFi Authentication for Higher Education and Large Networks

Enterprise SCEP Setup Guide: Certificate-Based WiFi Authentication for Higher Education and Large Networks A Purple Technical Briefing - Podcast Script (approximately 10 minutes) --- INTRODUCTION AND CONTEXT - approximately 1 minute Welcome to the Purple Technical Briefing series. I am talking today about something that lands in a lot of IT inboxes but rarely gets a straight answer: how do you actually deploy certificate-based WiFi authentication at scale, using SCEP, across a large network - whether that is a university campus, a multi-site hotel group, or a large public sector estate? We are going to cover the full picture. What SCEP actually does, how it fits into an 802.1X architecture, the deployment sequence that most teams get wrong, two real-world implementation scenarios, and the pitfalls that will cost you a weekend of your life if you do not plan for them. This is a consultant briefing, not a tutorial. I am assuming you know what a RADIUS server is and you have probably already decided you need to move away from pre-shared keys. What you need now is the implementation map. Let us get into it. --- TECHNICAL DEEP-DIVE - approximately 5 minutes So, first principles. SCEP stands for Simple Certificate Enrollment Protocol. It was formalized by the IETF as RFC 8894 in 2020, though it had been in widespread enterprise use for well over a decade before that. Its job is straightforward: automate the process of getting a digital certificate onto a managed device without requiring a human to touch each machine. In the context of WiFi authentication, SCEP is the delivery mechanism. The actual authentication protocol you are targeting is EAP-TLS - Extensible Authentication Protocol with Transport Layer Security - which sits inside the 802.1X framework. EAP-TLS is widely regarded as the most secure authentication method for enterprise wireless networks because it requires both the client device and the RADIUS server to present valid certificates. Neither side trusts the other without cryptographic proof. That mutual authentication is what protects you against evil twin attacks - where an attacker spins up a rogue access point to harvest credentials. Here is how the full chain works. A managed device - a student laptop, a staff cell phone, a hotel point-of-sale terminal - needs to join the corporate wireless network. Your MDM platform, which might be Microsoft Intune or Jamf, pushes a SCEP payload to that device. The payload contains two things: the SCEP URL, which points to your NDES server or cloud SCEP gateway, and a challenge password or shared secret. The device generates its own public and private key pair locally. This is critical. The private key never leaves the device. It is generated on-device, stored in the secure enclave or TPM, and is never transmitted across the network. The device then creates a Certificate Signing Request - a CSR - and sends it to the SCEP gateway. The gateway validates the challenge, forwards the CSR to your Certificate Authority, and the CA signs it and returns the public certificate to the device. From that point on, when the device connects to your WiFi SSID, it presents that certificate to the RADIUS server. The RADIUS server validates the certificate against your CA's trust chain, checks the Certificate Revocation List to confirm the cert has not been revoked, and if everything checks out, sends an accept message to the access point. The device is on the network. The whole process is invisible to the user. Now, let us talk about where SCEP sits relative to the alternative, which is PKCS. PKCS - Public Key Cryptography Standards - is the other certificate delivery method supported by platforms like Intune. With PKCS, the CA generates both the public and private key centrally, and the certificate connector pushes the key pair down to the device. That means the private key travels over the network, which introduces a theoretical attack surface. PKCS is fine for use cases like S/MIME email encryption where key escrow is actually desirable. For WiFi authentication, SCEP is the right choice. The private key stays on the device, full stop. Now, the hardware layer. SCEP and EAP-TLS are vendor-neutral standards, which means they work across Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme, and Fortinet access points. Your RADIUS configuration - whether that is Windows NPS, FreeRADIUS, or a cloud RADIUS service - is where you define the certificate validation policy and, critically, where you configure dynamic VLAN assignment. Dynamic VLANs are how you segment the network by identity. A student device gets VLAN 20 - internet access only. A faculty device gets VLAN 10 - access to internal research systems. A facilities management device gets VLAN 30 - access to building management systems. All of this is driven by the certificate attributes and the RADIUS policy, with no manual intervention per device. For identity provider integration, SCEP certificate attributes - specifically the Subject Alternative Name - can carry the user's principal name from Microsoft Entra ID, Okta, or Google Workspace. That ties the certificate to a specific identity, which means when you disable an account in Entra ID and the MDM unenrolls the device, the certificate is revoked and WiFi access is cut automatically. That is the revocation story that pre-shared keys simply cannot tell. --- IMPLEMENTATION RECOMMENDATIONS AND PITFALLS - approximately 2 minutes Right, let us talk about the deployment sequence, because this is where most teams trip up. The sequence is non-negotiable: Trusted Root certificate first, SCEP certificate profile second, WiFi profile third. Intune and Jamf both enforce profile dependencies. If your WiFi profile references a SCEP certificate that has not yet been deployed to the device, the WiFi profile will fail with a cryptic error that looks like a misconfiguration but is actually just a timing issue. The second pitfall is group targeting. All three profiles - Trusted Root, SCEP, and WiFi - must be deployed to the exact same Azure AD or Jamf group. If the SCEP profile targets a user group and the WiFi profile targets a device group, Intune cannot resolve the dependency and the WiFi profile will show as Not Applicable. This catches teams out constantly. Third: NDES server accessibility. Your NDES server needs to be reachable from the internet so that devices can enroll before they arrive on-site. The right way to do this is via Azure AD Application Proxy, not by punching a hole in your firewall. App Proxy gives you secure remote access without inbound ports and lets you apply Conditional Access policies to the enrollment flow. Fourth: CRL availability. Your RADIUS server checks the Certificate Revocation List every time a device authenticates. If your CRL Distribution Point is unavailable - because a server is down, or the URL has changed - authentication fails for every device on the network simultaneously. That is a campus-wide outage. Make your CRL endpoints highly available, and test revocation before you go live. For large networks - anything above 500 devices - consider a cloud SCEP gateway rather than on-premises NDES. Cloud gateways eliminate the NDES single point of failure, scale horizontally, and typically integrate directly with cloud RADIUS services, removing another infrastructure dependency. --- RAPID-FIRE Q AND A - approximately 1 minute Can SCEP handle BYOD devices that are not MDM-enrolled? Not directly. SCEP requires MDM enrollment to push the certificate payload. For unmanaged BYOD, you need a different approach - either a self-service onboarding portal, or a separate SSID using a Captive Portal with identity verification. Purple's platform handles that guest and BYOD layer cleanly, sitting alongside your certificate-authenticated staff network. What about iOS and Android? Both platforms support SCEP natively. iOS has supported SCEP since iOS 4. Android Enterprise supports SCEP through Intune and other MDMs. The configuration is slightly different per platform but the underlying protocol is identical. Does EAP-TLS work with WPA3? Yes. WPA3-Enterprise mandates 192-bit security mode for sensitive environments, and EAP-TLS is fully compatible. In fact, WPA3-Enterprise with EAP-TLS is the combination recommended by the WiFi Alliance for government and financial networks. - SUMMARY AND NEXT STEPS - approximately 1 minute To bring this together. SCEP certificate WiFi authentication is the right architecture for any network with more than 50 managed devices. It eliminates shared credentials, gives you per-device identity, enables dynamic VLAN segmentation, and integrates directly with your identity provider for automated revocation. The deployment sequence - Trusted Root, then SCEP profile, then WiFi profile - is fixed. Group targeting must be consistent. CRL availability is not optional. For higher education specifically, the combination of SCEP for staff and faculty devices, alongside a separate guest WiFi layer for students on personal devices, gives you both security and a great user experience without compromise. If you want to go deeper, Purple's guide on enterprise WiFi authentication without Active Directory or an on-premises server covers the cloud-native path. And if you are thinking about what happens when an employee leaves, our guide on revoking WiFi access walks through the full revocation workflow. Thanks for listening. I am from the Purple technical team, and we will see you in the next briefing. - END OF SCRIPT