NDES and SCEP Explained: The Backbone of Automated Certificate Enrollment

As organizations accelerate adoption of Zero Trust, device authentication, and cloud-managed infrastructure, traditional manual certificate enrollment is no longer scalable. Whether onboarding thousands of laptops via Intune, issuing certificates for VPN access, or enabling Wi-Fi authentication across global offices, automated certificate enrollment is essential.

This is where SCEP (Simple Certificate Enrollment Protocol) and NDES (Network Device Enrollment Service) play a critical role in Microsoft PKI ecosystems. Despite their importance, many administrators deploy them without fully understanding how they work, how they differ, or how to secure them properly. Misconfigured NDES servers remain one of the most common PKI weaknesses discovered during security audits.

Quick Answer: What Are NDES and SCEP?

SCEP (Simple Certificate Enrollment Protocol) is the protocol that allows devices to request certificates over HTTP/HTTPS without joining Active Directory. NDES (Network Device Enrollment Service) is Microsoft’s implementation of SCEP, acting as the bridge between SCEP-speaking devices and ADCS. Without NDES, Intune and MDM platforms cannot issue certificates from an on-premises CA.

Key Takeaways

• NDES is the required bridge between SCEP-speaking devices (Intune-managed endpoints, IoT devices, VPN gateways, network appliances) and Microsoft ADCS. Without NDES, these devices cannot obtain certificates from an on-premises CA.
• Misconfigured NDES servers are one of the most commonly exploited PKI attack surfaces. An internet-exposed NDES endpoint, an over-privileged service account, or a weak certificate template can each independently lead to unauthorized certificate issuance.
• According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of all enterprises experienced certificate-related downtime in the past year. A misconfigured or unavailable NDES server breaks device authentication across an entire organization simultaneously.
• The CA/Browser Forum’s Ballot SC-081v3 (April 2025) reduces maximum public TLS certificate validity to 47 days by March 2029. This makes automated SCEP/NDES enrollment and CLM tooling essential; manual renewal cannot support this cadence at device fleet scale.
• SCEP and NDES are not being replaced by ACME; they serve different use cases. SCEP/NDES handles device certificates for Intune, VPN, and network appliances. ACME handles server and workload certificates for DevOps pipelines, Kubernetes, and cloud-native services. Most enterprises need both.

Who Should Care About NDES and SCEP

NDES deployment and security is a cross-functional responsibility. Every role below has a direct stake in getting it right.

Role	Why It Matters	Action Item
PKI Admins	Own NDES server deployment, certificate template configuration for SCEP, CA enrollment agent setup, and CA policy enforcement for NDES-issued certificates	Deploy NDES on a dedicated server (not the CA); configure templates with correct Key Usage, EKU, and no exportable private keys; integrate CA issuance logs with SIEM
Security Architects	Own the network isolation design, IIS hardening standards, and NDES service account privilege model that determine the attack surface of the NDES deployment	Place NDES in a DMZ behind a reverse proxy or application gateway; enforce least-privilege for the NDES service account; define certificate template ACLs restricting SCEP enrollment to authorized devices
Platform / Endpoint Teams	Own the Intune, MDM, and device management integration that depends on NDES for certificate delivery to managed devices	Configure Intune SCEP profiles pointing to NDES HTTPS endpoint; test certificate delivery to device types (Windows, iOS, Android, macOS); confirm device trust store includes the issuing CA root
Compliance Teams	Must demonstrate that certificate issuance via NDES is logged, monitored, and auditable; NDES is a critical control point for certificate-based authentication evidence	Confirm CA issuance logs capture all SCEP-enrolled certificates; integrate NDES IIS logs with SIEM; include NDES-issued certificates in quarterly certificate inventory and audit scope
CISOs	Own the risk register entry for NDES as a high-value attack surface, because NDES compromise enables unauthorized certificate issuance usable for authentication and lateral movement	Require NDES to be assessed in any PKI security audit; fund CLM tooling for unified visibility over NDES-issued certificates; include NDES availability in PKI resilience reporting

