Replacing NDES for SCEP enrollment

What NDES actually is

The Network Device Enrollment Service is Microsoft's implementation of a SCEP server. It is a role of Active Directory Certificate Services: an IIS application that accepts SCEP requests from devices and turns them into certificate requests against your enterprise CA, using a service account and a set of certificate templates.

It exists because AD CS speaks DCOM and RPC to domain-joined Windows machines, and an iPhone on a hotel network speaks neither. NDES is the translation layer.

Why it is awkward

Nothing here is a defect exactly. It is a 2000s-era Windows Server role being asked to do a 2020s job, and the friction adds up:

• It has to be reachable from the internet. Devices enrol from wherever they are. That means a reverse proxy, an application gateway, or Entra application proxy in front of an IIS server that is talking to your CA — a published path from the internet to your PKI, which is exactly the thing your network diagram would rather not contain.
• The service account is fiddly. Registry-level template configuration, SPNs, and enrol permissions on the templates. It works until somebody changes a template, and then the error surfaces as a generic HTTP 500.
• Dynamic challenges do not scale by themselves. NDES hands out one-time passwords through a web page. Automating that for a fleet is what pushed everyone toward connectors and third-party front ends.
• High availability is manual. Two NDES servers is a project, not a checkbox.
• Patching a public-facing Windows Server, forever. Because of the first bullet, this one is not optional.

The result is a component that is genuinely load-bearing — if it is down, no new device gets a certificate — running on infrastructure most teams would rather not expose or maintain.

And the Intune certificate connector

If you are issuing to Intune-managed devices from an on-premises AD CS, there is a second moving part: the Intune Certificate Connector, a Windows service that polls Intune, validates the challenge Intune issued, and forwards the request to NDES.

It buys you real dynamic challenges, which is a meaningful security improvement. It also adds another server, another certificate that expires, another set of outbound firewall rules, and another thing to notice has stopped polling. Teams running this stack usually describe it as working fine and being nobody's favourite.

Your options

Keep NDES. Right if you have heavy AD-integrated certificate policy, need dynamic challenges specifically, or already run this stack well. It is a known quantity.

Move to a hosted SCEP server. The enrollment endpoint, its availability and its patching become somebody else's problem. You keep control of which devices get a profile, what names their certificates carry, and what gets revoked. Nothing of yours needs to face the internet, and there is no service account, no IIS, and no connector.

Run a modern CA yourself. step-ca and EJBCA both do SCEP without IIS, and both are considerable improvements on NDES operationally. You still own the key custody, the CRL schedule and the exposure.

Keeping your own root

The objection worth taking seriously about hosted SCEP is trust: you have an existing root CA, your devices already trust it, and you do not want a second trust anchor — still less one you do not control.

You do not have to accept one. ScepNet can generate an intermediate and hand you a signing request; you sign it with your existing offline root and paste the result back. From then on the certificates issued chain to your root. Your root key never leaves your premises, your devices need no new trust anchor, and you can constrain what the intermediate is permitted to issue for, so it cannot mint a certificate outside your own namespace.

That is the arrangement worth aiming for: the trust anchor — the part that is painful to change later — stays yours, and the internet-facing endpoint that has to be patched every month does not.

Migrating without an outage

1. Stand up the new SCEP endpoint and, if you are keeping your root, sign the new intermediate with it. Nothing on the network changes yet.
2. Add the new issuing CA to what your RADIUS server trusts, and point it at the new CRL location as well as the old one. Both chains are now acceptable.
3. Point one MDM profile group at the new endpoint. Enrol a device, authenticate it, revoke it, confirm the revocation takes effect.
4. Re-target the remaining profile groups in batches. Devices re-enrol on their normal schedule, or immediately if you push the profile.
5. When the old CA has no valid certificates left, stop trusting it and decommission NDES.

The overlap in steps 2–4 is the whole trick: two acceptable chains at once means no device is ever between them. Keep publishing the old CRL until the last certificate under the old CA has expired.

See the documentation on bringing your own root for the specifics.