To use certificate-based Wi-Fi or VPN with Intune, you have to get a certificate onto each device. There are three common ways to do it. Here is how SCEP, PKCS, and Microsoft Cloud PKI differ, and which one to start with.
Key Takeaways
- SCEP creates the private key on the device. PKCS issues the key through the Intune Certificate Connector.
- Microsoft Cloud PKI replaces the on-premises CA, NDES, and connector, and issues certificates over SCEP.
- Cloud PKI issues certificates only. You still need a RADIUS server to check them.
What every option needs
Whatever you choose, Intune deploys three things to each device: a trusted certificate profile with your CA’s root (and issuing) certificate, a SCEP or PKCS certificate profile that gets the device or user its own certificate, and a Wi-Fi or VPN profile that uses that certificate. Each profile is per platform, so Windows, macOS, iOS, and Android each get their own.
Intune Plan 1, included in Microsoft 365 Business Premium, E3, and E5, covers SCEP and PKCS profiles.
SCEP
With SCEP, the device creates its own key pair and sends a signed request. The private key never leaves the device. Each request produces a unique certificate, and SCEP works for devices without an assigned user, such as shared or kiosk devices.
With an on-premises Microsoft CA, SCEP needs a Network Device Enrollment Service (NDES) server and the Intune Certificate Connector. NDES is the part most small teams would rather not run.
PKCS
With PKCS, the Intune Certificate Connector requests the certificate from your CA and Intune delivers it, with its key, to the device. It doesn’t need NDES, which makes it attractive if you already run a Microsoft CA. The trade-off is that the private key isn’t created on the device itself.
Microsoft Cloud PKI
Cloud PKI hosts the root and issuing CAs and a SCEP registration service in the cloud, so there is no CA server, NDES, or connector to maintain. It issues, renews, and revokes certificates for Intune-enrolled Windows, macOS, iOS/iPadOS, and Android devices, and Intune hosts the revocation list.
It’s an add-on to Intune, licensed through the Intune Suite or as a standalone capability, and a tenant can have up to three CAs. If you already have a PKI, Cloud PKI can create an issuing CA that chains to your existing root.
Which one to start with
- No existing PKI, mostly Entra-joined devices: Cloud PKI with SCEP. Least to build and maintain.
- An existing Microsoft CA you want to keep: SCEP through NDES if you’re comfortable running it, PKCS if you’d rather avoid NDES, or Cloud PKI chained to your root.
- Shared or userless devices: SCEP device certificates.
The part people forget: RADIUS
A certificate on the device does nothing until something checks it. For Wi-Fi and wired 802.1X, that’s a RADIUS server, either NPS on Windows Server or a cloud RADIUS service. Plan both halves together. Our guide to replacing a shared Wi-Fi password with 802.1X covers the network side, and the OID lookup helps when you need to check a certificate’s Extended Key Usage, such as Client Authentication.
We set this up as part of certificate-based Wi-Fi and VPN.