Migrating From NDES to Cloud SCEP: A Step-by-Step Guide for Intune Admins

If you are planning an NDES to cloud SCEP migration, you are not alone. Many Intune admins are working through this same transition as on-premises public key infrastructure (PKI) systems age and cloud-first IT strategies demand simpler, more resilient certificate delivery. This guide covers the architectural shift, the prerequisites, a step-by-step migration walkthrough, and how to validate and roll back if something goes wrong.

What Is NDES and How Does It Work With SCEP?

Network Device Enrollment Service (NDES) is a Windows Server role that acts as a registration authority (RA) between Intune and your on-prem certificate authority (CA). NDES implements the Simple Certificate Enrollment Protocol (SCEP), which allows managed devices without domain credentials to automatically request and receive X.509 certificates.

In an Intune-managed environment, the flow looks like this:

1. Intune pushes a SCEP certificate profile to a device.
2. The device contacts the NDES endpoint to submit a certificate signing request (CSR).
3. NDES validates the request and forwards it to the CA.
4. The CA issues the certificate back through NDES to the device.

NDES itself runs as an Internet Server Application Programming Interface (ISAPI) extension under Internet Information Services (IIS). That means it requires an IIS role on the host server, a CA connection, and (for Intune deployments) either direct internet exposure or an Entra Application Proxy in front of it.

Why Admins Are Moving: NDES Limitations and Operational Pain

The NDES-based SCEP stack works, but it carries real operational weight. Understanding these limitations is the reason most admins begin looking at cloud alternatives.

Infrastructure Overhead

NDES requires a dedicated Windows Server instance running IIS. In practice, that means patching the OS, patching IIS, patching the Intune Certificate Connector, and monitoring the service account. Version 1 certificate templates used by NDES do not support autoenrollment, so the NDES service certificate must be renewed manually (Microsoft Learn). Miss that renewal and certificate issuance stops for every device in scope.

No Native High Availability

A standard NDES deployment is a single server. If that server goes down, SCEP issuance stops. Achieving active/active redundancy requires a second NDES server, a second Certificate Connector, a second Entra Application Proxy registration, and a load balancer in front of them all. That is a significant architecture for what amounts to a certificate relay.

Attack Surface Vulnerability

NDES exposes an IIS endpoint, historically on TCP 443, that handles inbound certificate requests from internet-connected devices. In November 2024, Microsoft disclosed CVE-2024-49019 (CVSS 7.8), an AD CS privilege escalation vulnerability that affects version 1 certificate templates, the same template schema that NDES uses by default.

An attacker who could manipulate the Extended Key Usage field in a certificate request could escalate to Domain Administrator (Microsoft Security Response Center, November 2024). This is not a theoretical risk for organizations that have left default NDES templates unchanged.

Entra Application Proxy Dependency

For cloud-joined or hybrid-joined devices, NDES must be reachable from the internet. Microsoft’s recommended path is Entra Application Proxy, which adds another component to configure, maintain, and monitor. Any connector outage or token expiration in the proxy layer can silently break certificate renewal for all enrolled devices.

What Changes Architecturally With Cloud SCEP?

When you move from NDES to a cloud SCEP gateway, the on-prem relay disappears. Instead of Intune pointing devices at an IIS-hosted NDES URL, it points them at a cloud-hosted SCEP endpoint run by your chosen provider.

The CA relationship shifts as well. With NDES, the on-prem CA does the signing. With a cloud SCEP gateway, the CA can be cloud-hosted (a managed CA provided by your vendor) or a bring-your-own CA (BYOCA) model where the cloud gateway relays requests to a CA you control. Either way, you remove the NDES server, the Certificate Connector, and the Entra Application Proxy from the certificate issuance path.

For Intune, the change is an update to the SCEP URL in your certificate profile. Devices do not need to be re-enrolled. The profile update deploys silently at the next Intune sync.

Prerequisites Before You Begin

Before touching any Intune profiles, confirm these prerequisites are in place.

Intune:

• Microsoft Intune Plan 1 or Intune Suite license
• Existing SCEP certificate profiles you can clone and modify
• Device groups already in scope (do not change group targeting during the migration)

Entra ID:

• Devices are Entra ID-joined or Hybrid Entra ID-joined
• Users and devices are synced from Active Directory to Entra ID (required if using on-prem CA for BYOCA)

Cloud SCEP provider:

• Cloud SCEP endpoint URL from your provider
• Root CA and intermediate CA certificates from the cloud PKI, ready to deploy as trusted certificate profiles in Intune
• BYOCA connector or cloud CA configured at the provider side, depending on your CA model

Documentation:

