RCWRCW IT TrainingFree hands-on labs & simulators← Back to home
Microsoft Intune · Step-by-step guide

Microsoft NDES Implementation Guide: SCEP Certificates with Intune

Give Intune-managed devices certificates from your own private CA — for Wi-Fi, VPN and app authentication — using the Network Device Enrollment Service (NDES) and the SCEP challenge flow.

Published September 10, 2026 · RCW IT Training

What NDES is and when to use it

Network Device Enrollment Service (NDES) is a Windows Server role service that lets devices request certificates over the Simple Certificate Enrollment Protocol (SCEP). With Microsoft Intune, NDES is the bridge between your on-premises Active Directory Certificate Services (AD CS) CA and cloud-managed devices: Intune issues a one-time SCEP challenge, the device presents it to NDES, and the CA signs a certificate.

Choose the right Intune certificate path before you build:

MethodUse it when
SCEP via NDESDevices need certificates from your private CA (802.1X Wi-Fi, per-app VPN, EAP-TLS). Supports automatic renewal on most platforms.
PKCS via connectorYou need full certificate lifecycle from Intune but want the connector to request on the device’s behalf (no SCEP infrastructure).
PKCS imported (PFX)You already have user certificates (for example, S/MIME or smart-card logon certs) to push to devices as-is.

This guide covers the SCEP via NDES path end to end.

