NDES Replacement: Modern SCEP Without the Windows Service

What NDES Is, Technically

The Network Device Enrollment Service is a Microsoft implementation of SCEP (Simple Certificate Enrollment Protocol, RFC 8894) that fronts Active Directory Certificate Services. Architecturally, it is:

• An IIS web application running on a Windows Server
• Backed by a service account with permission to issue against specific ADCS templates
• Holding a Registration Authority (RA) certificate it uses to sign responses
• Reached by devices via an HTTP URL (typically https://ndes.example.com/certsrv/mscep/)
• Serving three endpoints: GetCACaps, GetCACert, and PKIOperation

Devices (iPhones, Android, Intune-enrolled Windows, Jamf-managed Macs, FortiGates, IoT gateways) that need a cert from your internal CA talk to NDES. NDES validates the request, forwards it to ADCS, gets the signed cert back, and returns it to the device.

In Microsoft's intended architecture, NDES is a translator between SCEP (what devices speak) and ADCS (what the CA speaks). In your architecture, it is a production bottleneck.

Why NDES Keeps Breaking

Three classes of production problem, in order of frequency:

Service-account password rotation

NDES authenticates to ADCS using an Active Directory service account with specific permissions. The service account's password is subject to your Active Directory password policy. When the policy rotates passwords (90, 180, 365 days), the NDES service account's password rotates. If the operator doesn't update IIS to use the new password, NDES fails to authenticate to ADCS, and SCEP breaks for the entire fleet.

The fix is "set the service account to password-never-expires," which is itself a finding in most audits.

RA certificate expiry

NDES uses an RA certificate to sign SCEP responses. That certificate is issued (by default) with a 2-year validity. When the RA cert expires, every SCEP response NDES returns fails signature verification. Devices stop renewing. Nobody notices for a few days because new enrollments are rare; then renewals start failing en masse.

The fix is a Windows scheduled task that monitors the RA cert and re-enrolls it before expiry. Teams write this once, forget about it, discover it is broken in year three.

IIS and the Windows reboot problem

NDES runs on IIS, which runs on Windows Server, which gets patched monthly. Monthly patches often require reboots. If NDES is the only SCEP endpoint in your architecture, every Windows reboot is a planned SCEP outage. Teams work around this with load-balanced NDES pairs (now two services to maintain, two RA certs, two service accounts) or by scheduling patches during low-enrollment windows.

Then there is the long tail: NDES documentation that assumes Windows Server 2012 R2 defaults, HSM drivers that don't work on current Windows versions, Internet Explorer prerequisites that nobody checks anymore, and the general vibe that NDES was built in 2010 and has not been meaningfully modernised since.

What Replaces NDES

A SCEP server that is not a Windows service.

Specifically: SCEP endpoints served by your CA directly, with no RA pattern, no service-account auth, no IIS, no Windows reboot in the enrollment path. The CA speaks SCEP natively. Devices point to the CA. One hop.

TigerTrust's SCEP server is this. It is a Go service that implements RFC 8894 as a first-class protocol - not translated through ADCS, not fronted by IIS. It issues against the same profiles that back your ACME, EST, and REST issuance, so an operator doesn't maintain two sets of policy for "web certs" and "device certs."

What NDES does, TigerTrust does inline:

The Microsoft Intune Case

Most teams running NDES in 2026 are running it specifically for Microsoft Intune. Intune's SCEP integration historically assumed NDES as the CA frontend. The flow:

1. Intune pushes a SCEP profile to the enrolled device
2. The device sends a CSR to NDES
3. NDES asks the Intune Service Connector for authorisation (does Intune actually want this device to have this cert?)
4. If authorised, NDES forwards to ADCS, gets the cert, returns to the device

TigerTrust supports Intune natively without NDES. The flow becomes:

1. Intune pushes a SCEP profile to the enrolled device (unchanged)
2. The device sends a CSR to TigerTrust's SCEP endpoint
3. TigerTrust calls the Microsoft Graph API directly to check device compliance
4. If compliant, TigerTrust issues; if not, the request is rejected

The Intune Service Connector in the middle - which required its own IIS install and its own TLS cert - is also gone. Your Intune / SCEP architecture goes from three Windows services to zero.

How the Migration Works

NDES retirement is straightforward because SCEP is a protocol with a stable URL contract. Four steps:

1. Stand up the new SCEP endpoint

Deploy TigerTrust's SCEP server (managed or self-hosted) with a profile that mirrors the NDES-fronted ADCS template. The profile covers EKU, SAN rules, validity, and the challenge mechanism.

2. Dual-publish the URL

Update your MDM, 802.1X, or device-provisioning configuration to publish both URLs during the transition - the old NDES URL and the new TigerTrust SCEP URL. Older devices continue to enroll via NDES; new or re-enrolled devices use the new URL.

3. Flip renewals

As devices come up for renewal, their SCEP profile already points at the new URL. The renewal succeeds against TigerTrust. The old cert expires naturally.

4. Retire NDES

Once the last cert issued by the NDES-fronted ADCS has rolled over, NDES has nothing to do. Decommission the service, remove the service account, re-use the Windows Server VM for something else. ADCS itself can also retire at this point - see the pillar ADCS migration guide for the full flow.

The Compliance Delta

NDES has three audit-adjacent properties that TigerTrust SCEP does not:

Service-account passwords. Service accounts with permission to issue certificates are a privileged-access concern. CyberArk / PAM policies get written specifically to govern them. Removing the service account removes a PAM scope.

Logs in the Windows event log. Issuance evidence lives in a rotating log on a server. SOC 2 CC7.2 ("the entity monitors system components and the operation of those components") is easier to document when evidence is streamed to a SIEM than when it rotates in an event log.

OS patching posture. NDES inherits the Windows Server OS patch cadence. A SCEP endpoint on a managed service inherits the provider's cadence (continuous for TigerTrust-managed; your container-platform cadence for self-hosted).

If any of these three show up in your compliance program, the NDES retirement pays for itself before the certificate migration completes.

Related Reading

• Migrating off Microsoft ADCS - the pillar guide
• Shadow ADCS: the coexistence pattern - the migration pattern NDES retirement fits into
• ADCS Migration solution - product-side walkthrough
• TigerTrust vs Microsoft ADCS - side-by-side comparison