Common Intune and NDES Misconfigurations and How to Fix Them

Not every Intune and NDES misconfiguration deserves the same level of urgency, some are silent operational annoyances, others are a direct, unguarded path to domain compromise. This is a ranked list, ordered by actual risk, of the misconfigurations we see most often, each with a rating, the real business impact, how to detect it in your own environment, and how to fix it.

For a category-by-category hardening approach rather than a ranked list, see our Microsoft NDES Hardening Guide. For platform-specific certificate mapping mechanics, see Strong Certificate Mapping for Intune, Jamf, NDES, and SCEP.

TL;DR: Key Takeaways

The two most critical misconfigurations both remove a required check entirely: disabling NDES’s password enforcement, and leaving the RA private key or service account over-privileged, either one alone can lead to full domain compromise.
CA-wide policy flags enabled to solve one NDES problem create risk across every other template on that CA: this is the most common way a narrow, well-intentioned fix turns into a broad exposure nobody intended.
Several misconfigurations here are operational, not security failures, and still deserve real attention: a misconfigured challenge password validity period or an outdated Certificate Connector won’t hand an attacker your domain, but they will generate real support tickets and enrollment failures at scale.
Detection is usually a five-minute check once you know exactly where to look: most items on this list can be confirmed or ruled out with a single registry check, console review, or version check, the hard part is knowing to look in the first place.

How We Rated These

Each item is rated Critical, High, Medium, or Low, based on a combination of impact (what actually happens if this misconfiguration is exploited or causes a failure) and likelihood (how often we actually find this in real environments), rather than either factor in isolation. A Critical rating means a realistic path to full domain compromise. High means significant, but more contained, security exposure. Medium means a real functional or partial security gap, most often causing certificate-based authentication to silently fail. Low means a genuine, common annoyance without direct security exposure.

1. EnforcePassword Set to 0 (Critical)

Business impact: anyone with network access to the NDES server can request a certificate with any subject they choose, no authentication required at all, this is a direct, unauthenticated path to certificate-based impersonation.
Detection: check HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP\EnforcePassword, the secure default is 1, a value of 0 means the enrollment password requirement has been removed entirely.
Remediation: set the value back to 1 immediately and restart the NDES service, then audit certificates issued during the exposure window for signs of abuse.

2. Over-Privileged NDES Service Account or Unprotected RA Key (Critical)

Business impact: the Exchange Enrollment Agent certificate’s private key is what lets NDES re-sign enrollment requests, if it’s compromised, or if the service account holding it has excessive rights, an attacker can effectively request a certificate for any identity, including a domain administrator.
Detection: confirm the NDES account isn’t a member of any local Administrators group and has no interactive logon rights, and confirm the RA certificate’s key protection matches the sensitivity described in our NDES hardening guide.
Remediation: reduce the service account to the minimum required rights (Request Certificates on the CA, Enroll on the device template, network logon only), and tighten access controls on the RA key itself.

3. mscep_admin Without SSL or Extended Protection for Authentication (High)

Business impact: without SSL, one-time enrollment challenge passwords transmit in clear text, without EPA, the endpoint is exposed to NTLM relay, since it supports NTLM authentication by default.
Detection: check whether the mscep_admin IIS site enforces HTTPS and has Extended Protection configured, neither is on by default after a standard NDES installation.
Remediation: enforce SSL on the site and enable Extended Protection for Authentication explicitly, this closes both the clear-text exposure and the relay path in one pass.

4. NDES Directly Internet-Facing Without a Reverse Proxy (High)

Business impact: exposing NDES directly to the internet for external or Intune-managed device enrollment puts a server holding highly sensitive RA key material directly in the path of internet-originated traffic.
Detection: review your firewall and network architecture diagrams to confirm what’s actually reachable from outside your network, don’t rely on documentation that may be out of date relative to the current configuration.
Remediation: place a reverse proxy in front of NDES that terminates external connections, consistent with Microsoft’s recommended architecture for Intune-driven device enrollment.

5. CA-Wide Policy Flags Enabled to Work Around an NDES Limitation (High)

Business impact: flags like EDITF_ATTRIBUTESUBJECTALTNAME2, sometimes enabled to solve a specific SAN or enrollment problem for NDES or Intune, apply CA-wide, exposing every other template that CA hosts to the same SAN-spoofing risk, covered in depth in our SAN extension guide.
Detection: run certutil -getreg policy\EditFlags against your CA and check for this and similar flags, don’t assume a flag enabled years ago for a since-forgotten reason isn’t still active.
Remediation: disable the flag and migrate to a properly scoped, template-level solution, typically a dedicated, permission-restricted template with the SAN embedded directly in the request rather than accepted as a CA-wide attribute.

6. Missing Strong Certificate Mapping on Intune or NDES-Issued Certificates (Medium)

Business impact: certificates issued without the required SID or SAN URI strong mapping data fail authentication outright under current enforcement, this shows up as a wave of authentication failures rather than a security breach, but it’s a real, disruptive gap.
Detection: spot-check recently issued device certificates for the expected SAN URI tag (tag:microsoft.com,2022-09-14:sid:) covered in our Intune, Jamf, and NDES mapping guide.
Remediation: confirm your Certificate Connector version and profile configuration actually populate this field correctly, and re-enroll affected devices once corrected, since the fix doesn’t apply retroactively to already-issued certificates.

