Microsoft NDES Hardening Guide

NDES is usually the single most exposed piece of an AD CS deployment, the whole point of it is to issue certificates to devices that can’t do standard domain-authenticated enrollment, which means it’s reachable from places your CA itself never has to be. And the stakes are higher than they look: if the private key behind NDES’s re-signing certificate is ever compromised, an attacker can request a certificate for any identity they choose, including a domain administrator, and use it to authenticate without ever touching that account’s actual credentials. This is a complete hardening guide across nine areas, with specific attention to what matters most for Intune-driven device certificate deployments.

This builds on our existing NDES Security Best Practices guide and connects directly to Strong Certificate Mapping for Intune, Jamf, NDES, and SCEP and ADCS Attack Path Visualization for Defenders.

TL;DR: Key Takeaways

The NDES service account needs narrow, specific rights, not administrative ones: request certificate permission on the CA, enroll permission on the device template, and network logon rights only, never local administrator membership or interactive logon.
The RA certificate’s private key is the single most consequential thing to protect on this server: compromise of the Exchange Enrollment Agent certificate’s key allows an attacker to request a certificate for any subject at all, a direct path to domain compromise.
SSL and Extended Protection for Authentication are not on by default: without them, challenge passwords transmit in clear text and the mscep_admin endpoint is exposed to NTLM relay, both need to be explicitly configured.
Never set EnforcePassword to 0: this single registry change removes the authentication requirement for retrieving a one-time enrollment password entirely, letting anyone with network access request a certificate with a subject of their choosing.
The MSCEP registry key is a genuinely high-value, low-noise monitoring target: its template values should never change after deployment, making any modification, or any change to its permissions, a reliable, low-false-positive detection signal.

Service Accounts

Grant only what NDES actually needs: Request Certificates permission on the CA, Enroll permission on the device certificate template, and Access this computer from the network (logon type 3) on the NDES server itself, nothing more.
Never make the NDES account a local administrator or grant it interactive logon rights, on the NDES host or anywhere else, this account has no legitimate need for either.
Use a group Managed Service Account where possible, this is the preferred option specifically because it removes password management from the equation entirely.
If a domain user account is used instead, harden it deliberately: enforce AES encryption for its Kerberos tickets, use a long, unique password, apply logon restrictions scoping exactly where it can authenticate, and never reuse this account for any other service.

RA Certificates

Understand the two certificates NDES depends on: a CEP Encryption certificate, used to apply SCEP-specific encryption to communication with requesting clients, and an Exchange Enrollment Agent (Offline Request) certificate, which NDES uses to digitally re-sign enrollment requests before forwarding them to the issuing CA.
Treat the Enrollment Agent certificate’s private key as one of your highest-value assets in the entire environment: whoever holds it can effectively vouch for any certificate subject, including a domain administrator, and that certificate can be used for PKINIT-based authentication without needing that account’s actual credentials at all.
Restrict access to this key as tightly as you would a CA’s own private key, and monitor for unexpected renewal, reissuance, or export activity involving it, this deserves the same level of scrutiny as your CA hierarchy’s own key material.
Consider a longer-validity custom template for device certificates where appropriate, the default IPsec (Offline Request) template carries only a one-year validity period, a version 2 template with a two-year validity reduces management overhead for large device populations without meaningfully increasing risk.

IIS

Understand the two virtual applications NDES creates: mscep, used for client interaction and actual certificate requests, and mscep_admin, used specifically for challenge password generation, both run in the SCEP application pool under the NDES service account’s identity.
Enable SSL explicitly, it is not on by default, without it, challenge passwords retrieved through mscep_admin are transmitted in clear text, a meaningful exposure for a value that’s supposed to function as a one-time authentication secret.
Enable Extended Protection for Authentication explicitly, it is not on by default either, mscep_admin supports NTLM authentication out of the box, without EPA it’s exposed to NTLM relay attacks, the same fundamental risk covered in our attack path guidance’s web enrollment section.
Restrict access to mscep_admin beyond its default configuration, by default it’s accessible to domain and enterprise admins along with the NDES service account, review this against the principle of least privilege for your specific environment rather than assuming the default is appropriately scoped.