• Inventory of all existing NDES-backed SCEP profiles in Intune (export from the Intune admin center)
• List of certificate templates in use (template name, key usage, subject name format, SAN configuration, validity period)

NDES to Cloud SCEP Migration: Step-by-Step Walkthrough

Step 1: Inventory Your NDES SCEP Profiles and Certificate Templates

Log in to the Intune admin center and export a list of all SCEP certificate profiles currently pointing to your NDES URL. For each profile, record:

• The SCEP server URL
• The certificate template it references
• The subject name format
• Any Subject Alternative Names (SANs)
• The key size and algorithm
• The validity period
• The assigned device groups

Cross-reference this with the certificate templates configured on your CA. Note the template schema version (version 1 vs. version 2+) and which templates are in active use by Intune.

Step 2: Configure the Cloud SCEP Endpoint

Stand up your cloud SCEP gateway and issue a SCEP URL. If you are using a BYOCA model, complete the CA connector configuration at this stage so your cloud provider can relay signing requests to your existing CA. If you are using the provider’s managed CA, configure the issuing CA hierarchy now and obtain the root and intermediate CA certificates.

Test the SCEP URL directly from a browser before proceeding. A valid NDES-style SCEP endpoint returns an HTTP 400 when you GET the base URL without a payload. Confirm the endpoint is reachable and returns a sensible response.

Step 3: Deploy Trusted Root and Intermediate CA Certificates

Before any device can trust certificates issued by the new cloud CA, Intune must distribute the CA chain. Create trusted certificate profiles in Intune for both the root CA and intermediate CA from your cloud provider. Assign these profiles to the same device groups that will receive the new SCEP profiles. Deploy and confirm the CA certificates are installed on a test device before proceeding.

Step 4: Clone and Update SCEP Certificate Profiles for a Pilot Group

Do not modify your existing NDES-backed profiles. Clone each profile and update only the SCEP server URL to point to your cloud endpoint. Set the assignment to a small pilot device group (10 to 20 devices covering Windows, iOS, Android, and macOS if all platforms are in scope).

Leave all other settings identical to the original profile:

• Subject name format
• SAN values
• Key size
• Validity period
• EKU fields

Changing anything else during this step introduces variables that make troubleshooting harder.

Step 5: Validate Certificate Issuance on the Pilot Group

Trigger an Intune sync on pilot devices. Confirm that devices receive and install the new certificate. Check these items for each platform:

• Certificate is present in the device certificate store.
• Subject name and SAN values match what the profile specifies.
• Issuing CA chain is trusted (no certificate warnings).
• 1X authentication, VPN authentication, or other dependent services work with the new certificate.

If any device fails, check the Intune device diagnostics report and the cloud SCEP provider logs before expanding the scope. Do not proceed to full rollout until the pilot is clean.

Step 6: Roll Out to All Device Groups

Once the pilot validates cleanly, update the assignment on your new SCEP profiles to include all production device groups.

Stagger the rollout if your device count is large: begin with a department or site, monitor for 24 to 48 hours, then expand. Intune processes profile assignments progressively, so devices will migrate as they check in.

Keep your original NDES-backed profiles active and assigned to no devices during this window. They serve as your documented rollback path.

Step 7: Validate at Scale and Decommission NDES

After all devices have checked in and received the new cloud-issued certificate, confirm the following:

• NDES server logs show no new certificate requests in the last full business cycle.
• Intune reporting shows 100% success on the new SCEP profiles.
• Helpdesk reporting shows no tickets related to certificate or authentication failure.

Once you are satisfied, unassign and delete the old NDES-backed SCEP profiles. Then begin the NDES decommission process:

1. Remove the Certificate Connector from the server.
2. Remove the Entra Application Proxy connector.
3. Schedule the Windows Server for retirement or repurposing.

Validating and Rolling Back Your NDES to Cloud SCEP Migration

Keep NDES running and healthy until Step 7 is complete. This is your rollback. If cloud SCEP issuance fails at scale, you can reassign the original NDES-backed profiles to your device groups in Intune, and devices will revert to requesting certificates from NDES at their next sync.

Plan your migration window around certificate expiry. If your existing certificates are set to renew at 80% of their validity period and validity is 12 months, you have roughly 2.5 months from issuance before Intune starts pushing renewal requests. Time your migration so the cutover happens well before the renewal window opens on your existing device population. Attempting a platform migration and a mass renewal simultaneously creates troubleshooting noise.

For 802.1X-dependent environments, test authentication end-to-end on your 802.1X authentication configuration before decommissioning NDES. A certificate that is syntactically valid may still fail RADIUS validation if the SAN format or EKU does not match what the RADIUS server expects.

