What are NDES security best practices?

NDES security best practices are the configuration and operational controls that protect the Network Device Enrollment Service (NDES) role in Active Directory Certificate Services, covering encrypted communication, service account hardening, private key protection, and certificate template lifecycle, so a compromised NDES server cannot be used to request arbitrary certificates.

The Network Device Enrollment Service (NDES) allows software on network devices, such as routers, firewalls, and switches, to obtain digital certificates without running any domain credentials. NDES is one of the role services on Active Directory Certificate Services (AD CS), and it implements the Simple Certificate Enrollment Protocol (SCEP), which defines the communication between the Registration Authority (RA) and network devices during enrollment. Because NDES sits at the boundary between untrusted devices and a trusted CA, every control on this page exists to keep that boundary from becoming the weak point in the PKI.

This guide covers what NDES actually does, the specific hardening steps Microsoft and EC recommend, how to decide which controls to prioritize first, a pros-and-cons view of the highest-impact decisions, a decision tree and decision matrix for your environment, and how NDES hardening fits into a broader certificate lifecycle management program.

Key Takeaways

• NDES bridges untrusted network devices and a trusted CA, so every hardening control exists to stop a compromised NDES server from becoming a path to arbitrary certificate issuance.
• Private key protection is the highest-priority control: an HSM keeps NDES keys out of the operating system’s memory and out of unencrypted VM snapshots or backups.
• Role separation and service account choice (Network Service, gMSA, or a hardened domain account) determine how much manual password and permission management the NDES deployment requires long term.
• NDES should run on its own server, never colocated with the CA except behind a scoped firewall rule, and should sit behind a reverse proxy whenever it is reachable from the internet.
• Enterprises relying on manual, undocumented PKI service hardening reported certificate-related downtime in 45% of cases over the past year, with 37.5% of those outages caused specifically by an expired certificate, according to DigiCert’s Trust Pulse Survey, published July 2, 2025, an unhardened or unmonitored NDES server sits squarely in that risk category.

Who Should Care About NDES Security Best Practices

NDES hardening touches more than whoever installed the role. Here is what each team should actually do about it.

• PKI Administrators own the NDES build, service account configuration, and certificate template lifecycle. Action: confirm the CEP Encryption and Exchange Enrollment Agent templates are unassigned from the CA outside of initial setup and renewal windows.
• Security Architects decide how NDES private keys are stored and how the server is isolated. Action: mandate HSM-backed key storage for any NDES deployment issuing certificates at scale, not just for the CA itself.
• Platform and Identity Teams manage the reverse proxy, firewall rules, and TLS configuration in front of NDES. Action: verify the reverse proxy and TLS 1.2+ enforcement are in place before any internet-facing SCEP enrollment (such as Intune) goes live.
• Compliance and GRC track whether NDES hardening evidence exists for audits. Action: add NDES service account, template assignment, and key storage checks to the recurring PKI control review, not just the CA’s own controls.
• CISOs own the risk that a compromised NDES server becomes a certificate-issuance path for an attacker. Action: treat NDES as a Tier 0-adjacent asset given its trust relationship with the CA, not as a low-priority network appliance.

What Are NDES Security Best Practices?

NDES security best practices are the set of Microsoft- and industry-recommended controls that reduce the attack surface of the Network Device Enrollment Service: encrypting administrative traffic, limiting how long the service runs, separating operational roles, protecting the private keys used to sign and encrypt enrollment requests, and correctly scoping the certificate templates NDES is allowed to use. None of these controls work in isolation; a hardened service account with an unprotected private key is still a critical exposure, and an HSM-backed key with no role separation still leaves the server open to misuse by anyone with access.

Functions of NDES

NDES performs three functions in the certificate enrollment flow, and each one is a point where a hardening control below applies:

1. Generates and provides one-time enrollment passwords to administrators.
2. Submits enrollment requests to the Certificate Authority (CA).
3. Retrieves enrolled certificates from the CA and forwards them to the requesting network device.