What Is SCEP?

SCEP, or Simple Certificate Enrollment Protocol, is a protocol originally developed by Cisco to automate certificate enrollment for network devices that cannot easily join Active Directory. Unlike traditional AD-based enrollment methods, SCEP allows devices to request certificates using HTTP/HTTPS, authenticate using a shared secret or challenge password, and automatically retrieve signed certificates.

SCEP was designed for devices such as routers and switches, VPN gateways, network appliances, IoT devices, and mobile devices. Over time, it has evolved into the de facto standard for certificate enrollment in device management platforms, including Microsoft Intune and many MDM solutions.

What Is NDES?

NDES (Network Device Enrollment Service) is Microsoft’s implementation of SCEP. It acts as a bridge between devices and the Microsoft Certification Authority, allowing devices that cannot authenticate via Active Directory to still obtain certificates securely. Without NDES, SCEP cannot be used with Microsoft ADCS.

In simple terms, this is how it works:

1. Devices talk to NDES using SCEP
2. NDES validates the request
3. NDES submits the request to Microsoft CA
4. The CA issues the certificate
5. NDES delivers it back to the device

Prerequisites Before Deploying NDES

Before deploying NDES, confirm each of the following is in place. A missing prerequisite is the most common cause of NDES installation failures and post-deployment enrollment errors.

Prerequisite	Requirement	Validation Check	Common Error if Missing	Owner
ADCS environment	At least one issuing CA running on Windows Server 2012 R2 or later; root CA accessible for chain validation	Run certutil -ping against the CA from the NDES server to confirm RPC connectivity	NDES setup fails with “The Certification Authority cannot be reached” error during configuration	PKI Admin
Dedicated NDES server	Windows Server 2016 or later; NDES must NOT be installed on the CA server itself; IIS must be installed before NDES role	Confirm server is domain-joined and IIS Default Web Site is running before NDES role installation	If installed on CA, NDES will conflict with CA RPC listeners; installation may succeed but enrollment fails at runtime	PKI Admin
NDES service account	Dedicated domain account (not a domain admin); must be in local IIS_IUSRS group; must have Enroll permission on the SCEP certificate template; must have “Log on as a service” right	Confirm account is NOT a member of Domain Admins; confirm Enroll ACE on the template Security tab	HTTP 500 on NDES URL or challenge password retrieval failure if account lacks CA enrollment rights	PKI Admin / Security Architect
Certificate template	Template configured for SCEP: Key Usage = Digital Signature; EKU = Client Authentication (and others as needed); private key not exportable; Supply in the request for Subject name	Open template in certtmpl.msc; confirm Key Usage, EKU, and private key settings; confirm template is published on the issuing CA	Certificate request rejected by CA if template EKU does not match intended use; NDES returns HTTP 400 to requesting device	PKI Admin
SSL certificate for NDES HTTPS endpoint	Valid SSL/TLS certificate bound to the NDES IIS site; issuing CA must be trusted by all devices that will use NDES; TLS 1.2 or higher enforced	Browse to the NDES HTTPS URL from a test device and confirm no certificate warning; check IIS bindings in inetmgr	Devices reject the NDES connection if the SSL certificate is self-signed or issued by an untrusted CA; Intune reports enrollment failure	PKI Admin / Platform Team
Network access	Devices must reach NDES HTTPS endpoint on TCP 443; NDES server must reach the CA on TCP 135 and dynamic RPC ports; reverse proxy or application gateway recommended for internet-facing deployments	Run Test-NetConnection -ComputerName ndes.contoso.com -Port 443 from a test device; confirm firewall rules allow CA RPC from NDES server	Enrollment timeouts or TCP reset errors on devices if firewall blocks NDES HTTPS; silent CA submission failures if NDES cannot reach CA on RPC	Security Architect / Network Team

Why NDES Still Matters in Modern PKI

Some administrators assume SCEP is outdated because it was created decades ago. SCEP usage has in fact grown dramatically due to modern device management trends. The following three use cases illustrate where NDES remains essential today.

