Certificates are how Intune-managed devices prove who they are to Wi-Fi (802.1X), VPNs, and some apps, with no passwords to phish or share. They're also one of the most fragile parts of an Intune deployment when built the traditional way. Before you troubleshoot SCEP, it's worth asking whether you need it at all.
Pick the approach
| Approach | What you run | Fits |
|---|---|---|
| Microsoft Cloud PKI | Nothing. Microsoft hosts the CA. | Organizations without an existing on-prem CA that want the least to maintain. It's a paid add-on, so check your licensing. |
| SCEP with NDES | An on-prem CA, an NDES server, and the Intune Certificate Connector | Organizations with an existing Microsoft CA, and many device types |
| PKCS | An on-prem CA and the Intune Certificate Connector (no NDES) | Simpler than SCEP when you already have a CA |
| No certificates | Nothing | Many small businesses. WPA2/WPA3-Personal Wi-Fi and a cloud VPN or ZTNA may be enough. |
How the SCEP chain fits together
For a SCEP certificate to arrive on a device, every link has to work:
- Trusted certificate profile. The root (and any intermediate) CA certificate must be deployed first. SCEP profiles reference it.
- SCEP profile in Intune, with subject name, SAN, key usage, and the NDES URL.
- Intune Certificate Connector, installed and healthy, validating requests on NDES.
- NDES server, reachable from the internet (usually through a proxy such as Entra application proxy), with the correct certificate template configured.
- Certificate Authority issues the certificate from the template.
Troubleshooting a SCEP profile that never delivers
Work down the chain.
The trusted root profile. Is it assigned to the same groups as the SCEP profile, and deployed successfully? A SCEP profile tied to an undelivered root never applies.
Connector health. In Intune, go to Tenant administration -> Connectors and tokens -> Certificate connectors. The connector should be Active, with a recent last-connection time. On the server, check the connector's logs under Applications and Services Logs -> Microsoft -> Intune -> CertificateConnectors.
NDES itself. From outside the network, browse to the NDES URL:
https://your-ndes-url/certsrv/mscep/mscep.dllAn HTTP 403 page from IIS is expected and means NDES is responding. A 500 error or timeout points at the NDES app pool, the service account, or the proxy.
The template. The NDES service account needs Read and Enroll on the template, and the registry on the NDES server must name the right template for the purpose you're using. A mismatch here is the classic "everything looks fine and nothing issues" cause.
The device. On Windows, look for the certificate in certlm.msc (device) or certmgr.msc (user), depending on the profile. Check the DeviceManagement-Enterprise-Diagnostics-Provider admin event log for SCEP errors.
The CA. Look in the CA's Failed Requests list. If requests arrive and fail there, the problem is the template or the subject/SAN values, not Intune.
Common SCEP mistakes
- A subject name or SAN variable that resolves empty for some users (a missing
{{OnPremisesSamAccountName}}on cloud-only users, for example) - Key storage provider set to TPM required on devices without a working TPM
- A validity period longer than the template allows
- The NDES service account's password expired
When to rebuild instead of repair
If your NDES setup was built years ago, isn't documented, and breaks every time someone patches the server, moving to Cloud PKI or PKCS is often less work than keeping SCEP alive, especially for a small fleet.