Intune Cloud PKI Fix Guide (2026)

Updated: September 1, 2026

Microsoft Intune Cloud PKI is a cloud-hosted certificate authority and SCEP registration service that issues X.509 certificates to Intune-managed devices without any on-premises NDES, IIS, or Intune Certificate Connector infrastructure. Most Cloud PKI failures in 2026 come from four repeatable patterns (profile-assignment sequencing, BYOCA chain-of-trust gaps, missing CRL distribution to RADIUS, and the generic 0x87d1fde8 remediation error), and every one of them is fixable in under fifteen minutes once you know where the SCEP URI and event logs live. I run a tier-1 queue where certificate tickets used to eat 40 minutes of mean time to resolution on the old NDES stack. After cutover, the same fixes take five. So this guide is basically the checklist we use, warts and all.

Cloud PKI includes a built-in SCEP service that replaces on-prem NDES, IIS, and the Intune Certificate Connector. No on-prem servers to maintain, and Microsoft handles Azure HSM key storage on paid tiers.
The single most common deployment failure is assignment sequencing. The trusted certificate profile must be deployed to the same user or device group as the SCEP certificate profile, or the SCEP profile silently stays in a pending state.
BYOCA (Bring Your Own CA) issuing CAs must be activated by uploading both the signed issuing certificate and the full .p7b chain. A missing intermediate breaks the trust chain on every relying party.
Cloud PKI has no OCSP support in 2026. RADIUS servers must be configured against the Cloud PKI CRL Distribution Point URIs, and the CRL is the only supported revocation mechanism.
Microsoft 365 E5 includes Cloud PKI at no additional cost as of July 1, 2026, alongside Endpoint Privilege Management and Enterprise Application Management.
Report data on the Cloud PKI monitor dashboard lags device issuance by up to 24 hours. Don't open a ticket if the certificate exists on the device but is missing from the tenant report.

What is Microsoft Intune Cloud PKI?

Microsoft Intune Cloud PKI is a Platform-as-a-Service certificate authority that runs entirely inside your Intune tenant. It provisions a two-tier CA hierarchy (a root CA and one or more issuing CAs) and exposes a built-in SCEP registration authority so managed Windows, macOS, iOS/iPadOS, and Android devices can request and renew certificates directly against a cloud endpoint. The service supersedes the legacy pattern where you had to stand up Active Directory Certificate Services (ADCS), Network Device Enrollment Service (NDES), a public-facing App Proxy, and the Intune Certificate Connector on a domain-joined Windows Server.

Cloud PKI supports two deployment models. In the Cloud Root CA model, both the root and issuing CAs are hosted inside Intune and are never exposed outside the tenant. In the Bring Your Own CA (BYOCA) model, you keep your existing ADCS root, generate a CSR for a new cloud-hosted issuing CA, sign that CSR on your private root, and upload the signed certificate plus the full chain. BYOCA is the common choice for organisations that already have a well-trusted internal PKI and want their existing relying parties (RADIUS, ADFS, internal web apps) to continue trusting certificates without redistributing a new root.

The service is a subset of what ADCS can do. It handles SCEP-based issuance to Intune-managed endpoints and nothing else. No server auth certificates, no code-signing, no manual enrolment, no CSR signing for network devices. Treat it as a certificate delivery pipe for Intune, not a general-purpose CA replacement. Microsoft's deployment models documentation lays out the constraints in detail.

Cloud PKI vs on-premises NDES: what changed for tier-1

If you've run NDES for enterprise Wi-Fi or VPN certificates, you already know the tier-1 pain: the NDESConnector_YYYYMMDD.svclog, the PfxRequest\Failed folder, the 0x800706BA RPC errors when the CA hostname is typed wrong in the SCEP profile, and the recurring incidents when the NDES service account password expires. Cloud PKI removes almost all of that surface area. Devices talk to a Microsoft-hosted SCEP endpoint over TLS, Microsoft rotates the CA keys inside an Azure HSM on paid tiers, and there is no on-prem log to gather for the SCEP service itself.

