Wi-Fi or VPN stops working on a batch of laptops, and the cause turns out to be the SCEP certificate profile: it shows Pending for days, or Error with 0x87D1FDE8. The usual first moves are to rebuild the NDES server, reinstall the Intune Certificate Connector, or delete and recreate the profile.
Hold off on all three. A SCEP certificate goes through six handoffs between the Intune admin center and the device's certificate store, and most "SCEP failed" tickets break at the first one: assignment. This post walks the chain in order. Every step below only reads until the change table at the end.
TL;DR
- The SCEP profile and the trusted certificate profile it points to must reach the same entity type. A SCEP profile assigned to users with a root profile assigned only to devices fails, and so does the reverse.
- Certificate type (User or Device) decides the subject variables you can use and, on Windows, the store: Device goes to Local Computer, User goes to Current User.
-
0x87D1FDE8is a generic "remediation failed." The real reason is in the device's DeviceManagement-Enterprise-Diagnostics-Provider > Admin log (events 306, 36, 39). - Browsing to the NDES URL and getting HTTP 403.0 Forbidden is the healthy result. 503, GatewayTimeout, 414 or 500 each point to a specific server-side cause.
- With Cloud PKI there's no NDES, connector or App Proxy to troubleshoot. Look at the SCEP URI, the root pairing and the EKUs instead.
Where in the chain did it break?
Microsoft's SCEP troubleshooting guide breaks delivery into six steps. Each one leaves its own evidence:
| Step | What happens | Typical symptom when it breaks |
|---|---|---|
| 1. Profile deployment | Intune sends the SCEP profile plus a signed challenge for a specific user/device, purpose and type | Pending forever, or Error because the root profile and SCEP profile target different entity types |
| 2. Device → NDES | Device builds the CSR and calls the SCEP URL (GetCACaps, GetCACert, PKIOperation) |
No IIS log entry at all; TLS errors such as 0x80072F8F; App Proxy "GatewayTimeout" |
| 3. NDES → policy module | The Intune Certificate Connector checks the CSR against the challenge | Challenge validation failure, for example "Subject Name in CSR and challenge do not match" |
| 4. NDES → CA | NDES submits to the template named in the MSCEP registry | Request denied or failed on the CA; wrong template for the profile's key usage |
| 5. Delivery | The certificate is installed in the right store | Event 39 missing; certificate lands in the other store |
| 6. Reporting | The connector reports issuance back to Intune | Certificate is on the device, portal still lags |
In the Intune admin center > Devices > Configuration > [SCEP profile] > Device and user check-in status, note the status for three or four affected devices. If every device fails, look at the profile, the pairing or the server. If one network or one platform fails, look at reachability.
Step 1: Read the assignment pairing
This is the cheapest check and the most common cause. Microsoft's pairing rule:
| SCEP profile assigned to | Root profile assigned to Users | Root profile assigned to Devices | Root profile assigned to both |
|---|---|---|---|
| Users | Success | Failure | Success |
| Devices | Failure | Success | Success |
| Users and devices | Success | Success | Success |
Then open the SCEP profile's settings (read only):
- Root Certificate: it must point at the trusted certificate profile for the top-level root that chains to your issuing CA, not at an intermediate profile.
-
Certificate type: User certificates can carry user and device variables; Device certificates can only carry device variables. A Device profile with
CN={{UserPrincipalName}}won't get a certificate. - Device groups and timing: Microsoft notes that a profile assigned to a device group waits for full device registration. A profile assigned to a user group arrives faster after enrollment. "Pending for an hour after Autopilot" is often just that.
Troubleshooting + support > Troubleshoot, with Assignments set to Configuration profiles, shows whether the user is in the group and when the device last checked in. If the device hasn't checked in, start with the Company Portal / sync triage.
Step 2: Read the device's SCEP events
On an affected Windows device, with authorization:
# Read-only: recent SCEP entries from the MDM Admin log
Get-WinEvent -LogName 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin' -MaxEvents 500 |
Where-Object Message -match 'SCEP' |
Select-Object TimeCreated, Id, LevelDisplayName, Message -First 20 | Format-List
| Event | Meaning | What to read |
|---|---|---|
| 306 | Profile arrived. Result: 0x2ab0003 is accepted for processing
|
InstallLocation: user or device. It should match the Certificate type you meant to deploy |
| 36 | "SCEP: Certificate request generated successfully" | The NDES URL the device actually used |
| 39 | "SCEP: Certificate installed successfully" | Delivery is done. If Wi-Fi still fails, the problem is with the relying party, not SCEP |
Decode any code read-only with certutil -error 0x80072f8f. The usual network ones: 0x80072F8F is a TLS/secure-channel failure (untrusted or expired NDES certificate, revocation check, clock skew, TLS inspection), 0x80072EE2 is a timeout, and 0x80072EFD means it couldn't connect.
Then check the stores, again read only:
# Root present in Local Computer > Trusted Root? (Issued To = Issued By)
Get-ChildItem Cert:\LocalMachine\Root | Where-Object Subject -match '<your root CA CN>' |
Select-Object Subject, NotAfter, Thumbprint
# Where did the SCEP certificate land, if anywhere?
Get-ChildItem Cert:\CurrentUser\My, Cert:\LocalMachine\My |
Where-Object Issuer -match '<your issuing CA CN>' |
Select-Object PSParentPath, Subject, NotAfter, Thumbprint
A certificate in LocalMachine\My when you expected one per user (or the reverse) means the profile's Certificate type doesn't match how the Wi-Fi/VPN profile uses it. The store follows the certificate type, not the group.
Step 3: Read NDES reachability (on-premises NDES only)
From an affected device's network, open the SCEP Server URL from the profile in a browser:
| Result | Meaning |
|---|---|
| HTTP Error 403.0 – Forbidden | Expected. The Intune policy module is in front of NDES |
| Generic NDES welcome page | The connector's policy module isn't intercepting; check the connector install |
| 503 Service Unavailable | SCEP application pool stopped (often intermediate CAs in the NDES server's Trusted Root store, CRL reachability, or an expired NDES policy certificate) |
| GatewayTimeout | Entra application proxy connector service not running |
| This page can't be displayed | App Proxy external URL wrong; Microsoft recommends the *.msappproxy.net default domain |
| 414 Request-URI Too Long | IIS request filtering not set for NDES's long query strings |
On the NDES server (read only):
# Did the device's request arrive at all? 200 = reached NDES, 500 = IIS_IUSRS rights
Select-String -Path "$env:SystemDrive\inetpub\logs\LogFiles\W3SVC1\*.log" -Pattern 'mscep' |
Select-Object -Last 20 | ForEach-Object Line
# Which template does each key-usage purpose map to?
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Cryptography\MSCEP' |
Select-Object SignatureTemplate, EncryptionTemplate, GeneralPurposeTemplate
# Intermediates sitting in Trusted Root (a known app-pool crash cause)
Get-ChildItem Cert:\LocalMachine\Root | Where-Object { $_.Issuer -ne $_.Subject }
No IIS entry at all means the request never got there: firewall, reverse proxy, DNS. If you publish more than one SCEP URL behind a load balancer, all three calls in one request must reach the same NDES server, or the request fails.
Step 4: Challenge, template and subject name
If IIS shows 200 but no certificate comes back, read the connector log on the NDES server (Event Viewer > Applications and Services Logs > Microsoft > Intune > CertificateConnectors > Operational). Typical causes:
-
Template mapping: the profile's Key usage picks the registry value (Digital signature →
SignatureTemplate, Key encipherment →EncryptionTemplate, both →GeneralPurposeTemplate). That value must hold the template name, not its display name. The template's subject must be Supply in the request. - Validity: the profile can't ask for more than the template allows, and Microsoft warns against anything under five days.
-
Subject name: an escaped
\,\;or\=in the CN breaks challenge validation. Quote the CN instead. Names over 64 characters can hit the CA's DN length enforcement. -
{{DeviceId}}on Windows: Microsoft says to avoid it in the subject name on Windows because in some cases it makes Intune sync fail.{{AAD_Device_ID}}or{{DeviceName}}are the usual alternatives. -
Unsupported variables: a device must support every variable in the profile.
{{IMEI}}on a laptop with no modem fails the whole profile. - Third-party CA and the SID tag: Intune now adds a strong-mapping SID URL tag to the SAN. CAs that don't support it may refuse to issue.
Cloud PKI: a shorter checklist
With Microsoft Cloud PKI there's no NDES server, no certificate connector and no proxy to publish. What's left to read:
-
SCEP Server URL is the issuing CA's SCEP URI with
{{CloudPKIFQDN}}left exactly as is. Don't mix NDES URLs into the same profile. - Root Certificate points at the trusted certificate profile for the root the issuing CA is anchored to. Microsoft recommends deploying the issuing CA certificate with its own profile too.
- EKUs in the profile must exist on the issuing CA, and subject variables must exist on the Entra user/device object (an empty email attribute means no certificate).
When a change is justified
| Finding | Prefer | Avoid |
|---|---|---|
| Root and SCEP profiles target different entity types | Assign the trusted certificate profile to the same groups as the SCEP profile | Recreating the SCEP profile |
| Root Certificate points at an intermediate | Re-point to the top-level root profile | Importing roots onto devices by hand |
| Certificate in the wrong store | New profile with the right Certificate type, tested on a pilot group | Editing Wi-Fi/VPN profiles to accept any certificate |
0x80072F8F / certificate warning on NDES URL |
Fix the TLS chain, revocation reachability or TLS inspection bypass for that URL | Switching the profile to HTTP to "test" |
| 503 / GatewayTimeout / 414 | Fix that specific server cause from Step 3 | Rebuilding NDES |
| Challenge mismatch on subject | Quote the CN, swap {{DeviceId}} for {{AAD_Device_ID}}
|
Editing the production profile for everyone at once (it reissues certificates) |
| Template mismatch | Correct the MSCEP registry value to the template name, then restart the server (Microsoft: not iisreset) |
Granting broader template permissions |
FAQ
What does 0x87D1FDE8 mean on a SCEP profile?
It's a generic remediation-failed status. It tells you the profile didn't apply, not why. The device's MDM Admin log and the connector log have the reason.
Why is the SCEP profile Pending but the root certificate shows Succeeded?
Usually the device hasn't finished the SCEP exchange yet, the profile targets a device group and the device isn't fully registered, or the root profile reached users while SCEP targets devices.
Do I need NDES for Intune SCEP certificates?
Only with an on-premises Microsoft CA. Cloud PKI provides its own SCEP service, and third-party CA partners use their own integration.
The certificate installed (event 39) but Wi-Fi still fails.
Then SCEP did its job. Check the RADIUS/NPS side: does it trust your issuing CA, and does on-prem certificate auth need the strong-mapping SID ({{OnPremisesSecurityIdentifier}} as a URI SAN)?
Is it safe to just reinstall the certificate connector?
Only after the logs point there, for example the generic NDES page instead of 403. Reinstalling first throws away the evidence.
Related posts
- Company Portal can't connect / device not syncing: a 10-minute triage order
- Autopilot ESP stuck? An assignment-first triage checklist
- Intune compliance "Not applicable", "Is active" and minimum OS
- Compliance before Conditional Access: an enrollment compliance runway
Free checklist
Certificate-based Wi-Fi and VPN often end up behind Conditional Access. Before you require compliant devices, the free Conditional Access pre-enforcement checklist keeps device readiness, pilot groups and report-only review on one page, so a broken certificate rollout doesn't turn into a sign-in lockout:
If you want the rest of the Intune runway written down for the team (enrollment hygiene, compliance phasing, break/fix cards and read-only PowerShell snapshots), the Intune & M365 Admin Starter Pack pairs with this triage: https://cashflow4375.gumroad.com/l/joonf?utm_source=devto&utm_medium=article&utm_campaign=aps_first_sale&utm_content=intune-scep-certificate-failed
Admin Pack Studio; not affiliated with Microsoft. Steps 1–4 only read. Test profile changes on a pilot group first, and check current Microsoft docs for event IDs and log names.
Top comments (0)