Intune NDES connector: why SCEP requests fail, and whether you still need it

Certificate delivery through the Intune NDES connector breaks in ways that produce no useful error on the device. Reading the device log and working backwards fails, because the device only ever sees a generic profile failure while the real cause sits three hops away in a certificate template, a registry value or a missing SAN attribute. What follows is the chain as Microsoft documents it, the four places it actually breaks, and the licence change that has made rebuilding on NDES the wrong default.

There is a second question underneath the first, and it is now the more important of the two. Microsoft moved Cloud PKI across into Microsoft 365 E5 on 1 July 2026, which is covered separately in Intune Cloud PKI cost. If you hold E5, the correct response to a broken NDES server is often to decommission it rather than repair it. The rest of this page assumes you still need to know how the chain works, because plenty of tenants do.

One disclosure before the detail. I have not run an NDES deployment in production. My tenant is a lab with no enrolled devices, so every factual claim below is taken from Microsoft’s current documentation and verified on 12 September 2026, and the judgement section at the end is labelled as judgement rather than measurement.

What the Intune NDES connector actually does

The connector is not a certificate authority and it issues nothing. It validates. Microsoft’s current name for the component is the Certificate Connector for Microsoft Intune, and it installs a policy module alongside the Network Device Enrollment Service on the same server. When a device presents a SCEP request, NDES hands it to the policy module, the module checks the challenge against Intune to confirm the request matches a profile genuinely assigned to that device, and only then does NDES ask the certificate authority to issue on the device’s behalf.

Three consequences follow, and every one of them is a source of confusion later. The device is never in contact with the CA, so it cannot report anything the CA said. A device showing a failed profile may have been refused by Intune, by the policy module, by IIS or by the CA, and it has no way to tell you which. And the connector must not sit on the issuing CA itself, which Microsoft documents as unsupported, so the chain always crosses at least one server boundary.

Devices also make three separate calls to the NDES server rather than one. That matters the moment someone puts a load balancer in front of it without session affinity.

The infrastructure requirements people skip

The full list is on Microsoft’s SCEP infrastructure page and it is long. These are the entries that cause failures weeks later rather than at install time.

• The NDES service account must be a member of the local IIS_IUSRS group, and must hold both Read and Enroll on the SCEP template. Enroll on its own is not enough.
• The template must be a version 2 template with the subject name supplied in the request. A template that builds the subject from Active Directory will refuse every request that arrives.
• Certificate validity must be five days or greater. Microsoft warns that shorter periods risk the certificate expiring or being rejected before it is installed.
• NDES cannot be a domain controller, and must be domain joined in the same forest as the enterprise CA.
• A third party reverse proxy must support GET requests with a URI up to 40 KB, and pre-authentication must be set to passthrough. This is the requirement that fails silently on appliances tuned for ordinary web traffic.
• Internet Explorer Enhanced Security Configuration must be disabled on both the NDES server and the connector server.

The SCEP Server URL in the Intune profile points at the NDES endpoint directly, in the form Microsoft documents:

1# The SCEP Server URL as it goes into the Intune SCEP profile.
2# HTTPS is mandatory for every Android management mode, not just recommended.
3https://ndes.contoso.com/certsrv/mscep/mscep.dll

The failure modes

The SID extension that decides whether authentication works at all

This is the one that catches established deployments rather than new ones, and it is the most expensive item on the page. The Key Distribution Center requires user and device objects to be strongly mapped to Active Directory for certificate-based authentication, which means the certificate’s subject alternative name must carry a security identifier extension matching the object’s SID. Microsoft is explicit that strong mapping is required for all certificates deployed by Intune and used for certificate-based authentication against the KDC. It applies to user certificates on every platform, and to device certificates only on Microsoft Entra hybrid joined Windows devices.

The fix is one attribute in the SCEP profile, and it is easy to miss because nothing warns you that it is absent:

1# Add this variable to the SAN in the SCEP certificate profile, as a URI attribute.
2OnpremisesSecurityIdentifier
3# Intune then appends the resolved SID to the SAN in this form.
4tag:microsoft.com,2022-09-14:sid:<resolved sid>

The prerequisite is that the users and devices are synced from Active Directory to Entra ID, because there is otherwise no SID to resolve. The reason this costs so much time is the shape of the failure. A certificate issued without the extension installs cleanly, reports as delivered in Intune, and then fails authentication at the domain controller. Every Intune-side indicator says the deployment worked.

The iOS and macOS renewal that never retries

Renewal on iOS, iPadOS and macOS happens only during the renewal threshold window, and only while the device is unlocked and syncing with Intune. If that attempt fails, Microsoft documents the outcome plainly: the expired certificate stays on the device, Intune does not trigger a renewal again, and there is no option to redeploy an expired certificate. The documented recovery is to exclude the affected devices from the SCEP profile temporarily so the expired certificate is removed, then let them request a new one.

