Microsoft Cloud PKI is a managed cloud certificate authority that lets you retire the on-premises issuing CA and the NDES and connector plumbing you run purely to hand certificates to your endpoints. It is not an enterprise PKI, and understanding exactly where that boundary sits is most of what it takes to use it well.
A great many organizations carry an on-premises certificate authority they would rather not, kept alive for one narrow reason: it issues the Wi-Fi, VPN, and authentication certificates their devices need, and the machinery to deliver those certificates from Intune has always required an on-premises footprint. Cloud PKI removes that footprint for exactly those scenarios. And since it began rolling into Microsoft 365 E5 over the summer of 2026, tenant by tenant with a thirty-day notice in the message center, the estates most likely to want it, the ones modernizing off Active Directory Certificate Services, increasingly already own it.
The footprint it removes
To deliver certificates to Intune-managed devices the traditional way, you stand up an issuing certificate authority, you run the Network Device Enrollment Service in front of it, you publish that through a reverse proxy, and you install the Intune Certificate Connector to broker enrollment requests back to your CA. That is a chain of on-premises servers whose only job, in many estates, is to get a Wi-Fi certificate onto a laptop. Every link in it is something you patch, monitor, and expose, and the NDES role in particular has a long history as a piece of internet-facing infrastructure nobody wanted to be responsible for.
Cloud PKI replaces that chain with a hosted service. It includes a built-in SCEP service and a SCEP validation service, so the registration authority that NDES used to provide now lives in the cloud. For the certificates Cloud PKI issues, the on-premises issuing CA, the NDES role, the reverse proxy, and the Intune Certificate Connector all go away. What remains is a certificate profile in Intune that points at a cloud-hosted issuing CA, and the devices enroll against that. The important qualifier, and I will come back to it, is that this removal is complete only for the scenarios Cloud PKI covers. If you still issue certificates by other means, the connector may still have a job.
The trust-anchor decision
The first real design decision Cloud PKI puts in front of you is where your trust chain is anchored, and there are two answers. You can create a fully cloud-hosted hierarchy, a Cloud PKI root CA with one or more issuing CAs chained beneath it, entirely inside the service. Or you can bring your own certificate authority, generating the issuing CA in Cloud PKI as a subordinate and having your existing private root, whether that is Active Directory Certificate Services or something else, sign its request. Both models can run side by side in one tenant.
The choice is not cosmetic. A cloud root is the clean answer when you are building fresh or when nothing in your environment needs to chain to an existing anchor, and it leaves you with no root private key to protect because the service holds it. Bringing your own CA is the right answer when devices, network appliances, or services already trust your existing root and you want the certificates Cloud PKI issues to be trusted by that same chain without redistributing a new root everywhere. That tends to matter most during a migration, when the cloud-issued certificates have to be accepted by infrastructure that was configured around your old hierarchy years ago.
Two constraints make this a decision you get one attempt at. A certificate authority’s properties cannot be edited after it is created: the key size, the validity period, the extended key usages it can issue are all fixed at birth, and correcting any of them means building a new CA. And the tenant gives you three certificate authority slots in total, with every kind counting against the cap, a cloud root, a cloud issuing CA, a bring-your-own-CA subordinate alike. A root and an issuing CA consume two of the three before you have issued a single certificate. Design the hierarchy on paper first, because the service offers no room to sketch.
It is a certificate issuer for your enrolled endpoints, not a certificate authority for your enterprise.
What it issues, and to what
Be precise about what Cloud PKI actually delivers, because the precision is where the honest boundary lives. It issues through SCEP certificate profiles only. It does not do PKCS or imported PFX certificates, which means any scenario that depends on delivering the same private key to multiple parties is off the table. It issues to Intune-enrolled devices only, across Windows, iOS and iPadOS, macOS, and Android. The intended uses are the endpoint authentication cases: certificate-based Wi-Fi, VPN, wired 802.1x, and the per-user or per-device certificates that prove a managed device is what it claims to be.
Windows Hello for Business is not on that list, and it is worth saying so plainly because the two get mentioned together constantly. Hello is a key-based credential with its own deployment models, none of which run through Cloud PKI. The only real intersection is that a certificate Intune issues can be stored under the Hello key container for scenarios like certificate-based remote desktop, which is certificate storage, not a Hello deployment. If your problem is user sign-in credentials, that is the Windows Hello for Business design conversation from Phase 2, not this one.
The other place people reliably overreach is email. Cloud PKI can support S/MIME signing, because signing needs only the holder’s own key, but it cannot support S/MIME encryption, because encryption requires the same key material to be present across recipients and that means imported PKCS certificates Cloud PKI does not issue. If your requirement is encrypted mail, this is not the tool, and assuming otherwise because the certificate word appears in both places is a mistake worth naming out loud.
The lifecycle you no longer run
Beyond issuance, Cloud PKI takes over the parts of certificate lifecycle that are tedious to run yourself. Intune hosts the CRL distribution point and the authority information access endpoints for each certificate authority, publishes a fresh certificate revocation list every three and a half days with a seven-day validity, and updates it immediately whenever something is revoked. Revocation happens automatically in the events that should trigger it: a device is retired, wiped, or unenrolled, or the certificate profile is removed. That automation is a real part of the value, because certificate cleanup after a device leaves is precisely the housekeeping that gets skipped when it is manual.
Two details are worth holding onto so you design around them rather than discover them. Cloud PKI publishes a CRL but does not offer OCSP, so anything in your environment that expects real-time OCSP validation needs to be checked against CRL-based revocation instead. And revocation is tied to device lifecycle events, not to identity ones, so a certificate is not automatically pulled because a user lost a license or was deleted from the directory. When an account is being terminated, retire or wipe the device before the account goes, or revoke the certificate deliberately, because removing the user does not remove what their device carries.
One capability arrived in June 2026 that improves the long-term operating picture considerably. Issuing CAs can now be renewed in place: the service generates a new key pair, stages the renewed CA as a version you can test issuance against, and when you activate it the production SCEP URI carries over, so the certificate profiles you deployed years earlier keep working untouched. Before this shipped, an expiring issuing CA meant a new CA and a round of profile surgery, which on a five-year clock is exactly the kind of debt people forget they signed up for. Root CAs still cannot be renewed in place, which is one more reason to give the root the longest validity you can justify on day one.
The boundaries to design around
This is where I want to be most direct, because the license inclusion will tempt people to treat Cloud PKI as a replacement for Active Directory Certificate Services, and it is not one. It issues only to enrolled endpoints, which means it does nothing for domain controllers, member servers, internal applications, code signing, or any of the non-endpoint certificate needs a real enterprise PKI serves. Those stay with your existing CA. The concrete limits reinforce the same shape: the three-CA cap I described above, RSA keys only with no elliptic-curve support, and keys backed by a managed hardware security module for licensed authorities while trial authorities use software keys that can never be promoted afterward, so a trial hierarchy is a throwaway and not a foundation. None of this makes Cloud PKI less useful. It makes it a specific tool with a clear shape, and the discipline is to deploy it for what it is rather than stretch it toward what AD CS does.
How it is licensed
Cloud PKI is an advanced capability that sits on top of base Intune. Through the change Microsoft announced in December 2025 and provisioned across tenants over the summer of 2026, it is included in Microsoft 365 E5, and it otherwise remains available through the Intune Suite bundle or as a standalone add-on for estates that are not on E5. The carve-out I raised in the Suite overview applies here as it does to every component: this rides on Microsoft 365 E5, not on Enterprise Mobility and Security E5 and not on Microsoft 365 E3, so confirm which one you hold before you plan a certificate-authority migration around the assumption that you already own the issuer.
I placed Cloud PKI second in the adoption order for the Suite, close behind Endpoint Privilege Management, and the condition on that placement is the one to keep in mind. It earns real design effort precisely when you carry an on-premises certificate authority that exists mainly to serve endpoints, because retiring that footprint removes servers, an internet-facing role, and a standing maintenance burden in one deliberate move. If you do not carry that footprint, Cloud PKI is a smaller decision you can take later. If you do, it is one of the cleaner architectural simplifications the Suite now puts within reach, provided you adopt it as the endpoint certificate issuer it is and keep your enterprise PKI, if you still need one, for everything it deliberately does not touch.
Where this goes from here
This article used to be where the Cloud PKI story ended on this site. It is now where it starts. The pieces that follow take each decision in turn: designing the hierarchy inside that three-slot budget, where cloud root versus bring-your-own-CA is argued properly. The certificate lifecycle as it actually behaves, including the renewals that quietly fail and the revocations that do not happen on their own. The RADIUS question, because Cloud PKI hands you client certificates and Microsoft sells nothing that terminates them, and that gap is the real design problem in a cloud-native estate. The migration off NDES, and what actually retires versus what only pretends to. And then the build sheets that stand the whole thing up: the certificate authorities and the profile trio, then certificate-based Wi-Fi end to end. We start with the hierarchy, because it is the one decision the service will not let you re-make.
Intune Deployment Guide · Phase 12: The Intune Suite
‹ Previous: [12.2.6] Build Sheet: Elevation Rules
Next: [12.3.1] Designing the Hierarchy: Cloud Root, BYOCA, and the Three-Slot Budget ›