Permissions

Restrict local administrator membership on the NDES host to a dedicated PKI Admins group, and grant interactive, remote interactive, batch, and service logon rights solely to that group, not broadly to IT staff or general server administrators.
Never set EnforcePassword to 0 under HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP, its default value of 1 requires authentication to retrieve a one-time enrollment password, setting it to 0 removes that requirement entirely, allowing anyone with network access to request a certificate with a subject of their own choosing.
Never set the CA-wide EDITF_ATTRIBUTEENDDATE policy flag, this is a global setting that stops your CA from enforcing certificate validity periods across every template it hosts, not an NDES-specific setting, but one that comes up in the same hardening conversation and deserves the same firm “never” treatment.
Apply explicit ACL hardening to the MSCEP registry key itself, restricting write access to only the accounts and processes that genuinely need it, this is what makes the monitoring approach covered later in this guide actually meaningful.

Network Placement

Don’t expose NDES directly to the internet, for Intune-managed or other external device enrollment scenarios, place a reverse proxy in front of it that terminates external connections, consistent with Microsoft’s recommended architecture for this exact use case.
Segment the NDES host appropriately within your internal network, treating it with a security posture closer to your CA infrastructure than to a general application server, given what compromising its RA key would actually enable.
Confirm firewall rules reflect only the traffic NDES genuinely needs to send and receive, rather than broad, convenience-driven allowances that outlive the specific reason they were originally configured.

Enrollment Challenge Handling

Confirm the challenge password validity period is configured sensibly, governed by the ValidityPeriod and ValidityPeriodUnits registry values under the MSCEP key, commonly set to a small number of hours, values that resolve to zero or an unreasonably short window produce confusing enrollment failures that look unrelated to the actual cause.
Keep the NDES server’s clock synchronized with your domain controllers and requesting devices, challenge expiration is time-sensitive, and a clock sync issue can make a freshly generated password appear expired the moment it’s created, verify with w32tm /query /status if you’re troubleshooting unexpected expiration.
Rely on SSL, covered above, to protect the password in transit, a challenge password’s entire security value depends on it not being intercepted between generation and use.
Confirm no Group Policy or deployment script is silently overwriting these registry values, this is a documented, real cause of unexpected challenge expiration in hardened environments where a well-intentioned policy conflicts with NDES’s own configuration requirements.

Patching

Keep the underlying OS, IIS, and AD CS role current, including the specific CVEs covered elsewhere in our series, an unpatched NDES server carries every general AD CS risk in addition to its own specific exposure.
Keep the Intune Certificate Connector version current if you’re using Intune for device management, strong certificate mapping support for Intune-issued certificates depends on running a sufficiently current connector version, covered in more depth in our Intune and Jamf strong mapping guide.
Track patch currency for NDES specifically, not just the broader server, its exposure profile is different enough from a typical domain-joined server that it deserves its own explicit place in your patch management tracking.

Logging

Recognize that NDES’s native logging is genuinely thin, don’t assume default IIS and Windows event logging alone gives you sufficient visibility into what’s happening on this server, particularly for the kind of tampering that would precede a real compromise.
Enable and retain IIS logs for both the mscep and mscep_admin applications, this is your primary record of actual enrollment and challenge-password request activity.
Enable object access auditing on the MSCEP registry key specifically, this is what makes the monitoring approach below possible at all, native logging won’t surface registry tampering without this explicitly configured.

Monitoring