The trade-off is visibility. When a Cloud PKI certificate doesn't deploy, you no longer have server-side connector logs to grep. Your diagnostic surface shrinks to three things: the Intune device configuration profile status, the Windows DeviceManagement-Enterprise-Diagnostics-Provider event log, and the Cloud PKI issuing CA monitor dashboard. That's a smaller surface, but you have to know exactly where each of those lives.

Dimension	On-prem NDES + ADCS	Intune Cloud PKI
Servers to patch	NDES, IIS, App Proxy, connector, CA	None
SCEP endpoint	Public reverse proxy you own	Microsoft-hosted SCEP URI
Key storage	Depends on HSM you buy	Azure HSM on paid tiers, software-bound on trial
Revocation	CRL and OCSP	CRL only (no OCSP in 2026)
Non-Intune certificate issuance	Yes (users, servers, network gear)	Intune-managed devices only
Licensing	Windows Server + CALs	Intune Suite or M365 E5 (from July 2026)
Typical MTTR for a bad SCEP profile	30-45 min (multi-log correlation)	5-10 min (profile + one event log)

How do I fix a SCEP certificate stuck in pending?

A SCEP certificate profile that reports Pending in the Intune device install status, with no leaf certificate ever landing in the device's Personal store, is almost always a profile-assignment sequencing problem. The rule is strict: the trusted certificate profile carrying the root (and, for BYOCA, any intermediate CA) must be assigned to the same user or device that receives the SCEP certificate profile, and it must land on the device first. If the device only has the SCEP profile, it has no trust anchor to validate the Cloud PKI SCEP endpoint's own certificate, and the request silently loops.

Work the fix in this order:

Confirm the trusted certificate profile is assigned to the same group. In the Intune admin center, open both profiles and compare Assignments. For BYOCA, you need one trusted certificate profile per CA in the chain: one for your root, one for each intermediate.
Verify the SCEP URI in the SCEP profile matches the one shown on the Cloud PKI issuing CA's Properties page exactly. A single copy-paste truncation here produces the pending state (I've done this myself, twice).
Check the device event log. On Windows, open Event Viewer → Applications and Services Logs → Microsoft → Windows → DeviceManagement-Enterprise-Diagnostics-Provider. Filter for provider DeviceManagement-Enterprise-Diagnostics-Provider and look for events 306, 404, or anything with 0x8xxxxxxx result codes referencing SCEP or ClientCertificateInstall.
Force a re-sync. Settings → Accounts → Access work or school → managed account → Info → Sync. Then wait five minutes and re-check the device's certmgr.msc Personal store.

The following PowerShell one-liner pulls the last two hours of MDM diagnostic events without needing you to click through Event Viewer. Run it on the target device as an administrator:

Get-WinEvent -FilterHashtable @{
    LogName   = 'Microsoft-Windows-DeviceManagement-Enterprise-Diagnostics-Provider/Admin'
    StartTime = (Get-Date).AddHours(-2)
} |
    Where-Object { $_.Message -match 'SCEP|ClientCertificate|Cert' } |
    Select-Object TimeCreated, Id, LevelDisplayName, Message |
    Format-List

Look for the event that shows the CSP path the profile targets and the Result HRESULT. If the CSP path references a certificate template that Cloud PKI doesn't support (Cloud PKI is template-less; templates are an ADCS concept), the profile was authored wrong. Recreate it as a Cloud PKI SCEP profile, not a legacy NDES one.

How do you fix Intune error 0x87d1fde8?

Error 0x87d1fde8 (also displayed as -2016281112, meaning "the system cannot find the file specified") is Intune's generic remediation-failed HRESULT. It surfaces against many profile types (VPN, LAPS, Wi-Fi, custom OMA-URI, and PKCS/SCEP certificates), and the same error code hides at least six unrelated root causes. Don't treat it as a single bug. Treat it as a signal to open the DeviceManagement-Enterprise-Diagnostics-Provider event log and identify which CSP failed.

Common root causes when 0x87d1fde8 appears on a Cloud PKI profile

