Microsoft Cloud PKI lets Intune issue SCEP certificates without NDES

If you've ever deployed device certificates with Intune, you know the pain. Until recently there was no way around a classic NDES server and connector stack. Microsoft Cloud PKI, generally available since early 2024, finally changes that. More and more tenants I work in want SCEP-based certificate deployment, usually for Wi-Fi or VPN authentication, and keeping NDES infrastructure alive has always been a chore. Cloud PKI makes things easier for admins and users alike.

Microsoft Cloud PKI adds a hosted certificate authority to Intune

Microsoft Cloud PKI is a certificate authority that runs in the cloud and is designed for Intune scenarios. It's licensed either as part of the Intune Suite or as a standalone add-on, and it has been generally available since early this year. There are two models. In the first, Microsoft hosts both the root and the issuing CA. In the second, bring-your-own-root (BYOCA), your cloud CA is anchored to an existing on-prem AD CS root. In most cloud-only Intune environments the hosted model is far simpler, while BYOCA is mainly relevant for organisations with strict compliance or legacy integration requirements.

What it gives you is central issuance of device and user certificates from the cloud, with no on-prem infrastructure at all. You manage everything in the Intune admin center under Tenant administration → Cloud PKI. The CAs are scoped to your tenant and managed from one place. This is roughly how the pieces fit together:

flowchart TD
    Intune["Intune" ] --> CloudPKI["Cloud PKI (CA)" ]
    CloudPKI --> Device["Device" ]
    CloudPKI --> CRL["CRL endpoint" ]
    BYOCA["BYOCA (on-prem CA)" ] -- "optional" --> CloudPKI

Figure: Cloud PKI architecture. Intune requests certificates from the cloud CA, and a BYOCA connection can optionally be added.

SCEP profiles no longer depend on an on-prem NDES server

The main point of Microsoft Cloud PKI for Intune is getting rid of the old SCEP/NDES server stack. In the past, SCEP certificates meant setting up an NDES server, connecting it to Intune and keeping the whole PKI running. With Cloud PKI you need no NDES, no connector machines and no firewall rules. Intune talks to Cloud PKI directly, and SCEP certificate profiles run entirely in the cloud, from initial deployment through renewal. Wi-Fi (typically 802.1X with RADIUS) and VPN authentication behave exactly as before. The difference is that the whole certificate chain now lives in the cloud.

If you're just getting started, the official setup guides help a lot. I'd read the Cloud PKI deployment steps and the guide to configuring the CA, both of which walk through the process step by step.

Practical tip: If you're moving over from an existing SCEP profile setup, check every configuration that depends on it (Wi-Fi, VPN) and get the new root CA certificates out to devices before you switch. If you don't, you'll see connection problems.

Cloud PKI fits Wi-Fi and VPN authentication best

In my projects, Cloud PKI nearly always serves one of two purposes: device authentication on Wi-Fi (RADIUS, 802.1X) or VPN access. The flow is the familiar one. The device receives a trusted SCEP certificate and uses it to authenticate against the network service. Cloud PKI also supports trusted certificate profiles, which push the CA certificates to devices so they trust the new issuing chain.

There are a few things to keep in mind. Revocation is handled centrally, and Cloud PKI automatically publishes a CRL (certificate revocation list) endpoint on the internet, which RADIUS validation, for one, depends on. The limits mostly appear in niche or complex setups, such as multi-CA hierarchies, custom or advanced certificate templates, or smartcard logon. For the bulk of Intune use cases, Cloud PKI covers what you need.

Revocation and CRL management run from the Intune admin center

Revocation and CRL availability have always been sore spots, because certificate validation fails as soon as the CRL endpoint can't be reached. Cloud PKI takes care of this without any effort on your side. Microsoft hosts the CRL, and its endpoint is written into every issued certificate. You can revoke individual certificates straight from the Intune admin center (when a device is compromised or lost, for instance), and auditing through Intune is easy. Distributing trusted certificates is simple too, and the whole process is built to scale without adding complexity.

Some scenarios still require legacy NDES/SCEP infrastructure

Microsoft Cloud PKI has come a long way, but there are still cases where you need the classic NDES/SCEP stack. If on-prem services require certificates from a legacy PKI (AD smartcard logon, say, or on-prem systems that are tightly bound to it), Cloud PKI can't do that yet. The same applies if you need advanced certificate templates or custom extensions that aren't supported today. Hybrid or heavily customised environments will stay on the old stack for the time being.

Cloud PKI has proven itself in production

After several months in production, Microsoft Cloud PKI is fast becoming my default for device certificate deployments through Intune. I no longer patch or troubleshoot on-prem NDES servers, I don't worry about the CRL, and I don't fiddle with connectors. If your environment is aiming for a cloud-first or simpler hybrid setup, Cloud PKI is the right choice. Admins running complex, heavily customised PKI setups will need classic infrastructure a while longer, but for most organisations the direction is clearly towards the cloud.