The renewal threshold is expressed as the percentage of lifetime remaining, so a threshold of 20 attempts renewal once the certificate is 80 per cent through its life. A short lifetime combined with a low threshold leaves a narrow window, and a device that spends its week locked in a drawer will miss it.

CryptographicException in the registration point log

The Intune NDES connector writes its own registry keys on first start. If they are missing, validation throws before the request ever reaches the CA, and the exception is specific enough to search for:

1# From CertificateRegistrationPoint_xx_xx.svclog on the NDES server.
2System.Security.Cryptography.CryptographicException: m_safeCertContext is an invalid handle.
3   at Microsoft.ConfigurationManager.CertRegPoint.Helper.ValidateChallenge(...)

Microsoft’s documented cause is missing registry keys under HKLMSoftwareMicrosoftMicrosoftIntuneNDESConnector. The first resolution is to restart the Intune Connector Service and confirm the keys appear. The second, for the cases where they do not, is to reset the MSCEP template values to the IPSECIntermediateOffline default, restart the server, and reapply the custom template name once the keys exist. The log itself sits under C:Program FilesMicrosoft IntuneNDESConnectorSvcLogsLogs.

Android 11 and the trusted root that will not install

From Android 11, a trusted certificate profile can no longer install the trusted root certificate on devices enrolled as Android device administrator, with Samsung Knox the exception. Without the root there is no chain, so the SCEP certificate is rejected on arrival and the symptom looks like a certificate problem rather than an enrolment one. Android device administrator management is deprecated for devices with Google Mobile Services in any case, so the real answer here is a change of management mode, not a change of template.

How to tell whether the chain is working

Read the NDES server rather than the device, and look for the success markers instead of the errors. Microsoft documents the exact strings, which turns this into a search rather than an interpretation:

1# NDESPlugin log, on a request that passed validation.
2Verify challenge returns true
3Exiting VerifyRequest with 0x0
4# CertificateRegistrationPoint.svclog, same request.
5Validation Phase 1 finished with status True.
6Validation Phase 3 finished with status True.
7VerifyRequest Finished with status True
8# IIS log, the request arriving at the policy module.
9POST /CertificateRegistrationSvc/Certificate/VerifyRequest - 443 - NDES_Plugin - 201

If those entries are absent, the request never reached the policy module, which puts the fault in front of NDES: profile assignment, the reverse proxy, or the device’s network path. If they are present and the certificate still does not arrive, the fault is behind NDES, in the template permissions or on the CA. That single split saves more time than any individual error lookup, and it is the same discipline as working through the Intune device not syncing diagnosis order: establish the last boundary the request definitely crossed, then stop guessing about everything on the far side of it.

Whether you still need NDES at all

Microsoft Cloud PKI is the managed alternative, and it removes the NDES server, the connector, the reverse proxy and the certificate templates from the picture entirely. Microsoft’s Cloud PKI documentation describes it as an Intune Suite feature, and since 1 July 2026 it has been included with Microsoft 365 E5, as part of the same change that moved Endpoint Privilege Management into E5.

That inverts the old argument. For years the case for NDES was that it came free with a Windows Server licence you already owned, while the managed option was a per user add-on nobody had budgeted for. For an E5 tenant that case has gone, and what is left is a set of servers to patch in exchange for nothing.

One documented limitation settles the remaining cases. Microsoft states that Cloud PKI issues certificates only to devices that are MDM enrolled. So NDES survives exactly where you need to issue to something Intune does not manage.

What I would do differently

This section is judgement, and I have flagged it as such because I have not operated an NDES estate at scale.

I would stop treating NDES as the default and make it the exception that has to be argued for. The requirements list above is a meaningful amount of infrastructure for a function now included in a licence a large number of organisations already hold. If someone proposed building it new today in an E5 tenant, I would want the specific non-enrolled device that requires it named in writing first, because that one line is the entire justification.

Where the Intune NDES connector stays, I would add the SID extension to every SCEP profile now rather than waiting for an enforcement date, on the grounds that the failure is silent and the remedy is a single attribute. I would also lengthen certificate lifetimes on iOS and macOS rather than shorten them, which runs against the usual security instinct. The renewal path on those platforms has no retry, so a longer life with a wider threshold window is more reliable than a short one that expires while the device is locked in a bag.

The thing I would not do is publish NDES through a reverse proxy whose configuration I do not control. Most appliance owners cannot confirm the 40 KB URI behaviour quickly, and when it is wrong the symptom is indistinguishable from a certificate template fault, so the investigation starts in the wrong place and stays there.

Certificates are an input to authentication, so the policy consuming them deserves equal scrutiny. The failure modes on that side are in the Conditional Access policy design guide.

Last verified: 12 September 2026.