Wrong CSP path in a custom OMA-URI profile. If someone authored a custom policy to write a certificate to a store the device doesn't expose, the CSP write fails with 0x87d1fde8. Verify the OMA-URI path against the current CSP reference on Microsoft Learn.
Trusted root profile missing. A SCEP profile evaluating against an empty trusted store returns 0x87d1fde8 because the referenced trust anchor "file" cannot be resolved on the device.
Conflicting profiles. Two profiles trying to set the same setting to different values will register as 0x87d1fde8 on whichever loses the merge. In the Intune admin center, use Reports → Device configuration → Assignment failures → Per-setting status to find the conflict.
OS edition or build mismatch. A Cloud PKI certificate profile requires Windows 10 1809 or later on the Pro/Enterprise/Education SKUs. Windows Home devices report 0x87d1fde8 because the MDM CSP isn't present.
Known VPN profile issue. On Windows 11 devices with an Always On VPN profile, Microsoft has documented an active known-issue that reports 0x87d1fde8 without any real failure. Cross-check the Windows release health dashboard before chasing this one.

The fastest way to narrow down which cause is yours: on the affected device, run MdmDiagnosticsTool.exe -area DeviceEnrollment;DeviceProvisioning;Autopilot;TPM -zip C:\Temp\MDM.zip, open MDMDiagReport.html, and search for the policy definition URI. The event immediately preceding the failure usually tells you which parameter the CSP could not resolve.

BYOCA chain-of-trust troubleshooting

A BYOCA issuing CA becomes usable only after you upload two files: the signed issuing CA certificate and the full chain-of-trust bundle as a .p7b. If you skip the .p7b, or if the .p7b is missing an intermediate, the issuing CA will flip to Active in the tenant UI, but every certificate it issues will fail chain validation on your RADIUS servers and any Windows client that doesn't already trust the intermediate. That failure mode looks like Wi-Fi authentication silently rejecting devices that have a valid-looking cert in certmgr.msc. Honestly, this is one of the nastier failure modes because the certificate is right there, and the device thinks everything worked.

To activate a BYOCA issuing CA correctly, follow this sequence in the Intune admin center: Tenant administration → Cloud PKI → select the issuing CA → Properties → Upload signed certificate. Attach the signed issuing CA cert and the corresponding chain file. Wait 60-120 seconds and refresh; the Status column should read Active, and the Root common name should show your on-prem root, not "Microsoft Cloud PKI Root". That column is the fastest sanity check that the anchoring worked.

Once active, the issuing CA properties expose three URIs your infrastructure needs:

SCEP URI. Used in every SCEP certificate profile that targets this issuing CA. Copy this into the SCEP profile's Server URL field verbatim.
CRL Distribution Point URI. Must be reachable from every RADIUS server, VPN concentrator, and internal reverse proxy that validates certificates issued by this CA.
AIA URI. For BYOCA, this URI is defined by your private CA's AIA configuration; ADCS defaults to LDAP AIA, which relying parties outside the domain cannot fetch. If you plan to use certificates with off-domain RADIUS or SaaS RADIUS, publish a second HTTP AIA on your ADCS root before onboarding BYOCA.

Microsoft's official BYOCA configuration reference documents the CSR signing steps and the exact fields your on-prem CA must populate on the issued certificate.

CRL, AIA, and 802.1X Wi-Fi/RADIUS integration

Cloud PKI doesn't include a RADIUS server, and Microsoft hasn't announced one. If you plan to use Cloud PKI certificates for EAP-TLS Wi-Fi (802.1X) or wired auth, you still need an NPS server, a cloud RADIUS SaaS, or the RADIUS role in your firewall. Cloud PKI just handles the client-side certificate delivery. Our sister guide on enterprise Wi-Fi troubleshooting for 802.1X, WPA3, and Wi-Fi 7 walks through the supplicant configuration side; this section is only about the Cloud PKI–side plumbing.