Microsoft’s own guidance on these controls is a useful secondary reference: see the NDES Security Best Practices post on the Microsoft Community Hub.

Security Best Practices for NDES

Work through these controls together rather than in isolation. Each one closes a different exposure, and most real-world NDES compromises trace back to two or three of these being skipped at once, not just one.

Enable SSL/TLS for the NDES Administrator Site

SSL/TLS protection on the MSCEP_Admin site ensures the enrollment challenge password is protected against inspection attacks when an administrator or a network device connects to it. Without it, the one-time password NDES generates is exposed in plaintext to anyone positioned to intercept the connection.

Use Extended-Validity Device Certificates Where Appropriate

The default IPsec (Offline Request) certificate template has only a one-year validity period. If you define custom signing, encryption, or general-purpose certificate templates for devices, consider a version 2 template with a two-year validity period to reduce the management overhead of requesting device certificates. Weigh this against the industry-wide move toward shorter certificate lifetimes for anything internet-facing; a longer validity period is appropriate for internal device certificates, not for anything touching the public TLS ecosystem.

Disable the NDES Service When Not in Use

Stopping the NDES service when it is not actively needed ensures unauthorized certificates cannot be issued during that window, and it clears any unused enrollment passwords from the service cache. This control trades convenience for reduced exposure, and it works best for environments with scheduled, batch-style device enrollment rather than continuous, on-demand enrollment.

Lock Down the Server with the Security Configuration Wizard

The Windows Security Configuration Wizard analyzes the roles and services actually running on the NDES server and recommends locking down IIS and everything else installed alongside it. Run it after NDES configuration is finalized, and re-run it after any change to the roles installed on that server.

Implement Role Separation

Several distinct accounts are involved in installing, configuring, and operating NDES, and none of them should overlap in scope:

• Setup account, used only during initial installation and template renewal.
• Device administrators, who manage device enrollment day to day.
• The NDES service account itself, which is Network Service, a Group Managed Service Account (gMSA), or a hardened domain user account, depending on the environment.

Choose and Harden the NDES Service Account

Whichever account type you choose, apply these controls consistently:

• AES encryption is required for gMSA or domain user accounts.
• Configure login restrictions and a long, non-reused password for domain user accounts.
• Do not reuse a gMSA or domain user account on any other computer or for any other purpose.
• Enable the “Account is sensitive and cannot be delegated” checkbox for domain user accounts.
• Manually configure permissions on the NDES certificates’ private keys when using a gMSA or a custom certificate template, since these permissions are not always set automatically.

Harden the Underlying System

Reduce the local Administrators group on the NDES server to include only PKI Admins. Only members of that group should hold any logon rights on the box, interactive, remote interactive, log on as a batch job, or log on as a service. Every other account should have zero logon rights to the NDES server.

Secure the Private Keys with an HSM

Key protection is the single highest-impact control on this list, because a compromised NDES private key lets an attacker request a valid certificate for logging into Active Directory as any subject.

• Use a Hardware Security Module (HSM) to generate, store, and manage access to NDES keys. An HSM ensures NDES keys never reside in the operating system’s memory, adds operational controls, and limits exposure to the key material itself.
• If NDES is virtualized, use an HSM to store its private keys regardless, since virtualization host admins with access to the VM, disk, or memory can otherwise recover the keys in an unencrypted form.
• If an HSM is not in use, encrypt backups and tightly restrict access to them, since snapshots, checkpoints, and other backup types typically contain the NDES private keys in the clear.

Isolate NDES Within Your Infrastructure

• When allowing internet access to NDES, for example to enroll certificates on Intune-managed mobile devices, protect it with a reverse proxy such as Azure AD Application Proxy or Web Application Proxy (WAP). Never expose NDES to the internet directly.
• Install NDES on a different computer than the one hosting the CA, and run no other services on the NDES server itself.
• If NDES must be colocated on a CA computer, configure the Certification Authority Enrollment and Management Protocol (CERTSVC-RPC-TCP-IN) firewall rule so only the NDES (and OCSP) IP address can reach the CA for enrollment.