1. Microsoft Intune Device Certificate Enrollment

Organizations deploying Intune often rely on NDES to issue device authentication certificates, Wi-Fi certificates, VPN certificates, and email authentication certificates. Without NDES, Intune cannot issue certificates from on-premises ADCS. This makes NDES a dependency for any hybrid Intune deployment that relies on an internal CA rather than a cloud-based CA.

2. Client Authentication Certificates

NDES is commonly used to issue client authentication certificates for Windows Always-On VPN, third-party VPN clients, and hybrid remote access architectures. This enables passwordless VPN authentication tied to device identity, which is a foundational control in Zero Trust network access models.

3. IoT and Network Device Enrollment

NDES allows certificates to be issued to printers, cameras, manufacturing systems, and network devices. These devices often cannot join AD, making SCEP the only scalable option. In OT and industrial environments where device counts run into the thousands, PKIaaS-backed NDES or PKI-as-a-Service provides the scalable issuance infrastructure these environments require.

How NDES Works: Architecture Overview

A typical NDES deployment involves four components: the requesting device (MDM-managed or network device), the NDES server, the Microsoft Certification Authority (CA), and the certificate template configured for SCEP.

Step 1: Device Requests Enrollment

The device contacts the NDES HTTPS endpoint using SCEP. For Intune-managed devices, this is triggered automatically by an Intune SCEP profile. The device generates a key pair and constructs a PKCS#10 Certificate Signing Request (CSR).

Step 2: NDES Issues a Challenge Password

NDES generates a one-time challenge password (OTP) used to validate the request. In Intune-integrated deployments, Intune pre-authorizes the request and provides the challenge via the NDES Connector, so no manual OTP retrieval is required.

Step 3: Device Submits Certificate Request

The device submits its certificate signing request along with the challenge password to NDES using an HTTP POST to the SCEP endpoint. NDES validates the challenge before forwarding the request to the CA.

Step 4: NDES Submits to the CA

NDES forwards the request to the Microsoft CA using the NDES service account credentials and the designated certificate template. The CA evaluates the request against the template’s policy, key usage, EKU, and subject name settings before issuing or rejecting the certificate.

Step 5: Certificate Is Issued

The CA signs the certificate and returns it to NDES. The CA issuance event is logged in the CA database and event log. This is the point where SIEM integration should capture the issuance event for audit trail purposes.

Step 6: Device Retrieves Certificate

The device polls the NDES endpoint and retrieves the signed certificate. The device installs it into the appropriate certificate store (machine store for device authentication, user store for user certificates). The CLM platform should register this certificate in the inventory at this point for tracking and renewal management.

Common NDES Misconfigurations Found in Security Assessments

In PKI security assessments, several recurring NDES misconfigurations appear consistently. Each represents a real attack vector.

1. NDES Exposed Directly to the Internet

NDES endpoints often run on IIS and may be published externally without protection. This allows attackers to attempt certificate enrollment, enumerate templates, and exploit IIS vulnerabilities. NDES should always be protected by application gateways and role-based access rules. Never publish the raw NDES URL directly to the internet; always route through a reverse proxy or Azure Application Proxy that can enforce authentication before requests reach NDES.

2. Over-Privileged Service Accounts

NDES uses a service account to request certificates from the CA. If this account has excessive permissions, attackers who compromise it can issue certificates independently. This risk is particularly severe because certificates can be used for authentication and lateral movement. The NDES service account should have only the Enroll permission on the designated SCEP template, local IIS_IUSRS membership, and Log on as a service rights. It should never be a member of Domain Admins or CA Admins.

3. Weak Template Configuration

Templates used for SCEP are sometimes configured to allow exportable private keys, allow overly broad usage rights (e.g., both client and server authentication in the same template), and issue certificates without manager approval controls. These misconfigurations can lead to identity compromise and certificate misuse. Always disable private key export on SCEP templates. Set the minimum EKU required for the use case. Consider enabling CA Manager Approval for high-privilege templates even when SCEP is used.