Architecture at a glance

  1. The Intune admin creates a trusted root profile and a SCEP profile targeting a device or user group.
  2. Intune generates a unique SCEP challenge password for each certificate request.
  3. The device contacts your NDES server URL (https://ndes.contoso.com/certsrv/mscep/mscep.dll) and submits the challenge plus a certificate signing request.
  4. NDES validates the challenge against Intune through the Intune certificate connector, then forwards the request to the issuing CA.
  5. The CA signs the certificate, NDES returns it, and the device installs it into its certificate store or managed keychain.

Traffic summary: devices need HTTPS (443) to the NDES URL, which is typically published through a reverse proxy or WAF. The NDES server talks to the CA over DCOM/RPC, and the connector talks outbound to Intune over 443 — no inbound firewall holes are needed for the connector itself.

What you’ll need

Prerequisites
  • An Active Directory Certificate Services deployment with an enterprise issuing CA (Windows Server 2016 or later; keep it patched).
  • A domain-joined Windows Server for NDES — Microsoft recommends a dedicated server, not the CA itself.
  • A domain-joined Windows Server for the Intune certificate connector (can share the NDES server in small environments, but separate is cleaner).
  • A service account for NDES with Request Certificates permission on the issuing CA.
  • Intune administrator access (Intune Administrator or equivalent role) and an Entra ID group for pilot devices.
  • A public DNS name and TLS certificate for the NDES URL, plus a reverse proxy or Application Gateway if devices enroll over the internet.

Step 1 — Design the CA hierarchy and NDES placement

  1. Use a two-tier hierarchy: an offline root CA and at least one online enterprise issuing (subordinate) CA. Point NDES at the issuing CA only.
  2. Place the NDES server in a network segment that can reach the issuing CA over DCOM/RPC (TCP 135 plus the dynamic range, or a fixed RPC port) and reach the internet over 443 for connector traffic.
  3. Decide the NDES external URL now (for example, https://ndes.contoso.com/certsrv/mscep/mscep.dll) — the SCEP profile will embed it, and changing it later means reissuing profiles.
  4. Give the NDES service account no more than it needs: domain user, Request Certificates on the CA, and Enroll on the NDES-specific templates from Step 2.

Step 2 — Create the certificate templates

You need three templates on the issuing CA. Duplicate the built-ins — never edit the defaults in place:

  1. CEP Encryption / Enrollment Agent template: duplicate the CEP Encryption template. On the Request Handling tab, allow private key export. Grant the NDES service account Read + Enroll. This lets NDES act as a registration authority.
  2. Exchange Enrollment Agent (Offline request) template: duplicate it and grant the NDES service account Read + Enroll. NDES uses this enrollment-agent certificate to submit requests to the CA on behalf of devices.
  3. SCEP device template: duplicate the User template (or Computer, to match your scenario) and configure it for Intune SCEP:
    • Subject Name: Supply in the request; Intune will pass {{UserPrincipalName}}, {{DeviceId}} or a custom CN.
    • Validity period: 1 year, renewal period 6 weeks is a common starting point; align with your Wi-Fi/VPN session policy.
    • Key Usage: Digital Signature + Key Encipherment; add Client Authentication (1.3.6.1.5.5.7.3.2) under Extended Key Usage.
    • Security: grant the NDES service account Read + Enroll; do not grant Enroll to broad groups.
    • Issuance Requirements: leave CA certificate manager approval off — SCEP issuance must be automatic.
  4. On the issuing CA, right-click Certificate Templates → New → Certificate Template to Issue and publish all three.

Note the exact template display names — the NDES configuration wizard and the Intune SCEP profile both need them.

Step 3 — Install and configure the NDES role

  1. On the NDES server, open Server Manager → Add Roles and FeaturesActive Directory Certificate Services → Network Device Enrollment Service. Include the IIS management tools when prompted.
  2. Run the AD CS Configuration wizard, select Network Device Enrollment Service, and choose the NDES service account from Step 1.
  3. Select the issuing CA, then map the roles to your templates:
    • RA Information: the Enrollment Agent + CEP Encryption templates.
    • SCEP signing/encryption: generated automatically by the wizard.
  4. Complete the wizard and verify the NDES admin page loads locally: https://localhost/certsrv/mscep_admin/.
  5. Test SCEP enrollment from a browser or curl: https://ndes.contoso.com/certsrv/mscep/mscep.dll/pkiclient.exe?operation=GetCACert should return the CA certificate chain. If it does, NDES is serving.

Keep the NDES server on a maintenance schedule with the CA: expiring RA certificates are the most common cause of “SCEP suddenly stopped working” incidents.

Step 4 — Install the Intune certificate connector

  1. In the Intune admin center, go to Tenant administration → Connectors and tokens → Certificate connectors and download the connector installer.
  2. Run the installer on the connector server and sign in with an account that has the Intune Administrator role. The connector registers itself with your tenant — confirm it shows Active (green) in the admin center.
  3. The connector needs outbound TCP 443 to *.manage.microsoft.com and *.dm.microsoft.com. If you use a proxy, configure it during setup and allow the connector service account through.
  4. The connector polls Intune for pending SCEP challenges — there is nothing to publish inbound for the connector itself. Only the NDES URL needs to be reachable from devices.

Step 5 — Create the trusted root profile

Devices must trust your CA chain before the SCEP certificate is useful. Deploy the root (and issuing) CA certificates first:

  1. Export the root CA certificate (and issuing CA certificate) as Base-64 .cer files.
  2. In Intune admin center: Devices → Configuration profiles → Create profile. Platform: match your devices; Profile type: Templates → Trusted certificate.
  3. Upload the root CA .cer, set destination store to Computer certificate store – Root (Windows) or the platform equivalent, and assign to the same groups as the SCEP profile.
  4. Repeat for the issuing CA certificate into the Intermediate store where the platform requires it.

Step 6 — Create the SCEP profile

  1. Devices → Configuration profiles → Create profile. Platform: match your devices; Profile type: Templates → SCEP certificate.
  2. Certificate type: Device (recommended for Wi-Fi/VPN machine auth) or User.
  3. SCEP Server URLs: add your NDES URL, for example https://ndes.contoso.com/certsrv/mscep/mscep.dll. You can add a second NDES server URL for failover.
  4. Root Certificate: select the trusted root profile from Step 5.
  5. Extended Key Usage: add Client Authentication; add Server Authentication only if the scenario needs it.
  6. Subject name format: Custom is typical — for example CN={{DeviceId}} for device certs or CN={{UserPrincipalName}} for user certs.
  7. Subject Alternative Name: add UPN ({{UserPrincipalName}}) or DNS as your RADIUS/VPN policy requires.
  8. Certificate validity period: match the template (for example, 1 year). Set renewal threshold to ~20% so devices renew well before expiry.
  9. Key storage provider: use TPM-backed keys (Windows) or the Secure Enclave / StrongBox equivalent where available.
  10. Assign to a pilot group first, then roll out broadly once validation passes.

Step 7 — Deploy and validate

  1. On a pilot device, sync Intune policy and confirm both the trusted root and SCEP profiles show Succeeded under device configuration status.
  2. Verify the certificate landed: certlm.msc (Windows), Settings → General → VPN & Device Management (iOS/iPadOS), or Settings → Security → Credential storage (Android).
  3. Validate the end scenario: join the 802.1X Wi-Fi SSID or connect the VPN with EAP-TLS, and confirm authentication succeeds against your RADIUS/NPS logs.
  4. In the Intune admin center, check Devices → Monitor → Certificate connector events and the SCEP profile’s per-device status for failures.

Renewal, revocation and lifecycle

  • Renewal is automatic while the device stays enrolled and in scope: Intune issues a fresh challenge when the renewal threshold is reached. Keep devices syncing regularly.
  • Revocation: wipe or retire removes the SCEP certificate from the device. For lost or compromised devices, also revoke the certificate on the CA and publish the CRL — Intune does not auto-revoke on the CA.
  • Monitor expiry: report on SCEP profile status and CA-issued certificate expiry monthly. A device that misses its renewal window will fail Wi-Fi/VPN auth with no other warning.
  • Template changes: changing key length, EKU or validity requires a new template version plus a profile update — plan a re-enrollment window.

Security hardening checklist

  • Publish NDES only through a reverse proxy or WAF with TLS 1.2+, and restrict the /certsrv/mscep_admin page to administrators.
  • Keep the NDES service account least-privilege: Request Certificates on the CA plus Enroll on the three NDES templates — nothing else.
  • Set short SCEP challenge validity (Intune default) and never reuse challenge passwords across requests.
  • Enable auditing on the CA (issue/manage events) and alert on unexpected issuance spikes.
  • Prefer TPM / Secure Enclave-backed keys and require device compliance (healthy attestation, OS version floor) before the SCEP profile applies.

Troubleshooting notes

SCEP profile stuck at “Pending”

The device cannot reach the NDES URL, or the challenge expired. Verify DNS and 443 to the NDES FQDN from the device network, then re-sync. Check the connector status is Active in the admin center.

Error: challenge validation failed

The NDES server clock is skewed, the RA/enrollment-agent certificates expired, or the connector cannot reach Intune. Run certutil -pulse, check RA cert expiry in certlm.msc, and review the connector logs under %ProgramData%\Microsoft\Intune\NDESConnectorSvc\Logs.

CA denies the request (permissions)

The NDES service account lacks Enroll on the SCEP device template, or manager approval is enabled on the template. Fix template permissions and ensure automatic issuance.

Certificate issued but Wi-Fi/VPN rejects it

Subject/SAN or EKU mismatch with the RADIUS policy. Compare the issued certificate (certutil -store my) against NPS connection-request policy conditions, and confirm the full chain validates on the client.

Renewals failing at scale

Usually an expired RA certificate or a changed NDES URL/TLS certificate. Renew the RA certs via the NDES admin page, then confirm GetCACert responds before re-pushing profiles.

Learn more

Key takeaway: A reliable NDES deployment is four coordinated pieces — a least-privilege issuing CA with purpose-built templates, a reachable NDES URL, a healthy Intune certificate connector, and SCEP profiles whose subject, EKU and validity match what your Wi-Fi and VPN policies actually expect.