Manage CA and Certificate Templates Correctly

NDES relies on a small set of certificate templates, each with a narrow, specific purpose, and each one needs its own permission and lifecycle discipline.

CEP Encryption and Exchange Enrollment Agent Templates

CEP Encryption: a certificate based on this template is issued to the NDES computer during service configuration and applies SCEP-specific encryption to communication with the requesting client. Exchange Enrollment Agent (Offline Request): a certificate based on this template is also issued during configuration, and NDES uses it to digitally re-sign the enrollment request received from the device or MDM before forwarding it to the issuing CA. Both templates are needed only during initial NDES installation and when renewing the certificate before it expires; unassign them from the CA during normal operating time, and grant the Setup Account Enroll permissions on these templates only for the duration of configuration.

IPSec (Offline Request) / SCEP Certificate Template

This template, also known as the “Device Template” or “SCEP Certificate Template,” is used for enrolling device or user certificates and is automatically assigned to the CA during NDES configuration. Most deployments replace it with a custom template that better fits their needs. Grant Enroll permissions on this template to the Device Administrator role and the NDES service account, and no one else.

Enforce Data-in-Transit Encryption (TLS 1.2+)

TLS must encrypt every communication between NDES and the MDM or device requesting the certificate. This includes enforcing TLS by disabling IIS’s HTTP listener entirely and confirming TLS 1.2 compliance across the stack, not just on the NDES site itself.

Selection Criteria: Which Practices to Prioritize First

Not every environment can implement all eleven controls on day one. Prioritize in this order when time or resources are limited:

1. Private key protection (HSM-backed storage) first, since this is the control with the highest blast radius if skipped.
2. Data-in-transit encryption (TLS 1.2+) second, since it is low-effort and closes a passive interception risk immediately.
3. Infrastructure isolation (separate server, reverse proxy if internet-facing) third, since it limits what an attacker can reach even if another control fails.
4. Role separation and service account hardening fourth, since misconfigured accounts are the most common way the other controls get bypassed.
5. Certificate template lifecycle and system hardening last, since they reduce residual risk once the higher-impact controls are already in place.

Pros and Cons of Key NDES Security Controls

Control	Pros	Cons
HSM-backed private key storage	Keys never leave a hardware trust boundary; meets most compliance mandates for key protection	Added cost and operational complexity; requires HSM integration expertise
gMSA service account	No manual password rotation; supports AES; reduces credential-theft surface versus a domain user account	Requires AD schema and version support; still needs one gMSA scoped per NDES server
Reverse proxy for internet-facing NDES	Keeps NDES itself off the public internet; centralizes authentication and TLS termination	Adds infrastructure that itself needs patching, monitoring, and its own hardening
Colocating NDES with the CA	Fewer servers to build, patch, and monitor	Expands the CA’s attack surface; discouraged by Microsoft except behind a scoped firewall rule
Disabling NDES when idle	Shrinks the exposure window; clears unused cached passwords	Breaks always-on enrollment scenarios such as continuous Intune SCEP issuance

Decision Tree: Which NDES Security Controls Apply to Your Environment

Use this tree to work out which controls are non-negotiable for your specific deployment:

• Is NDES reachable from the internet (for example, for Intune SCEP enrollment)?
  • Yes: deploy a reverse proxy (Azure AD Application Proxy or WAP) in front of NDES and confirm TLS 1.2+ is enforced end to end before enabling access.
  • No: confirm NDES is still isolated on its own internal segment; internal-only does not mean unrestricted.
• Does your organization already use an HSM for the issuing CA?
  • Yes: extend the same HSM to protect NDES private keys rather than leaving NDES keys in software.
  • No: prioritize HSM adoption for NDES before expanding SCEP enrollment volume, since volume increases the value of the keys as a target.
• Is NDES currently installed on the same server as the CA?
  • Yes: migrate NDES to its own server if possible; if not possible in the short term, configure the CERTSVC-RPC-TCP-IN firewall rule immediately.
  • No: confirm no other unrelated services are running on the NDES server itself.