4. Lack of Monitoring and Logging

Many organizations deploy NDES but never monitor it. Without proper monitoring and logging, rogue certificate issuance goes unnoticed, enrollment abuse cannot be detected, and incident response becomes difficult. Integrate CA event logs (Event ID 4886 for certificate requests, Event ID 4887 for certificate issuance) with your SIEM. Set alerts for abnormal enrollment volume spikes from a single source IP or device. Use CBOM Secure to maintain continuous cryptographic inventory of all NDES-issued certificates.

Security Best Practices for NDES Deployments

To secure NDES in modern environments, organizations should follow these best practices. For more detail, see the companion guide: NDES Security Best Practices.

1. Isolate NDES Servers

NDES should never be installed directly on the CA. Deploy it in a dedicated DMZ segment, behind a reverse proxy or application gateway, with limited network access to the CA (CA RPC ports only, blocked from all other internal segments). This limits blast radius if the NDES server is compromised.

2. Restrict Template Permissions

SCEP templates should allow only required EKUs, restrict subject name formats to Supply in the request (validated via NDES challenge), disable private key export, and set enrollment permissions to only the NDES service account rather than Domain Computers broadly.

3. Monitor Certificate Issuance

Log all SCEP requests via IIS logs and CA event logs. Monitor template usage by template name and requesting account. Alert on abnormal enrollment volumes (e.g., more than 50 certificate requests per hour from a single source). This is especially important for templates that grant client authentication certificates, as these can be used for lateral movement if obtained by an attacker.

4. Harden IIS Configuration

Since NDES runs on IIS, disable unused IIS modules, enforce TLS 1.2 or higher on the NDES HTTPS binding, apply HTTPS security headers (HSTS, X-Content-Type-Options, X-Frame-Options), and regularly patch the server. The NDES IIS site should be the only site on the server; do not co-locate other applications.

Where SCEP and NDES Start to Show Limitations

Despite their widespread adoption, SCEP and NDES were not originally designed for today’s cloud-native environments. Several challenges commonly arise in modern deployments.

Limited Security Context

SCEP was designed for simplicity, which means it provides limited identity validation capabilities. The challenge password mechanism is a shared secret, not a cryptographically bound identity proof. Additional controls must often be layered on top (such as Intune’s pre-authorization via the NDES Connector) to ensure strong device authentication before certificate issuance.

Operational Complexity

NDES deployments require dedicated servers, IIS hardening, network exposure planning, template configuration management, and service account lifecycle management. In hybrid or multi-cloud environments with multiple NDES instances, this introduces significant operational overhead without unified CLM tooling providing visibility across all instances.

Scaling Challenges

While SCEP works well for endpoint devices, it is less suited for dynamic workloads such as containers, microservices, or ephemeral cloud instances. These modern workloads require faster certificate issuance cycles, stronger identity verification mechanisms, and short-lived certificates. ACME handles these scenarios more effectively.

The Modern Certificate Automation Framework: ACME

ACME (Automated Certificate Management Environment) was developed to enable fully automated certificate lifecycle management with minimal human involvement. Unlike SCEP, ACME was built for modern environments and supports automated certificate issuance and renewal, API-driven workflows, identity verification mechanisms, and short-lived certificates aligned with Zero Trust principles.

ACME is particularly valuable for DevOps pipelines, Kubernetes clusters, cloud-native services, and service-to-service authentication. Enterprises are increasingly adopting it internally for workload identities alongside SCEP/NDES for device certificates.

Comparing SCEP, NDES, and ACME in Enterprise PKI

Each technology serves a different purpose. Organizations often use them together rather than choosing only one.