The single biggest gotcha in 2026: Cloud PKI supports CRL revocation only, not OCSP. If your RADIUS server has Require OCSP checked, every Cloud PKI certificate will be rejected regardless of whether it is valid. On Windows NPS, this is controlled by the Ignore Server Certificate Revocation and OCSP settings under the network policy's Constraints → Authentication Methods → EAP-TLS properties. Configure NPS to validate against the Cloud PKI CRL Distribution Point URL, and make sure your RADIUS server can reach that URL. Cloud PKI CRLs are published to a public HTTPS endpoint, so any RADIUS server sitting behind a firewall must be allowed outbound to the Microsoft CRL host.

The other silent killer is the RADIUS server-name match in your Intune Wi-Fi profile. When Windows Wi-Fi validates the RADIUS server, it checks the Subject/SAN on the RADIUS server certificate against the exact names you listed in the Wi-Fi profile's Server names field. A trailing whitespace, wildcard mismatch, or FQDN casing difference produces silent auth failure with almost no client-side telemetry. Deploy Wi-Fi profiles with the RADIUS server FQDN typed exactly as it appears on the RADIUS cert Subject line.

Sequencing the profiles

Assignment order matters at the platform level, not just the group level. The device must have, in this order, the trusted root profile, the trusted intermediate profile(s), the SCEP client certificate profile, and finally the Wi-Fi profile. If the Wi-Fi profile arrives first, most Windows and Android supplicants cache the failure and stop retrying that SSID until the user manually toggles Wi-Fi off and on. On managed devices, we set the Wi-Fi profile's Applicability rule to require the client cert profile's success indicator. It's a bit of extra config, but it drops repeat tickets on that ticket type close to zero.

Monitoring Cloud PKI: dashboards, reports, and revocation

Every Cloud PKI issuing CA has its own monitor dashboard under Tenant administration → Cloud PKI → <issuing CA> → Monitor. It shows the count of issued, active, expired, and revoked certificates and lets you drill into individual leaf certificates by device or user. Per Microsoft's Cloud PKI monitor documentation, certificate report data can lag issuance by up to 24 hours. So a device that has a certificate visible in certmgr.msc but doesn't appear in the tenant report isn't a failure, it's just report latency. Train your tier-1 to check the device's local store first before opening a ticket.

Revocation is the operation that trips up new Cloud PKI admins. When you revoke a certificate from the monitor dashboard, the CRL is updated within minutes, but the client device doesn't automatically retire the revoked cert. Worse, if the SCEP profile assignment is still in place, the device will simply request a fresh certificate on next check-in. To fully retire a certificate for a leaving employee or a lost device, you must revoke the cert and remove the SCEP profile assignment from that user or device. Otherwise you're just handing them a new one. This is a common source of "we revoked their cert last week and they still connected to Wi-Fi yesterday" incidents.

For metrics-oriented teams, the monitor dashboard's revocation count is the single most useful chart to alert on. A sudden spike in revocations means either a mass off-boarding, a lost-device incident, or (worst case) a compromise where an admin is trying to invalidate certificates in bulk. Wire it into your SIEM as a Cloud PKI issuing CA activity log so it lands next to your Intune audit trail.

Migrating from NDES to Cloud PKI without breaking Wi-Fi

Don't big-bang the migration. Cloud PKI can run in parallel with your existing NDES + ADCS stack; devices can hold certificates from both authorities simultaneously as long as both are trusted by the same RADIUS server. Our recommended cutover pattern for teams migrating in 2026:

Inventory NDES-issued templates. List every certificate template NDES currently issues for Intune, the SANs and EKUs on each, and which Intune groups those SCEP profiles target. Cloud PKI has no template concept, so you must translate template settings into Cloud PKI SCEP profile parameters manually.
Stand up the Cloud PKI issuing CA in BYOCA mode anchored to the same root your RADIUS servers already trust. This is the single move that eliminates the "RADIUS doesn't recognise the new certs" incident class before it starts.
Pilot on a small ring. Deploy a Cloud PKI SCEP profile to 20-50 devices in an IT ring. Verify both certs coexist in certmgr.msc, then use netsh to force EAP-TLS to select the Cloud PKI cert on next Wi-Fi association.
Expand ring by ring, watching your first-call resolution (FCR) rate on Wi-Fi tickets. If FCR drops, you have a chain trust or CRL reachability problem. Pause and fix before rolling further.
Once 100% coverage, remove the NDES SCEP profiles, monitor for two weeks, then decommission the NDES server, the Intune Certificate Connector, and the App Proxy publishing rule.