• Does enrollment happen continuously (such as automated MDM-driven SCEP requests) or in scheduled batches?
  • Continuous: skip the “disable when not in use” control and instead rely on the other controls plus active monitoring.
  • Batch: disable the NDES service between enrollment windows to shrink the exposure surface.

Decision Matrix: Use Case, Security Impact, Operational Effort, Automation Fit, and Owner

Use this matrix to route each NDES hardening decision to the right owner with a realistic sense of the effort involved.

Use Case	Security Impact	Operational Effort	Automation Fit	Recommended Owner
Public/internet-facing NDES for MDM enrollment	High	Medium	High, reverse proxy and TLS policy can be automated	Platform / Identity Team
NDES colocated with the CA	High	Low	Low, mostly a one-time firewall rule and migration decision	PKI Administrator
Private key storage (HSM vs. software)	Critical	Medium	High, HSM APIs support scripted key operations	Security Architect
Service account selection (gMSA vs. domain user)	Medium	Low	High, gMSA removes manual password rotation entirely	PKI Administrator
Certificate template lifecycle (CEP/EEA unassignment)	Medium	Low	Medium, can be scripted but needs a change window	PKI Administrator
Data-in-transit enforcement (TLS 1.2+)	High	Low	High, enforceable via IIS and group policy baseline	Security Architect

How NDES Security Connects to Certificate Lifecycle Management

Every certificate NDES issues to a network device still needs to be discovered, tracked, and renewed for the rest of its life, and a hardened NDES server that issues into an untracked certificate population still produces the same outage risk. DigiCert’s Trust Pulse Survey, published July 2, 2025, found that 45% of enterprises experienced certificate-related downtime in the past year, with 37.5% of those incidents caused specifically by an expired certificate, device certificates issued through NDES are exactly the kind of high-volume, easy-to-lose-track-of population that drives that number.

Certificate lifecycle management platforms such as CertSecure Manager extend visibility to every certificate NDES issues, not just the ones an administrator remembers to track, closing the gap between “NDES is hardened” and “every certificate it issued is accounted for.” If you are modernizing PKI operations more broadly, see how PKI modernization and CLM work together and how a combined PKI and CLM roadmap accounts for device-certificate automation, not just server or user certificates.

NDES Security in Cloud, Hybrid, and Multi-CA PKI Environments

Hybrid environments that route mobile device enrollment through Intune or another cloud MDM add a cloud-facing edge to what was historically an entirely on-premises service, which is exactly why the reverse proxy and TLS controls above matter more, not less, in a hybrid deployment. Multi-CA environments compound the certificate template question: every CA that NDES can reach needs the same template scoping and permission discipline, not just the primary issuing CA.

For organizations managing NDES and certificate issuance across multiple environments, a PKI-as-a-Service model centralizes the hardening baseline, key protection, and monitoring that would otherwise need to be replicated and audited separately on every NDES instance.

Measuring Success and What to Audit Regularly

A hardened NDES deployment is not a one-time project. Audit these on a recurring schedule, not only at initial configuration:

• Whether the CEP Encryption and Exchange Enrollment Agent templates are still unassigned from the CA outside of configuration or renewal windows
• Whether the NDES service account’s permissions and password policy still match the intended hardening baseline
• Whether TLS 1.2+ enforcement and the HTTP listener disablement are still in effect after any IIS or Windows update
• Whether private keys are still confirmed to be HSM-backed, especially after any server migration or virtualization change
• Whether the reverse proxy in front of any internet-facing NDES instance is current, patched, and still correctly scoped

A cryptographic asset inventory such as CBOM Secure extends machine identity inventory and certificate discovery across every certificate NDES issues, providing the audit trail these recurring checks depend on, rather than relying on institutional memory of what NDES was configured to do at rollout.

