Microsoft Cloud PKI: certificate management without NDES or on-premises servers

Certificate management is one of the most underestimated challenges in endpoint management. Anyone managing devices with Intune and using SCEP certificates for Wi-Fi, VPN, or internal authentication knows the classic picture: an NDES server (Network Device Enrollment Service), an Intune Certificate Connector running on it, and an Entra Application Proxy bridging the connection to the outside. Every link in that chain is a potential failure point and demands ongoing maintenance.

From 1 July 2026, something fundamental changes. Microsoft Cloud PKI, the fully cloud-managed certificate authority for Intune, is now included in Microsoft 365 E5. Organisations already on E5 no longer need to purchase a separate add-on. The on-premises certificate chain for device certificates can be decommissioned step by step.

What exactly does Microsoft Cloud PKI replace?

Microsoft Cloud PKI is a cloud-hosted certificate authority that lives entirely within the Intune service. It issues SCEP certificates to Intune-managed devices — Windows, macOS, iOS, and Android are all supported. The area where this saves the most time is the elimination of three on-premises components.

First, the NDES server disappears. NDES is a Windows Server role that handles SCEP communication between devices and the certificate authority. That server needs patching, monitoring, and sometimes its own high-availability configuration. Second, the Intune Certificate Connector goes away — the software running on the NDES server that maintains the connection with Intune. Third, the Entra Application Proxy or a reverse proxy is no longer needed to allow SCEP traffic from outside the network. Cloud PKI handles all of this internally.

The result is a direct SCEP endpoint in the cloud that Intune certificate profiles can call without any on-premises component needing to be present. The CA itself, certificate issuance, renewal, and revocation all run through the Intune portal and the underlying cloud service.

Licensing: what is included where?

Microsoft Cloud PKI is part of the Intune Suite. Until 1 July 2026, the Intune Suite had to be purchased as a separate add-on on top of your existing Microsoft 365 licence, at around two euros per user per month. From that date, the Intune Suite — including Cloud PKI, Endpoint Privilege Management, Enterprise Application Management, and Advanced Analytics — is included in Microsoft 365 E5 at no additional cost.

For organisations on Microsoft 365 E3, this does not apply automatically. There, the Intune Suite remains a separate add-on. Anyone using E3 who wants to deploy Cloud PKI still needs an Intune Suite licence for the users in scope. For E5 environments, the step is simpler: the functionality is available once the tenant has processed the new licence entitlements.

Two architecture models

When setting up Cloud PKI, you choose between two deployment models. The simplest is a fully cloud-hosted two-tier hierarchy: a new root CA and a new issuing CA, both created in the cloud via the Intune admin centre. There is no dependency on existing infrastructure. This model is the fastest to set up and best suited to organisations without an existing PKI, or to environments that deliberately want to start with a new trust chain.

The second model is BYOCA — Bring Your Own CA. Here you create a new cloud-hosted issuing CA that does not have its own root but chains to your existing on-premises root CA. Devices then continue to trust certificates via the existing trust chain already present in their certificate store. This model suits organisations with an existing internal PKI that want to retain that root but move the issuance layer to the cloud.

How does the migration from NDES work?

A migration from NDES to Cloud PKI runs in four steps. The first step is inventorying the current state: which Intune certificate profiles exist, for which device groups, and which SCEP endpoints do they use? That list determines the scope of the migration.

The second step is setting up Cloud PKI in the Intune admin centre. You create the root CA and the issuing CA, or configure the BYOCA model if you want to retain an existing root. This typically takes less than an hour.

The third step is updating the SCEP URL in your existing certificate profiles. The SCEP endpoint URL changes from the on-premises NDES address to the cloud address provided by Cloud PKI. You can keep both profiles — the old and the new — active in parallel during the transition period. Devices receive a certificate from whichever profile responds first.

The fourth step, once all devices have switched over and you have verified that certificate issuance is working correctly, is decommissioning the NDES server, the Certificate Connector, and the Application Proxy configuration. That step delivers immediate maintenance savings.

What Cloud PKI does not do

It is important to understand what falls outside the scope of Cloud PKI, because organisations with broader PKI needs will still require supplementary infrastructure. Cloud PKI is exclusively designed for Intune-managed devices. Devices managed via Jamf, ManageEngine, or another MDM solution are out of scope.

Server certificates are not supported. Anyone who needs to provide internal web servers, RADIUS servers, domain controllers, or network hardware with certificates requires a different CA solution for that. Cloud PKI only issues client certificates to endpoints enrolled in Intune.

Cloud PKI also has technical constraints worth knowing: there is no OCSP support for real-time revocation status, only RSA keys are supported (no ECC), and a maximum of six CAs can be configured per tenant. The CA configuration is immutable after creation — anyone wanting to change settings must create a new CA.

What can you do now?

Three concrete steps to start today. First: check your licence. Are you on Microsoft 365 E5? Then Cloud PKI is available in your tenant now. Open the Intune admin centre and navigate to Tenant administration, Cloud PKI to confirm the feature is active. On E3: check whether the Intune Suite has been added to your subscription.

Second: inventory your certificate infrastructure. How many NDES servers do you have? Which device groups receive SCEP certificates? For which use cases (Wi-Fi, VPN, authentication)? That inventory determines the complexity of the migration and the right choice of architecture model.

Third: assess whether the fully cloud model or BYOCA fits your situation. If your devices already trust an existing internal root CA and you want to retain that trust chain, BYOCA is the appropriate route. If you want a clean start, the fully cloud model offers the lowest maintenance burden in the long run.

Want support setting up Microsoft Cloud PKI, carrying out the NDES migration, or assessing your certificate infrastructure? Contact Zarioh for a practical conversation.