Alert on every Event ID 4657 tied to the EncryptionTemplate, GeneralPurposeTemplate, or SignatureTemplate values under the MSCEP key, rather than trying to tune out routine noise, these values should remain completely static after deployment, so their expected legitimate change volume is effectively zero, making this an unusually high-value, low-false-positive alert.
Correlate a fired alert with Event ID 4670, which records a permissions change on the same object, seeing both together is a strong signal someone modified the ACL you deliberately hardened, not just the value itself.
Correlate against IIS application pool recycles or service restarts occurring shortly after a flagged change, this is a corroborating signal worth checking, a configuration change that’s followed by a service cycle is more likely to represent a genuine reconfiguration attempt than an isolated, inconsequential registry read.
Establish a baseline before treating every MSCEP-path change as an incident, some values beyond the three specifically called out may legitimately update during normal operation, know your environment’s actual baseline before tuning alert sensitivity.
Stop the NDES service when it’s not actively needed, this prevents unauthorized issuance during that window and clears any cached, unused one-time passwords from the service, a simple, low-effort operational control worth building into your standard practice rather than reserving for incident response.

How Encryption Consulting Can Help

NDES sits at an unusual intersection: it needs to be reachable enough to actually serve device enrollment, especially for Intune-managed fleets, while protecting a certificate that, if compromised, opens a direct path to domain-wide impersonation. Getting that balance right takes more than a default installation.

Encryption Consulting’s PKI Services team supports this directly:

NDES hardening assessment: reviewing your service account configuration, RA certificate protection, IIS settings, and registry permissions against the full set of practices covered here.
Intune and MDM enrollment architecture review: confirming your NDES network placement, reverse proxy configuration, and Certificate Connector version support your actual device enrollment needs securely.
Monitoring and detection implementation: building the MSCEP registry monitoring and correlation logic covered in this guide into your actual SIEM environment.
RA key protection design, ensuring your Exchange Enrollment Agent certificate’s private key is protected with the rigor its actual risk profile warrants.
Ongoing NDES governance, integrated into your broader continuous PKI risk assessment practice, so configuration drift on this specific, high-value server doesn’t go unnoticed.

If you’re running NDES for Intune or other device enrollment and haven’t had it specifically hardened and reviewed, our PKI Services team can assess and secure it.

Conclusion

NDES is a small piece of infrastructure with an outsized blast radius if it’s compromised, protecting the RA certificate’s private key, locking down service account permissions, enforcing SSL and EPA that aren’t on by default, and monitoring the MSCEP registry key are what actually stand between a routine device enrollment service and a path to full domain impersonation. Work through all nine areas here deliberately, they compound, a hardened service account doesn’t help much if the RA key itself is left unprotected, and neither matters if the server is directly internet-facing without a reverse proxy in front of it.

Running NDES for Intune or device enrollment and want it properly hardened? Talk to our PKI Services team about an assessment. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What permissions does the NDES service account actually need? The NDES account needs Request Certificates permission on the CA, Enroll permission on the device certificate template, and Access this computer from the network (logon type 3) rights on the NDES server itself. It should never be a member of any local Administrators group and never requires interactive logon rights.

Why is the NDES RA certificate’s private key so sensitive? The Exchange Enrollment Agent (Offline Request) certificate is what NDES uses to digitally re-sign enrollment requests before forwarding them to the issuing CA. If its private key is compromised, an attacker can request a certificate with any subject of their choosing, including a domain administrator, and use it for PKINIT-based authentication without ever touching that account’s actual credentials.

Does NDES enforce SSL and Extended Protection for Authentication by default? No, neither is enabled by default. Without SSL, SCEP challenge passwords retrieved through the mscep_admin endpoint are transmitted in clear text. Without Extended Protection for Authentication, the mscep_admin endpoint, which supports NTLM authentication by default, is vulnerable to NTLM relay attacks. Both need to be explicitly enabled.

Should NDES be directly exposed to the internet for Intune device enrollment? No. NDES should sit behind a reverse proxy that terminates external connections rather than being directly internet-facing, consistent with Microsoft’s recommended architecture for supporting external or Intune-managed device enrollment.

What’s a high-value, low-noise registry location to monitor on an NDES server? The MSCEP registry key (HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP), specifically the EncryptionTemplate, GeneralPurposeTemplate, and SignatureTemplate values. These should remain static after deployment, so any change to them, or to their permissions, is a strong signal worth immediate investigation.