7. Outdated Intune Certificate Connector Version (Medium)

Business impact: strong mapping support and several issuance bug fixes were introduced in specific connector updates, an outdated connector may silently lack both.
Detection: check the installed Certificate Connector version against Microsoft’s current release documentation, don’t assume “it’s been working fine” means it’s current.
Remediation: update to a current connector version and validate a test enrollment afterward, rather than assuming the update alone resolves any existing certificate population’s gaps.

8. Domain Controllers Below Windows Server 2019 (Medium)

Business impact: offline-issued, SAN URI-mapped certificates from Intune or NDES require domain controllers on Server 2019 or later to be correctly recognized as strongly mapped, older domain controllers can accept the certificate while still logging it as unmapped.
Detection: confirm the OS version of every domain controller in scope for certificate-based authentication, not just your most recently deployed ones.
Remediation: prioritize upgrading or replacing domain controllers below this version, this is an infrastructure dependency no certificate-side configuration change can work around.

9. No MSCEP Registry Monitoring (Low-Medium)

Business impact: doesn’t cause a breach on its own, but significantly delays detection of tampering with NDES’s core configuration, this is a visibility gap, not an active exposure.
Detection: check whether object access auditing is enabled on the MSCEP registry key and whether anything actually alerts on changes to it.
Remediation: enable auditing and build alerting on Event ID 4657 for the key template values, covered in detail in our NDES hardening guide.

10. Misconfigured Challenge Password Validity Period (Low)

Business impact: a validity period set to zero or an unreasonably short window causes enrollment failures that look unrelated to the actual cause, generating support tickets rather than a security incident.
Detection: check the ValidityPeriod and ValidityPeriodUnits registry values under the MSCEP key, and confirm clock synchronization between NDES, domain controllers, and requesting devices.
Remediation: correct the values to a sensible window (commonly a small number of hours) and confirm no Group Policy is silently overwriting them afterward.

How Encryption Consulting Can Help

Knowing which misconfigurations actually matter most, and confirming whether they exist in your specific environment, is the difference between a triage list and a genuine risk reduction plan.

Encryption Consulting’s PKI Services team supports this directly:

Intune and NDES misconfiguration assessment: systematically checking your environment against this list and the broader hardening practices it’s drawn from.
Risk-based remediation planning: helping you sequence fixes by actual severity rather than working through an undifferentiated checklist.
CA-wide policy flag audits: identifying flags like EDITF_ATTRIBUTESUBJECTALTNAME2 that may have been enabled years ago for a since-forgotten reason.
Certificate Connector and domain controller readiness review, confirming your infrastructure actually supports the strong mapping enforcement your certificates depend on.
Ongoing monitoring design, building the detection capability this list depends on into your standing operations, not just a one-time check.

If you want your Intune and NDES environment assessed against this exact list, our PKI Services team can do it.

Conclusion

Most organizations running Intune and NDES have at least one item from this list somewhere in their environment, the two Critical items deserve immediate attention if present, the High items close real security gaps, and the Medium and Low items are worth fixing even though they’re less urgent, since they compound into real operational cost over time. Work down this list in order, confirm each item against your actual configuration rather than assuming it’s fine, and treat this as a starting triage, not a complete audit.

Want your Intune and NDES environment assessed against this exact list? Talk to our PKI Services team for a misconfiguration review. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What is the single most critical NDES misconfiguration to check for? The EnforcePassword registry value under HKLM\SOFTWARE\Microsoft\Cryptography\MSCEP being set to 0. This removes the authentication requirement for retrieving a one-time SCEP enrollment password entirely, allowing anyone with network access to the NDES server to request a certificate with a subject of their own choosing.

How is risk rated for these Intune and NDES misconfigurations? Each item is rated Critical, High, Medium, or Low based on a combination of impact (what happens if the misconfiguration is exploited or causes a failure) and likelihood (how frequently it’s actually found in real environments), rather than either factor alone.

Why does outdated Intune Certificate Connector version matter for security? Strong certificate mapping support for Intune-issued certificates, along with several issuance bug fixes, was added in specific connector updates. Running an outdated connector version means certificates may lack the strong mapping data required for authentication to succeed under current enforcement, or may carry other unresolved issuance defects.

Can NDES misconfigurations be exploited without directly compromising the NDES server itself? Yes. CA-wide policy flags like EDITF_ATTRIBUTESUBJECTALTNAME2, enabled to work around an NDES or Intune enrollment limitation, expose every template on that CA to SAN spoofing, not just the specific NDES workflow the flag was originally enabled to support.

What’s the difference between this list and a general NDES hardening guide? A hardening guide is organized by configuration area and tells you how to build NDES correctly from the start. This is a ranked list organized by actual observed risk, intended for triage: which misconfigurations to check for first in an existing environment, and how severe each one actually is.