If you’ve spent time maintaining a traditional ADCS stack for Intune certificate delivery — a root CA, an issuing CA, NDES, the Intune Certificate Connector, proxy rules so cloud devices can hit your on-prem NDES server — you know exactly how much operational weight that architecture carries. And you know how badly it ages as your fleet moves toward Entra join.
Microsoft Cloud PKI, now rolling out to Microsoft 365 E5 tenants as part of the expanded Intune Suite, eliminates that entire stack for your Intune-managed devices. No NDES. No connector. No on-prem servers in the certificate issuance path. Let’s look at what that actually means, how it works, and where the hard limits are.
What Cloud PKI replaces
Here’s the traditional architecture for Intune SCEP-based certificate delivery — and what each component maps to in Cloud PKI:
| Traditional stack | Cloud PKI equivalent |
|---|---|
| Root CA (offline Windows Server) | Cloud PKI Root CA (Microsoft-hosted) |
| Issuing/Subordinate CA | Cloud PKI Issuing CA (Microsoft-hosted) |
| NDES server | Built-in Cloud PKI SCEP service |
| Intune Certificate Connector | Eliminated entirely |
| Proxy/reverse proxy for NDES | Eliminated entirely |
The Cloud PKI certificate registration authority replaces the need for an on-premises CA, NDES, and the Intune certificate connector. That’s meaningful — in a typical traditional deployment those three components each have their own maintenance surface, their own failure modes, and their own security exposure.
Architecture overview
The certificate flow works as follows. When a device checks in with the Intune service, it receives the trusted certificate profiles and SCEP profile. Based on the SCEP profile, the device generates a certificate signing request (CSR) — the private key is created on the device and never leaves it. The SCEP service validates the request, after which the issuing CA signs the CSR and the signed certificate is delivered back to the device.
Key security property: The private key is generated on the device and never transmitted. Only the CSR (public key + subject info) leaves the device.
Two deployment models: Cloud root vs. BYOCA
Cloud PKI gives you a choice at setup time that you cannot change later, so it’s worth understanding upfront.
Model 1: Full cloud PKI (Cloud root CA)
With the Cloud PKI root CA approach, you create one or more PKIs within a single Intune tenant, deploying a two-tier hierarchy with multiple issuing CAs subordinate to the root. These CAs are not public — both the root and issuing CAs are created in the cloud, private to the Intune tenant.
This is the clean-slate path. You get a fully managed, Microsoft-hosted PKI hierarchy. No on-prem servers involved at any point in the chain. If your organization is cloud-native, or you’re standing up a new Intune deployment from scratch and don’t need to preserve an existing trust chain, this is the right choice.
Model 2: Bring Your Own CA (BYOCA)
With BYOCA, you deploy Cloud PKI using your own private CA. You create a cloud issuing CA anchored to a private CA such as Active Directory Certificate Services (ADCS). When you create the Cloud PKI BYOCA issuing CA, a Certificate Signing Request is generated in Intune, which you then sign using your on-prem CA and upload back.
This is the hybrid path. Your existing ADCS root chain remains the trust anchor. The Cloud PKI issuing CA extends that trust into the cloud, so Intune-managed devices receive certificates that chain to your existing root — meaning existing relying parties (NPS, Wi-Fi RADIUS, VPN gateways) that already trust your ADCS PKI will trust the new certificates without requiring you to push a new root CA to everything.
BYOCA won’t remove all need to maintain on-premises servers or hardware — your ADCS root still needs to exist and be operational for the initial signing, and the ADCS AIA/CDP URLs need to remain reachable for chain validation.
ADCS AIA warning: ADCS uses a default LDAP AIA location. Non-domain-joined devices cannot follow an LDAP AIA to validate the chain. Ensure your ADCS issuing CA has an HTTP AIA/CDP configured and publicly resolvable before going down the BYOCA path.
Setting it up: the step-by-step
Prerequisites
- License: Microsoft Intune Suite, Microsoft 365 E5, or the Cloud PKI standalone add-on
- Role: Intune Administrator, or a custom role with Cloud PKI permissions (Read CAs, Create CAs, Revoke issued leaf certificates)
- Devices: Must be Entra joined or hybrid Entra joined and enrolled in Intune
Step 1: Create the root CA
In the Intune admin center, navigate to Tenant administration > Cloud PKI > Create. Select Root CA as the CA type. Configure:
- Common Name (CN) for the root CA
- Validity period — configure this carefully, it cannot be changed after creation
- Key size: RSA 2048, 3072, or 4096 — note: EC keys are not currently supported
- Extended Key Usage
Important: You will not be able to edit CA properties after creation. If you later need to add an EKU, you must create a new CA. Plan your subject, validity period, and EKUs carefully before clicking Create.
Step 2: Create the issuing CA
Back in Tenant administration > Cloud PKI, create a second CA. Select Issuing CA and set the Root CA source to Intune (for full cloud PKI) or Bring your own root CA (for BYOCA). When the issuing CA is created, Cloud PKI automatically provisions the built-in SCEP service.
After creation, navigate to the issuing CA properties and copy the SCEP URI — you’ll need it when creating SCEP certificate profiles.
Step 3: Download and deploy the CA trust certificates
Download the public key for both the root CA and the issuing CA from their respective Properties pages. The root and issuing CA certificates must be installed on all relying parties — Wi-Fi RADIUS/NPS servers, VPN gateways, and any other authentication endpoints.
You’ll also create Trusted Certificate profiles in Intune to push the CA chain to managed devices, one per platform (Windows, iOS, macOS, Android).
Step 4: Create SCEP certificate profiles
In Devices > Configuration profiles, create a SCEP profile for each platform. Key settings:
| Setting | Guidance |
|---|---|
| SCEP Server URL | Paste the SCEP URI copied from the issuing CA properties |
| Certificate type | User or Device depending on scenario |
| Subject name format | CN={{UserPrincipalName}} for user certs; CN={{DeviceName}} for device certs |
| Extended key usage | Client Authentication (OID 1.3.6.1.5.5.7.3.2) for 802.1x / VPN |
| Renewal threshold | Default 20% of validity period; Cloud PKI handles renewal automatically |
| Root certificate | Point to the trusted certificate profile for your root CA |
Assign profiles to a pilot group first before rolling broad.
Step 5: Push trust certs to relying parties
If your NPS/RADIUS server or VPN concentrator doesn’t already trust the new CA chain, install the downloaded root and issuing CA public keys there. For domain-joined NPS servers, GPO to the Trusted Root and Intermediate certificate stores works cleanly. For cloud-based RADIUS services, follow their documentation for adding custom CA trust.
What you can and can’t do with Cloud PKI
What it handles well
- Certificate issuance, renewal, and revocation for all Intune-supported platforms (Windows, iOS/iPadOS, macOS, Android)
- Automatic certificate renewal — devices request a new certificate when the existing one is within 20% of its validity period
- CRL publication — the CRL is valid for 7 days, refreshed every 3.5 days and immediately upon any revocation
- Multiple issuing CAs under the same root (useful for separating user and device cert issuance, or segmenting by platform)
Hard limits to know before you commit
- RSA only: Cloud PKI supports RSA 2048, 3072, and 4096-bit keys. EC keys are not currently supported.
- Intune-managed devices only: Endpoints must be Entra joined or hybrid Entra joined and enrolled in Intune. Domain-joined-only servers and non-Intune-managed devices stay on ADCS.
- No server certificates: Cloud PKI does not issue TLS/SSL server certificates. Your NPS server cert, VPN gateway cert, and internal web service certs must come from elsewhere.
- NPS + pure Entra join: If using on-premises NPS for 802.1x and your devices are purely Entra joined (no AD accounts), authentication will fail. NPS requires the authenticating principal to have an AD account. Consider a cloud RADIUS service (EZRADIUS, RADIUSaaS, etc.) that integrates natively with Entra ID.
BYOCA AIA gotcha: the one that will bite you
Worth calling out specifically because it’s easy to miss. When you configure a BYOCA issuing CA, the AIA extension in issued certificates reflects whatever AIA your on-prem ADCS issuing CA is configured with. If that CA was set up with the Windows default — an LDAP AIA — then Entra-joined Windows devices and all non-Windows platforms cannot follow that AIA to retrieve the issuing CA cert for chain building.
The fix: before creating your BYOCA issuing CA, ensure your ADCS issuing CA has an HTTP CDP and AIA configured, pointing to a URL reachable from wherever your Intune-managed devices live. To check:
certutil -dump
Run this against your CA and look for the CDP and AIA extensions. If you see only LDAP entries, fix that first before proceeding.
Licensing summary (as of late 2025 / 2026 rollout)
| License | Cloud PKI included? |
|---|---|
| Microsoft 365 E5 | Yes (rolling out 2026) |
| Microsoft Intune Suite (add-on) | Yes |
| Cloud PKI standalone add-on | Yes |
| Microsoft 365 E3 | No — E3 gets Remote Help, Advanced Analytics, Plan 2 only |
| EMS E5 (standalone) | No |
Note that EPM, Enterprise App Management, and Cloud PKI are specific to Microsoft 365 E5 — they were not added to the underlying EMS E5 subscription and are only available with a full Microsoft 365 E5 purchase.
The bottom line
Cloud PKI is a genuine operational improvement for any organization running Intune at scale. Eliminating NDES, the Intune Certificate Connector, and the associated proxy infrastructure removes real maintenance surface and real attack surface — NDES in particular has historically been a source of ESC-family ADCS vulnerabilities when misconfigured.
The BYOCA path makes migration practical for organizations with existing PKI investments, since it lets you preserve your trust chain while eliminating the on-prem issuance infrastructure for your Intune fleet. Full cloud PKI is the right call for greenfield or cloud-native deployments.
Go in clear-eyed on the constraints: RSA only, Intune-managed devices only, no server certs, and NPS 802.1x only works if your devices have AD accounts. Within those boundaries, it’s a solid, well-implemented service.
Hope this helps!
É
