Microsoft Cloud PKI: Certificates for Intune Devices Without an On-Premises CA

Microsoft Cloud PKI is a certificate authority service that Microsoft hosts and that you manage from the Intune admin center. You create a root CA and one or more issuing CAs in your tenant, assign a SCEP certificate profile to a group of enrolled devices, and the service issues, renews and revokes each certificate for its whole life. Microsoft's documentation describes it as automating SCEP-based certificate issuance and renewal without on-premises NDES or connector infrastructure; a SCEP service in the cloud acts as the certificate registration authority that NDES used to be.

That names what it replaces: Active Directory Certificate Services on a domain-joined server, the Network Device Enrollment Service role, the Intune Certificate Connector beside it, the reverse proxy that published NDES, and the yearly cycle of patching and renewing the NDES service certificates. Cloud PKI removes the NDES server, the connector and the publishing; whether it removes AD CS itself depends on the deployment model, covered in the third section.

Intune itself does not change: devices enroll the same way, the SCEP and trusted certificate profiles are the same profile types, and Wi-Fi and VPN profiles reference the certificate as before.

Cloud PKI issues leaf certificates to users and devices enrolled in Intune on Windows, iOS and iPadOS, macOS and Android. The typical certificate is a client authentication certificate requested from the issuing CA through a SCEP profile and used for certificate-based authentication: 802.1X on a wired or wireless network through a RADIUS server such as NPS, a VPN that authenticates the device or the user by certificate. A user certificate carries the identity from Microsoft Entra ID; a device certificate carries the device identity.

Three boundaries matter:

• Enrolled devices only. A phone protected only by app protection policies, with no enrollment, cannot receive a certificate from Cloud PKI.
• No server certificates. Microsoft's documentation is explicit that Cloud PKI does not provide the TLS/SSL certificates for the RADIUS or VPN server side. NPS, VPN gateways and web servers keep getting their certificates from AD CS or a public CA, and devices need a trusted certificate profile for that server's root.
• Two profiles, not one. Every SCEP profile must be paired with a trusted certificate profile that installs the Cloud PKI root on the device first, or issuance fails. Cloud PKI does not support the Any Purpose extended key usage, and any variable in the subject name must exist on the Entra user or device object, or the certificate is not issued.

If your main certificate consumers are servers, code signing, smart cards or devices that will never enroll in Intune, Cloud PKI is not the tool for those; it is the tool for the managed laptops, phones and tablets that must prove who they are to the network.

Microsoft's deployment-model documentation names two options.

Cloud PKI root CA. You create the root CA in Intune, then one or more issuing CAs under it: a two-tier hierarchy that lives entirely in Microsoft's service. Private keys for licensed CAs are held in Azure Managed HSM, and Intune hosts the certificate revocation list for each CA. This is the model for a cloud-only firm, for a firm retiring Active Directory, and for anyone whose on-premises CA exists only to feed NDES.

Bring your own CA (BYOCA). The issuing CA is created in Intune but anchored to a private CA you already run, such as AD CS: your root stays where it is and signs the Cloud PKI issuing CA, so devices and RADIUS servers that trust your root need no new trust. This is the model for a firm that keeps AD CS for servers and smart cards and wants Intune devices on the same chain. Microsoft notes that root CAs and BYOCA issuing CAs can coexist in one tenant.

Decision rule: if AD CS will still exist in two years for a reason other than NDES, choose BYOCA; if NDES was the only reason, choose the Cloud PKI root and plan to retire the server.

Microsoft's Cloud PKI pages publish the limits a designer needs.

The three-CA cap is the one that bites. A root plus one issuing CA uses two slots; a root with two issuing CAs, or a BYOCA issuing CA beside a Cloud PKI root and its issuing CA, uses all three. Design the hierarchy on paper first, because deleting a CA to open a slot takes its issued certificates with it, and do not build production on trial CAs: their software-backed keys stay software-backed.

Cloud PKI is licensed per user and needs Intune Plan 1 in the tenant first; Microsoft's pricing page carries the footnote that every advanced Intune capability requires an Intune Plan 1 subscription as the base.

Microsoft list price, October 2026 price list.

Three situations cover almost every tenant. A Business Premium tenant holds Intune Plan 1 through the suite and buys the $2.00 add-on: 60 users is $120.00 per month, $1,440 per year. An E3 tenant also buys the add-on: Microsoft's 2026 packaging update moved Plan 2, Remote Help and Advanced Analytics into E3 and placed Cloud PKI in E5 (see 2026 pricing and packaging changes). An E5 tenant pays nothing more. The Suite arithmetic is in Intune Plan 1 vs Plan 2 vs Intune Suite: one capability, buy the add-on; two or more that pass $10.00 together, buy the Suite.

Worked example at list prices: a 120-user firm on Business Premium ($22.00) that needs certificate-based Wi-Fi and nothing else from the Suite adds Cloud PKI at $2.00: $240.00 per month, $2,880 per year, beside the $2,640 per month for Business Premium. The Windows Server that ran NDES, its license, its backup and the hours spent on it come off the books.

Nine steps, in the order that avoids an outage:

