Implementing SCEP for Secure BYOD and 802.1X WiFi in Higher Education

Implementing SCEP for Secure BYOD and 802.1X WiFi in Higher Education A Purple Technical Briefing - approximately 10 minutes [INTRODUCTION AND CONTEXT - 1 minute] Welcome to the Purple Technical Briefing. I'm going to walk you through one of the most common pain points we see in higher education IT: how to get thousands of student and staff devices onto a secure, certificate-authenticated WiFi network without your helpdesk drowning in tickets. The short answer involves three letters: SCEP. That's the Simple Certificate Enrollment Protocol. And when you pair it with 802.1X and a cloud RADIUS service, you get something genuinely powerful - a network where every device proves its identity before it gets access, certificates are issued and renewed automatically, and your IT team doesn't have to touch each device manually. Universities are under real pressure here. You've got tens of thousands of students arriving every September with their own laptops, phones, and tablets. You need them on a secure network quickly. And you need to ensure that when a student leaves or a device is lost, access is revoked cleanly. SCEP is the mechanism that makes all of that work at scale. Let's get into the technical detail. [TECHNICAL DEEP-DIVE - 5 minutes] First, let's be clear about what SCEP actually is. It's a protocol - originally developed by Cisco - that automates the process of requesting and receiving a digital certificate from a Certificate Authority. Before SCEP, getting a certificate onto a device meant either a manual process involving a USB stick and a lot of clicking, or a complex web-based enrollment that confused most end users. SCEP automates that handshake entirely. Here's how the flow works in a university BYOD context. A student arrives on campus. Their device - whether it's a MacBook, an Android phone, or a Windows laptop - is enrolled in your Mobile Device Management platform, or MDM. The MDM pushes a configuration profile to the device. That profile contains the SCEP URL pointing to your Certificate Authority, a challenge password for authentication, and the certificate template to use. The device generates a key pair locally - the private key never leaves the device - and sends a certificate signing request to the CA via SCEP. The CA validates the request, issues a certificate, and returns it to the device. The whole process takes seconds and requires no user interaction beyond the initial MDM enrollment. Now, why does this matter for WiFi specifically? Because 802.1X - the IEEE standard for port-based network access control - can use that certificate as the authentication credential. Instead of a username and password, the device presents its certificate to the RADIUS server. The RADIUS server validates the certificate against your CA, confirms the device is known and trusted, and grants access. This is EAP-TLS - Extensible Authentication Protocol with Transport Layer Security - and it's the gold standard for WiFi authentication. The security advantages over password-based approaches are significant. Certificates can't be phished. A student can't accidentally give their certificate to a fake network. The private key never leaves the device, so even if a certificate is somehow intercepted, it's useless without the corresponding private key. And because the certificate contains the device identity, you get granular visibility into exactly which device is on your network at any given time. Now let's talk about the infrastructure components you need. You need a Certificate Authority - this can be Microsoft Active Directory Certificate Services, which most universities already have, or a cloud-based CA. You need an NDES server - that's Network Device Enrollment Service - which acts as the SCEP proxy between your devices and your CA. You need a RADIUS server to handle the 802.1X authentication. And you need access points that support WPA2-Enterprise or WPA3-Enterprise with 802.1X. Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, and Fortinet all support this natively. For the RADIUS component, Purple's SecurePass uses a cloud-native RADIUS service. The primary server is rad1-secure.purple.ai and the secondary is rad2-secure.purple.ai, both on the standard authentication port 1812 and accounting port 1813. This eliminates the need to run your own on-premises RADIUS infrastructure - which historically has been a significant operational burden for university IT teams. For the full configuration steps, Purple's support documentation at support.purple.ai covers the exact setup process. One thing worth emphasising: SecurePass is built on the Passpoint - also known as Hotspot 2.0 - standard. This means a student who enrolls at your university doesn't just get secure access on campus. Their device will auto-connect at any of the 80,000-plus OpenRoaming-enabled venues worldwide - airports, hotels, train stations. The certificate-based identity travels with them. That's a genuinely useful benefit for students who travel. The SSID configuration is important to get right. SecurePass requires a dedicated SSID with WPA2 or WPA3-Enterprise and Hotspot 2.0 enabled. You should not reuse your existing captive portal SSID. The SSID must be broadcast - hidden SSIDs prevent the auto-connect behaviour that makes the whole system work. For identity provider integration, SecurePass syncs with Microsoft Entra ID and Google Workspace. This is critical for the joiners, movers, leavers workflow. When a student graduates or a staff member leaves, their account is disabled in Entra ID, and access is automatically revoked. No manual certificate revocation required. That's the kind of automation that saves your IT team real time. [IMPLEMENTATION RECOMMENDATIONS AND PITFALLS - 2 minutes] Let me give you the practical recommendations I'd give any university IT team starting this project. First, start with staff before students. Staff devices are typically managed - you have MDM coverage, you know the device inventory, and the population is smaller. Get the process right with staff, iron out the edge cases, then scale to students. Second, plan your certificate lifetime carefully. A one-year certificate lifetime is a common choice, but think about your academic calendar. If certificates expire in August, you'll have a wave of renewals right before the new academic year starts. Consider aligning expiry to mid-semester, or use automatic renewal via SCEP to avoid the problem entirely. Third, test your NDES configuration thoroughly before go-live. NDES is the component that most commonly causes issues. The challenge password must be generated fresh for each enrollment request - it has a short validity window. If your MDM is generating the SCEP request too slowly after fetching the challenge password, enrollment will fail. Test with a range of device types and operating system versions. Fourth, don't neglect the device compatibility matrix. iOS, macOS, Android, and Windows all handle SCEP slightly differently. iOS and macOS have native SCEP support built in and work cleanly with MDM-pushed profiles. Android behaviour varies by manufacturer. Windows requires the NDES connector or a third-party MDM agent. Document your supported configurations and communicate them clearly to students. The most common pitfall I see is under-investing in the MDM layer. SCEP is only as good as your MDM coverage. If students have devices that aren't enrolled in MDM, they can't receive the SCEP profile. You need a clear onboarding process - ideally integrated into your student registration workflow - that gets devices into MDM before they arrive on campus. [RAPID-FIRE Q AND A - 1 minute] A few quick questions I get asked regularly. Can SCEP work without an MDM? Technically yes - you can distribute SCEP profiles manually - but at university scale, you need MDM. Without it, you're back to manual processes. What happens to devices that don't support 802.1X? They continue through your existing captive portal as normal. SecurePass is additive - unsupported devices are not blocked. Does this work for IoT devices on campus? IoT devices typically don't support 802.1X. Segment them onto a separate VLAN with appropriate firewall rules. Don't try to put your smart building sensors on the same network as student laptops. Is EAP-TLS the only option? No. PEAP with MSCHAPv2 is a common alternative that uses username and password rather than certificates. But EAP-TLS with SCEP-issued certificates is significantly more secure and eliminates the password management overhead. [SUMMARY AND NEXT STEPS - 1 minute] To summarise: SCEP automates certificate enrollment at scale. Combined with 802.1X and EAP-TLS, it gives you a network where every device is cryptographically authenticated, certificates are issued and renewed without IT intervention, and access is revoked automatically when someone leaves. For a university with thousands of BYOD devices, that's the difference between a manageable network and a helpdesk nightmare. The key components are: a Certificate Authority, an NDES or SCEP proxy server, a cloud RADIUS service, and access points that support WPA2 or WPA3-Enterprise. Purple's SecurePass provides the cloud RADIUS layer and the Passpoint-based profile distribution, integrating with your existing Microsoft Entra ID or Google Workspace directory. Your next steps: review your MDM coverage and identify gaps, assess your CA infrastructure, and speak to your network hardware vendor about Passpoint support. Then visit support.purple.ai to review the SecurePass configuration guide and hardware compatibility list. Thanks for listening. If you have questions, the Purple team is at purple.ai.