The Enterprise Guide to SCEP: Deploying Simple Certificate Enrollment Protocol for Automated Campus WiFi Security

Good morning. If you're managing WiFi infrastructure across a hotel group, a retail estate, a stadium, or a university campus, this briefing is for you. We're going to cover SCEP - Simple Certificate Enrollment Protocol - and specifically how it solves one of the most persistent headaches in enterprise WiFi: getting certificates onto thousands of devices automatically, without your helpdesk drowning in tickets. [short pause] Let me set the scene. You've decided - correctly - that pre-shared keys are no longer acceptable for staff WiFi. A single compromised password exposes your entire network segment. You've moved, or you're moving, to 802.1X authentication. That's the IEEE standard that requires every device to prove its identity before it gets network access. The most secure flavor of 802.1X is EAP-TLS - Extensible Authentication Protocol with Transport Layer Security - which uses digital certificates rather than passwords. Certificates are cryptographically unique per device, they can't be shared, and they can be revoked instantly if a device is lost or an employee leaves. [short pause] So far, so good. The problem is distribution. How do you get a unique certificate onto every laptop, every phone, every tablet in your estate - across Windows, iOS, Android, macOS - without a technician touching each device? That's precisely what SCEP solves. [medium pause] SCEP was formalized by the Internet Engineering Task Force in RFC 8894 in 2020, though it's been in use in enterprise environments since the early 2000s. It's a protocol that lets a managed device request its own certificate directly from your Certificate Authority, using a pre-configured URL and a challenge password. The critical security point here: the private key is generated on the device itself, stored in the device's secure enclave - that's the TPM chip on Windows devices, or the Secure Enclave on Apple hardware - and it never travels across the network. The device generates a Certificate Signing Request, sends that to the SCEP gateway, the gateway validates the challenge, forwards the request to your Certificate Authority, the CA signs it, and the signed certificate comes back to the device. The whole process is invisible to the end user. [short pause] Now, in a Microsoft environment, the SCEP gateway is typically NDES - Network Device Enrollment Service - a Windows Server role that acts as the intermediary between your MDM platform and your CA. Microsoft Intune pushes the SCEP profile to managed devices, which tells them the NDES URL and the challenge password. Devices do the rest automatically. [medium pause] Let me walk you through what a real deployment looks like. Take a hotel group with 150 properties - think Marriott scale. They have a mix of Windows laptops for front-of-house staff, iOS devices for housekeeping supervisors, and Android tablets at the restaurant point-of-sale. Before SCEP, they were running WPA2-Personal with a shared password rotated quarterly. Every rotation generated a wave of helpdesk calls. With SCEP and Intune, they deploy three profiles in sequence. First, the Trusted Root Certificate profile - this tells every device to trust the company's Certificate Authority. Second, the SCEP Certificate profile - this instructs devices to go and collect their unique client certificate. Third, the WiFi profile - this configures the SSID, sets the security type to WPA2-Enterprise or WPA3-Enterprise, and points to the SCEP certificate for authentication. Deploy those three profiles to the same device group in Intune, and every managed device connects to the corporate SSID automatically, with a unique certificate, zero user interaction required. [short pause] The RADIUS server - typically Microsoft NPS or a cloud RADIUS service - receives the EAP-TLS authentication request, validates the certificate against the CA, checks the Certificate Revocation List, and grants or denies access. If an employee is terminated, you revoke their certificate in the CA. Their device loses WiFi access at the next authentication cycle. No password reset required. No waiting for a quarterly rotation. [medium pause] Now, people often ask about the difference between SCEP and PKCS - Public Key Cryptography Standards. Both work with Intune. The key difference is where the private key is generated. With SCEP, it's generated on the device. With PKCS, the CA generates both keys centrally and pushes the private key down to the device. That means the private key travels across the network, which introduces a theoretical interception risk. PKCS has its place - it's better suited for S/MIME email encryption where key escrow matters. For WiFi authentication, SCEP is the right choice. Every time. [short pause] Let me give you a second scenario - a retail estate. Imagine a fashion retailer with 200 stores across the US, each running Cisco Meraki access points. Their point-of-sale systems are Windows-based, managed through Intune. They need PCI-DSS compliance, which means network segmentation and strong authentication for any device handling cardholder data. SCEP-based EAP-TLS gives them device-level authentication on the staff SSID, with VLAN assignment driven by the RADIUS policy. The POS terminals land on the PCI-scoped VLAN automatically. Guest WiFi - handled separately through a platform like Purple - runs on a completely isolated SSID with its own authentication flow. The two networks never touch. Auditors are happy. The security team sleeps better. [medium pause] Right, let's talk about the pitfalls, because there are a few that catch teams out. [short pause] The most common failure mode is group targeting mismatches in Intune. Your Trusted Root profile, your SCEP profile, and your WiFi profile must all target the same Azure AD group. If the SCEP profile targets a User group and the WiFi profile targets a Device group, Intune can't resolve the dependency and the WiFi profile shows as an error. Check your assignments first - it's almost always the culprit. [short pause] Second pitfall: NDES server availability. Your NDES server needs to be reachable from the internet for remote devices to enroll before they arrive on-site. The secure way to do this is via Azure AD Application Proxy, which gives you remote access without opening inbound firewall ports. Don't expose NDES directly to the internet. [short pause] Third: CRL availability. Your RADIUS server checks the Certificate Revocation List every time a device authenticates. If the CRL Distribution Point is unreachable - maybe a server is down, or a firewall rule changed - authentication fails for everyone. Make your CRL endpoints highly available, and test them regularly. [short pause] Fourth: certificate template permissions. If your NDES connector service account doesn't have Read and Enroll permissions on the certificate template, devices get HTTP 403 errors when they try to collect their certificate. It's a simple permissions fix, but it's easy to miss during initial setup. [medium pause] Now for a rapid-fire round. [short pause] Can SCEP work with non-Microsoft MDMs? Yes - Jamf for Apple device fleets, VMware Workspace ONE, and most enterprise MDM platforms support SCEP profiles. The protocol is vendor-neutral. [short pause] Does SCEP work with cloud PKI? Yes. Microsoft's own cloud PKI in Intune Suite eliminates the need for an on-premises NDES server entirely. Third-party cloud PKI providers like SecureW2 and Keyfactor also offer cloud SCEP endpoints. [short pause] What about WPA3-Enterprise? WPA3-Enterprise uses the same 802.1X and EAP-TLS authentication stack. SCEP-issued certificates work identically. The upgrade is at the wireless protocol layer, not the certificate layer. [short pause] How long do certificates last? Typically one year, though you can configure shorter validity periods. Intune handles automatic renewal before expiry, so users never see an interruption. [medium pause] To summarize. SCEP automates certificate distribution at scale, eliminating the manual overhead of PKI deployment across large device fleets. The private key stays on the device - that's the security foundation of EAP-TLS. Deploy in sequence: Trusted Root first, SCEP profile second, WiFi profile third, all targeting the same group. Publish your NDES endpoint securely via Application Proxy. Keep your CRL endpoints highly available. And if you're starting fresh, evaluate cloud PKI to remove the on-premises NDES dependency entirely. [short pause] For guest WiFi - the separate, visitor-facing network - certificate-based authentication isn't the right model. Guests don't have managed devices. That's where a platform like Purple handles the authentication flow: captive portal, social login, email capture, or SMS verification, all feeding into a first-party data layer that your marketing team can actually use. The two approaches complement each other: SCEP for your managed staff estate, Purple for your guest network. Both running on the same hardware, cleanly segmented by VLAN. [short pause] That's your briefing on SCEP enterprise WiFi onboarding. The full written guide, with architecture diagrams, step-by-step Intune configuration, and worked examples, is available on the Purple website. Thanks for listening.