How SecureW2 Handles Cloud SCEP for Intune-Managed Devices

JoinNow Dynamic PKI is a cloud-native PKI platform that includes a cloud SCEP gateway purpose-built for Intune-managed devices. It serves as the destination for your NDES to cloud SCEP migration, replacing the entire NDES stack with a managed service. SecureW2 operates at 99.999% availability.

The SecureW2 Dynamic PKI platform handles both the CA and the SCEP gateway in a single managed service. Admins configure an Intune SCEP profile pointing to the SecureW2 SCEP endpoint, and SecureW2 issues certificates from a cloud CA that it manages on your behalf, or relays requests to your existing on-prem CA in a BYOCA model. There is no IIS to patch, no Certificate Connector to maintain, and no Entra Application Proxy to configure.

Beyond issuance, SecureW2 integrates with JoinNow Cloud RADIUS so the same certificates that authenticate devices to Intune can also authenticate them to your network. At the moment of connection, Cloud RADIUS validates the device certificate against the SecureW2 CA and checks real-time identity and compliance signals from Entra ID. If a device is disabled in Entra ID or falls out of Intune compliance, Cloud RADIUS revokes network access without waiting for certificate expiry.

CertIQ ML Anomaly Detection, built into the SecureW2 platform, monitors certificate issuance and usage patterns. If an anomaly appears during or after your migration, such as an unexpected spike in certificate requests or a certificate being used from an unrecognized source IP, the platform flags it before it becomes a security event.

For admins who are not ready to retire their on-prem CA, SecureW2 supports a BYOCA model. Your on-prem CA remains the signing authority; SecureW2 acts as the cloud SCEP RA. This is a common first step for organizations that need to migrate off NDES now but are not ready to move the CA itself.

If you are planning an NDES to cloud SCEP migration and want to see the SecureW2 SCEP gateway configured in Intune, schedule a demo to walk through the setup against your specific certificate profile requirements.

---

Frequently Asked Questions

What is the difference between on-premises NDES and a cloud SCEP gateway?

On-premises NDES is a Windows Server role that acts as a registration authority between Intune and a local CA, requiring IIS, a Certificate Connector, and typically Entra Application Proxy for internet-accessible device enrollment. A cloud SCEP gateway replaces that stack with a cloud-hosted endpoint managed by a PKI provider. Intune points SCEP certificate profiles at the cloud URL instead of the NDES server, and the cloud provider issues certificates without any on-prem relay infrastructure.

Can I replace NDES with a cloud certificate authority?

Yes. Cloud PKI platforms act as a full replacement for both NDES and the on-prem CA. If you do not have NDES infrastructure and want to use a SaaS-based solution for certificate deployment via Intune, you can use a cloud PKI service that provisions and manages all components of SCEP, including the registration authority and the CA. Organizations that want to keep their existing on-prem CA can use a BYOCA model where the cloud SCEP gateway relays signing requests to the on-prem CA while replacing the NDES relay itself.

How do I configure SCEP certificate profiles in Microsoft Intune after migrating to cloud SCEP?

After standing up your cloud SCEP endpoint and deploying the new CA chain as trusted certificate profiles, create new SCEP certificate profiles in Intune with the cloud SCEP URL in the SCEP server URL field. Keep all other settings (subject name format, SAN values, key usage, validity period) identical to your existing NDES-backed profiles. Assign the new profiles to a pilot group first, validate, then expand to all device groups. The existing NDES-backed profiles remain untouched and serve as your rollback option.

What are the infrastructure requirements to move from NDES to cloud SCEP in Intune?

You need an active Intune subscription, devices that are Entra ID-joined or Hybrid Entra ID-joined, and a cloud SCEP provider with an active endpoint and a configured CA (managed or BYOCA). On the Intune side, you need the ability to deploy trusted certificate profiles for the new CA chain and SCEP certificate profiles with the updated SCEP URL. No on-prem Windows Server, IIS instance, Certificate Connector, or Entra Application Proxy is required for cloud SCEP issuance.

What is SCEPman, and how does it differ from other cloud SCEP options?

SCEPman is a third-party cloud SCEP gateway that runs in your Azure tenant. It replaces NDES and uses Azure Key Vault to manage the CA key. Other cloud SCEP providers, including SecureW2, offer fully managed services where the provider operates the infrastructure in their own cloud environment. The key distinction is whether you want to manage the cloud infrastructure yourself (tenant-hosted solutions) or hand it to a provider with an SLA (managed service). For teams moving off NDES to reduce operational burden, a fully managed service removes the most overhead.