Dimension	SCEP / NDES	ACME	AD Auto-Enrollment
Primary use case	Device certificates for Intune-managed endpoints, VPN clients, IoT, network appliances	Server and workload certificates for DevOps pipelines, Kubernetes, cloud-native services	User and computer certificates for domain-joined Windows systems
Device requirement	Does not require Active Directory membership; uses challenge password for authentication	Does not require AD; uses domain validation or API token authentication	Requires Active Directory membership and Group Policy
Certificate lifetime	Supports longer-lived device certificates (typical: 1 year); renewal via new SCEP request	Designed for short-lived certificates (days to 90 days); automated renewal built into protocol	Supports any validity period configured in the template; renewal via auto-enrollment GPO
Infrastructure required	NDES server (dedicated Windows Server + IIS), NDES service account, CA RPC access	ACME-compatible CA endpoint; no dedicated server required beyond the CA itself	Domain controller, Group Policy, domain-joined CA
Cloud/hybrid support	Works with Intune via NDES Connector; requires on-premises NDES server for on-premises ADCS	Native to cloud CAs; works without on-premises infrastructure	Requires on-premises AD; not suitable for cloud-only or BYOD devices
PQC readiness	Limited; depends on CA and template algorithm configuration; no built-in algorithm negotiation	Strong; algorithm negotiation built into protocol; ready for NIST FIPS 203/204/205 migration	Depends on CA template configuration; requires template update for PQC algorithms
Best for	Intune device certs, VPN certs, Wi-Fi certs, IoT device identity	Web server TLS, container identity, CI/CD pipeline certs, short-lived service certs	Domain-joined Windows user and computer certificates

Real-World Example: Hybrid Enterprise Deployment

Consider an enterprise adopting Zero Trust and migrating to the cloud simultaneously. They might deploy NDES integrated with Intune to manage device certificates, ACME-based issuance for container workloads, and ADCS auto-enrollment for internal servers. This hybrid model enables them to maintain compatibility with legacy systems while modernizing certificate lifecycle management. It also reduces reliance on passwords and strengthens identity-based access controls across the environment.

How to Choose the Right Enrollment Method

If your focus is on end-user devices or network appliances that cannot join Active Directory, SCEP with NDES remains practical and widely supported. If your focus is on modern workloads or automation-heavy environments, ACME offers stronger integration and scalability. If you are managing domain-joined Windows systems with Group Policy, AD auto-enrollment is the most efficient path.

Most enterprises will need all three during their transition toward cloud-native security models. A unified CLM platform like CertSecure Manager provides the single pane of glass across all three issuance paths, ensuring no certificate escapes inventory regardless of how it was issued.

The Future of Enterprise Certificate Enrollment

Certificate-based authentication is rapidly becoming the default mechanism for securing enterprise environments. As organizations move toward passwordless authentication, device identity enforcement, Zero Trust access models, and cloud-native architecture, certificate automation becomes a core security capability rather than a niche PKI function.

SCEP and NDES will likely remain in use for device enrollment, while ACME adoption continues to grow for workload identities and infrastructure automation. NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. Organizations that have not begun PQC readiness planning will need to update CA algorithm profiles and certificate templates to support post-quantum algorithms. Start with the PQC Readiness assessment and the PQC Center of Excellence for NIST-aligned migration planning.

How Encryption Consulting Can Help

Encryption Consulting has extensive experience delivering end-to-end PKI solutions for enterprise and government clients. We provide both professional services and our automation platform (CertSecure Manager) to ensure your PKI is secure, resilient, and future-ready.

PKI Services

End-to-end advisory, design, and implementation services to help organizations build, modernize, and govern secure Public Key Infrastructure environments.

Project Planning

We assess your cryptographic environment, review PKI configurations, dependencies, and requirements, and consolidate findings into a structured, customer-approved project plan.

CP/CPS Development

We develop Certificate Policy (CP) and Certification Practice Statement (CPS) aligned with RFC 3647. These documents are customized to your organization’s regulatory, security, and operational requirements.

PKI Design and Implementation

We design and deploy resilient PKI infrastructures, including offline Root CAs, issuing CAs, NDES servers, and HSM integration, depending on the customer’s needs. Deliverables include PKI design document, build guides, ceremony scripts, and system configurations. Once deployed, we conduct thorough testing, validation, fine-tuning, and knowledge transfer sessions to empower your team.