1. Inventory the certificate consumers. Every template AD CS issues and who uses it: device Wi-Fi, user VPN, server TLS, smart card logon, code signing, S/MIME, LDAPS. Only the device and user authentication templates move.
2. Pick the model with the decision rule above.
3. License the users: Cloud PKI add-on, Intune Suite or E5 for every user whose device will request a certificate, with Intune Plan 1 present.
4. Create the hierarchy: root CA (or a BYOCA issuing CA signed by your root), then the issuing CA, with validity and key sizes from the table above; export the certificates.
5. Trust the root on the servers. Add the Cloud PKI root to the trusted root store on the NPS or RADIUS servers and the VPN gateway, and confirm those servers' own TLS certificates remain valid and trusted by devices.
6. Pilot the two profiles. Trusted certificate profile first, then the SCEP profile, to a pilot group on one platform; confirm that the certificate arrives, the subject name resolves and the device authenticates to Wi-Fi.
7. Repoint the Wi-Fi and VPN profiles to the Cloud PKI certificate, platform by platform, group by group.
8. Retire the NDES chain. Once every in-scope device holds a Cloud PKI certificate, remove the SCEP profiles that target NDES, uninstall the Intune Certificate Connector and decommission the NDES server; Microsoft's connector documentation notes that a tenant no longer using SCEP can keep only the PFX connector or remove NDES.
9. Decide the fate of AD CS. In the root model it is decommissioned once the remaining templates have new homes, a project of its own; in the BYOCA model it stays, smaller.

Budget two to four weeks of elapsed time for a 100-to-300-device fleet, most of it waiting for devices to check in and renew. Active Directory Certificate Services (AD CS) Migration runs steps 1 to 9 at $3,950, fixed price, quoted in writing before work begins; Microsoft Intune Initial Setup for Windows Device Management ($6,500 per project) builds the enrollment and profile foundation if the tenant lacks one; and retiring on-premises Active Directory covers whether the domain controllers can go too.

Three cases. The certificates are for servers (a web server, an LDAPS listener, a RADIUS server's own identity); Cloud PKI does not issue those. The devices are not in Intune and never will be (printers, badge readers, lab instruments); they keep an on-premises or public CA. The requirement is smart card logon to Active Directory or code signing; both stay on AD CS.

For the laptop and phone fleet that must prove itself to the Wi-Fi and the VPN, Cloud PKI is the simpler service. When the VPN itself is on the way out, Entra Private Access vs VPN covers the next step, and a Mac fleet that needs the same certificates is covered in managing Macs with Intune.

What is Microsoft Cloud PKI?

A certificate authority service inside Microsoft Intune. You create root and issuing CAs in your tenant, and the service issues, renews and revokes user and device certificates for Intune-enrolled Windows, iOS/iPadOS, macOS and Android devices through SCEP profiles, with no NDES server or certificate connector on-premises.

Does Cloud PKI replace Active Directory Certificate Services?

It replaces the part of AD CS that issued device and user authentication certificates through NDES. It does not issue server TLS, smart card or code-signing certificates, so a firm that needs those keeps AD CS or a public CA. The bring-your-own-CA model lets the Cloud PKI issuing CA chain to your existing root.

How much does Microsoft Cloud PKI cost?

$2.00 per user per month on an annual commitment ($24.00 per year) as a standalone add-on, or $10.00 per user per month inside the Microsoft Intune Suite; Microsoft 365 E5 includes it from 1 July 2026 (Microsoft list price, October 2026 price list). Intune Plan 1 is a prerequisite.

Does Cloud PKI work with NPS and RADIUS for Wi-Fi?

Yes, on the device side: a device presents its Cloud PKI certificate to the RADIUS server over 802.1X. The RADIUS server must trust the Cloud PKI root, and it keeps its own server certificate from AD CS or a public CA, because Cloud PKI does not issue server certificates.

How many certification authorities can I create in Cloud PKI?

Three per tenant, and root CAs, Cloud PKI issuing CAs and BYOCA issuing CAs all count toward that number. Trial CAs have their own cap of three and use software-backed keys that cannot become HSM-backed.

• Microsoft Cloud PKI for Microsoft Intune — Microsoft Learn, checked 2026-10-11
• Deployment models for Microsoft Intune cloud PKI — Microsoft Learn, checked 2026-10-11
• Microsoft Intune cloud PKI fundamentals — Microsoft Learn, checked 2026-10-11
• Configure Microsoft Cloud PKI root and issuing CA — Microsoft Learn, checked 2026-10-11
• Bring your own certificate authority with Cloud PKI — Microsoft Learn, checked 2026-10-11
• Use SCEP certificate profiles with Microsoft Intune — Microsoft Learn, checked 2026-10-11
• Certificate connectors for Microsoft Intune — Microsoft Learn, checked 2026-10-11
• Planning guide to move to Microsoft Intune — Microsoft Learn, checked 2026-10-11
• Microsoft Intune plans and pricing — Microsoft, checked 2026-10-11
• Microsoft NCE price list (US), October 2026: Microsoft Cloud PKI, Microsoft Cloud PKI for FLW, Microsoft Intune Suite, Microsoft Intune Plan 1, Microsoft 365 E5, Microsoft 365 Business Premium (Microsoft list price, October 2026 price list)