Longer term, the CA/Browser Forum’s April 11, 2025 ballot to shorten maximum TLS certificate validity to 200 days, then 100 days, then 47 days by 2029 does not directly govern internal device certificates the way it governs public TLS, but it signals where certificate lifecycle expectations are heading industry-wide, including for device populations like those NDES issues into. NIST finalized its first three post-quantum cryptography standards, FIPS 203, FIPS 204, and FIPS 205, on August 13, 2024, and any organization planning crypto agility across its PKI should include NDES-issued device certificates in that planning, not just server and user certificates. Encryption Consulting’s PQC Center of Excellence and a PQC readiness assessment are the right place to plan that transition.

Encryption Consulting’s Take

NDES hardening tends to get treated as a checklist to run once during initial setup, but the controls that matter most, private key protection, service account hygiene, and template lifecycle, all drift over time as staff change, servers get migrated, and new enrollment use cases get added without anyone revisiting the original hardening baseline. Treat the decision matrix and selection criteria above as a recurring review, not a one-time deployment gate.

Conclusion

Securing NDES means implementing every control above together, TLS enforcement, service account hardening, role separation, template lifecycle discipline, and, above all, HSM-backed private key protection, since a malicious actor with access to an NDES private key can request a valid certificate for logging into Active Directory as any subject. Use the selection criteria, pros and cons, decision tree, and decision matrix in this guide to prioritize and assign ownership for a specific environment.

If you need help hardening your NDES deployment or your broader PKI environment, feel free to email us at [email protected].

Frequently Asked Questions

What is the main takeaway from What are NDES security best practices?

NDES sits at the boundary between untrusted network devices and a trusted CA, so hardening it means protecting the private keys, encrypting all communication, separating operational roles, and scoping certificate templates tightly. No single control is sufficient on its own; the highest-priority control is HSM-backed private key protection.

Why does this matter for enterprise PKI teams?

A compromised NDES server can be used to request a valid certificate for logging into Active Directory as any subject, which makes NDES a high-value target even though it is often treated as a low-priority network appliance rather than a Tier 0-adjacent asset.

What risks increase if this topic is handled manually?

Manual, undocumented NDES hardening means service account permissions and TLS settings drift after updates, unassigned certificate templates get re-enabled and forgotten, and private key protection is never verified after a server migration until an incident forces a review.

Which teams should own this change?

PKI administrators own the NDES build, service account, and template lifecycle. Security architects decide on private key storage and server isolation. Platform and identity teams manage the reverse proxy and TLS configuration. Compliance and CISOs track NDES hardening as part of the broader PKI risk program.

How does this connect to certificate lifecycle management?

Every certificate NDES issues to a network device still needs discovery, renewal, and expiration tracking for its full lifetime. Certificate lifecycle management tools like CertSecure Manager extend that tracking to NDES-issued device certificates instead of stopping at server and user certificates.

How should organizations measure success?

Success looks like verified HSM-backed key storage, a service account that still matches the intended hardening baseline, TLS 1.2+ enforcement confirmed after every update, certificate templates correctly unassigned outside of configuration windows, and a current reverse proxy for any internet-facing instance.

What should be audited or monitored regularly?

Audit certificate template assignment, service account permissions and password policy, TLS and HTTP listener configuration, private key storage location, and the patch and configuration state of any reverse proxy sitting in front of NDES.

How does this topic affect cloud, hybrid, or multi-CA PKI?

Hybrid deployments that route enrollment through a cloud MDM add a cloud-facing edge that makes reverse proxy and TLS controls more important, not less. Multi-CA environments need the same certificate template scoping and permission discipline applied to every CA NDES can reach, not just the primary issuing CA.

What common mistakes should teams avoid?

Avoid leaving the CEP Encryption and Exchange Enrollment Agent templates assigned to the CA outside of setup, colocating NDES with the CA without a scoped firewall rule, storing private keys in software when an HSM is available, exposing NDES directly to the internet without a reverse proxy, and reusing a service account across other systems.

What should be refreshed quarterly?

This guide is a stable, evergreen explainer, so a full content refresh runs on a 6-month cadence rather than quarterly. Between refreshes, quarterly is still the right cadence for verifying the operational specifics that do change often: service account permissions, certificate template assignment, TLS configuration, and reverse proxy patch status.