Business Continuity and Disaster Recovery

Following the deployment, we develop and implement business continuity and disaster recovery strategies, conduct failover testing, and document operational workflows for the entire PKI and HSM infrastructure, supported by a comprehensive PKI operations guide.

Ongoing Support and Maintenance (Optional)

After implementation, we offer a subscription-based yearly support package providing comprehensive coverage for PKI, CLM, and HSM components. This includes incident response, troubleshooting, system optimization, certificate lifecycle management, CP/CPS updates, key archival, HSM firmware upgrades, audit logging, and patch management.

This approach ensures your PKI infrastructure is not only secure and compliant but also scalable, resilient, and fully aligned with your long-term operational and regulatory goals.

CertSecure Manager

CertSecure Manager by Encryption Consulting is a certificate lifecycle management solution that simplifies and automates the entire lifecycle, allowing you to focus on security rather than renewals.

• Automation for Short-Lived Certificates: With ACME and 90-day/47-day TLS certificates becoming the standard, manual renewal is no longer a practical option. CertSecure Manager automates enrollment, renewal, and deployment to ensure certificates never expire unnoticed.
• Seamless DevOps and Cloud Integration: Certificates can be provisioned directly into web servers and cloud instances, and they integrate with modern logging tools like Datadog, Splunk, ITSM tools like ServiceNow, and DevOps tools such as Terraform and Ansible.
• Multi-CA Support: Many organizations utilize multiple CAs (internal Microsoft CA, public CAs such as DigiCert and GlobalSign, etc.). CertSecure Manager integrates across these sources, providing a single pane of glass for issuance and lifecycle management across SCEP/NDES and ACME enrollment paths.
• Unified Issuance and Renewal Policies: CertSecure Manager enforces your organization’s key sizes, algorithms, and renewal rules consistently across all certificates, ensuring every certificate meets your security standards every time.
• Proactive Monitoring and Renewal Testing: Continuous monitoring, combined with simulated renewal and expiry testing, ensures you identify risks before certificates impact production systems.
• Centralized Visibility and Compliance: One consolidated dashboard displays all certificates, key lengths, strong and weak algorithms, and their expiry dates. Audit trails and policy enforcement simplify compliance with PCI DSS, HIPAA, and other frameworks.

If you are wondering where to get started with securing your PKI, Encryption Consulting is here to support you with its PKI Support Services. You can count on us as your trusted partner, and we will guide you through every step with clarity, confidence, and real-world expertise.

Conclusion

Enterprise PKI is evolving from a backend security tool into a central identity infrastructure. Understanding how SCEP, NDES, and ACME interact allows organizations to build scalable certificate management pipelines that support both legacy environments and modern cloud workloads. By combining traditional PKI foundations with modern automation frameworks, enterprises can move toward stronger identity-driven security without sacrificing operational efficiency.

NDES remains essential for hybrid Intune deployments and non-domain device certificate enrollment, but it must be deployed and secured with the same rigor applied to the CA itself. Treat every misconfigured NDES server as a potential certificate issuance backdoor. Invest in CLM tooling to maintain full visibility over NDES-issued certificates, and begin PQC readiness planning now so algorithm transitions do not require emergency CA rebuilds when regulatory deadlines arrive.

Frequently Asked Questions

What is the main takeaway from NDES and SCEP Explained: The Backbone of Automated Certificate Enrollment?

SCEP remains the de facto protocol for automated device certificate enrollment in Microsoft PKI environments, and NDES is the required bridge between SCEP-speaking devices and ADCS. Without NDES, Intune, MDM platforms, and non-domain devices cannot obtain certificates from an on-premises CA. Misconfigured NDES servers are one of the most commonly exploited PKI weaknesses and should be treated with the same security rigor as the CA itself.

Why does NDES and SCEP matter for enterprise PKI teams?