For teams that also use certificates for Windows Hello for Business, see our Windows Hello for Business troubleshooting guide before flipping the trust type. Cloud PKI can back the certificate trust variant of WHfB, but the cloud Kerberos trust model doesn't use Cloud PKI at all and needs a different remediation path when auth fails.

Metrics to track after cutover

The point of moving off NDES isn't "one less server". It's a measurable reduction in tier-1 handle time on certificate incidents, and if you can't show that number improve, the migration was theatre. These are the five metrics my ops team reviews the month after any Cloud PKI go-live:

MTTR on certificate-tagged tickets. Baseline against the trailing 90 days on the NDES stack. Target: 50% reduction within 30 days of full cutover.
First-call resolution (FCR) on Wi-Fi and VPN tickets. Should improve because tier-1 no longer has to escalate to whoever owns the NDES server. Target: +10 percentage points.
Cloud PKI issued cert count vs Intune-managed device count. If these diverge by more than the report-latency window (24 hours), you have silent SCEP failures. Alert on drift > 2%.
Revocation spike alerting, as noted above. Feed the issuing CA activity log into your SIEM.
Percentage of Wi-Fi/VPN sessions authenticating with Cloud PKI–issued certs, per RADIUS server accounting logs. Once this is above 99%, you have full coverage and can decommission NDES.

If you're also rolling out Intune more broadly, our Intune device enrollment troubleshooting guide covers the enrolment-side incidents that show up alongside a Cloud PKI rollout: enrolment errors, hybrid join failures, and the ESP timeouts that block certificate delivery entirely.

Frequently Asked Questions

Is Cloud PKI included in Microsoft 365 E5?

Yes, as of July 1, 2026. Microsoft announced in December 2025 that Cloud PKI is bundled into Microsoft 365 E5 alongside Endpoint Privilege Management and Enterprise Application Management, with the rollout happening throughout 2026. Before that date, Cloud PKI required either the full Intune Suite license or the Cloud PKI standalone add-on at roughly $2 USD per user per month.

Does Cloud PKI support OCSP?

No. Microsoft Cloud PKI supports revocation checking via CRL Distribution Points only. You must configure your RADIUS servers, VPN concentrators, and any other relying parties to fetch and honour the Cloud PKI CRL URI, and disable any "require OCSP" enforcement on those systems for Cloud PKI–issued certificates.

Can Cloud PKI replace Active Directory Certificate Services entirely?

Only for Intune-managed device certificate use cases. Cloud PKI doesn't sign CSRs from network devices, servers, or other non-Intune endpoints, and it doesn't support code-signing, server auth, or user certificates outside the Intune-managed path. Most enterprises will keep ADCS for those workloads while retiring the NDES-specific portion of the stack.

Why is my Cloud PKI dashboard showing zero certificates when devices already have them?

Report data on the Cloud PKI issuing CA monitor dashboard can lag device issuance by up to 24 hours. If the certificate is visible in the device's Personal store via certmgr.msc but missing from the tenant dashboard, wait a day before treating it as a failure. Only open a ticket if the device local store is also empty.

How do I migrate from NDES to Cloud PKI without breaking Wi-Fi authentication?

Run both systems in parallel during cutover. Stand up a BYOCA issuing CA anchored to the same root your RADIUS servers already trust, deploy Cloud PKI SCEP profiles to a small pilot ring, verify both NDES and Cloud PKI certificates coexist, then expand ring by ring while watching first-call resolution on Wi-Fi tickets. Only remove the NDES SCEP profiles after two full weeks of stable 100% Cloud PKI coverage.