Enterprise PKI teams are responsible for the certificate infrastructure that Intune, MDM, VPN, Wi-Fi, and Zero Trust access systems depend on. NDES is how those systems obtain certificates from ADCS for non-domain devices. According to DigiCert’s Trust Pulse Survey (July 2, 2025), nearly half of enterprises experienced certificate-related downtime in the past year. A misconfigured or unavailable NDES server can break device authentication across an entire organization simultaneously.

What risks increase if NDES and SCEP are not properly secured?

Risks include: an internet-exposed NDES endpoint allows attackers to enumerate certificate templates and attempt unauthorized enrollment; an over-privileged service account allows attackers to impersonate it and issue certificates independently; weak template configuration with exportable private keys creates identity compromise vectors; and no monitoring means rogue certificate issuance goes undetected until an incident occurs.

Which teams should own NDES and SCEP deployment and security?

PKI admins own NDES server deployment, certificate template configuration, and CA policy. Security architects own the network isolation design and IIS hardening standards. Platform and endpoint teams own the MDM/Intune integration and device enrollment profiles. Compliance teams own audit log requirements and monitoring evidence. CISOs own the risk register entry for NDES as a high-value attack surface given its role in certificate issuance for authentication.

How does NDES and SCEP connect to certificate lifecycle management?

NDES and SCEP handle the initial certificate enrollment and renewal requests from devices. Certificate lifecycle management (CLM) provides the broader operational layer that tracks, monitors, and manages all certificates across the environment. CertSecure Manager integrates with SCEP/NDES enrollment flows and provides unified visibility across ADCS-issued certificates, public CA certificates, and cloud-issued certificates in a single dashboard with automated expiry alerting and renewal workflows.

How should organizations measure success after deploying NDES?

Key metrics include: percentage of target devices successfully enrolled via SCEP/NDES (target: 100% of MDM-managed devices); number of failed SCEP enrollment attempts per week (target: trending toward zero after initial stabilization); certificate expiry-related authentication failures caused by NDES-issued certificates per quarter (target: zero); time to detect a rogue or unauthorized certificate issued via NDES (target: same-day via SIEM alerting); and NDES server availability (target: 99.9% minimum).

What should be audited or monitored regularly in an NDES deployment?

Monitor continuously: SCEP enrollment request volumes and failure rates; certificates issued via NDES in the CA database; NDES IIS application pool health; and network access to the NDES endpoint from unexpected source IPs. Audit quarterly: NDES service account permissions against least-privilege requirements; certificate template configuration for SCEP; IIS configuration for TLS version enforcement; and NDES server OS patch level.

How does NDES affect cloud, hybrid, or multi-CA environments?

In hybrid environments where Intune manages both cloud-native and on-premises devices, NDES is the required bridge for issuing certificates from on-premises ADCS to cloud-managed devices. In multi-CA environments, organizations may run multiple NDES instances. Without CLM tooling providing unified visibility, certificates issued by different NDES instances across different CAs create inventory blind spots. CBOM Secure automates cryptographic discovery across these hybrid environments to maintain a complete and auditable certificate inventory.

What prerequisites are required before deploying NDES?

Prerequisites include: a running ADCS environment with at least one issuing CA; Windows Server 2016 or later for the NDES role; a dedicated service account with CA enrollment rights and IIS access (not a domain admin); a certificate template configured for SCEP enrollment with correct Key Usage (digitalSignature), EKU, and no exportable private keys; IIS installed on the NDES server; and a valid SSL certificate for the NDES HTTPS endpoint. NDES must not be installed on the CA server itself.

What common errors should administrators watch for when deploying NDES?

Common errors include: HTTP 403 on the NDES URL caused by IIS permissions or application pool identity issues; challenge password retrieval failures caused by the NDES service account lacking CA enrollment permissions; certificate request rejections caused by template misconfiguration or missing EKU; NDES application pool crashing caused by memory or IIS module issues; and devices unable to trust the NDES SSL certificate because the issuing CA is not in the device trust store.