The question at the end of every PKI engagement now is the same one: does Microsoft Cloud PKI mean I can delete all of this. The short answer is that it deletes the worst component you own and none of the rest, and that anchoring it to your hierarchy makes your annual root appointment matter to every managed device in the estate.
Cloud PKI is a genuinely good service and I recommend it regularly, which is why it is worth being precise about its envelope. It issues end-entity certificates, over SCEP, to devices enrolled in mobile device management. That is the whole of it. Not domain controller certificates, not internal TLS for the hundred services terminating HTTPS on your own network, not code signing, not smart card logon, and not certificates for anything that will never be enrolled in Intune, which in most estates means the printers, the cameras, the badge readers, the building management system and every switch doing network authentication.
So the honest framing is not migration. It is division of labour: a cloud service that takes over the endpoint fleet, and a private hierarchy that keeps everything else, joined at a signature.
Two shapes, and why one of them is obvious here
There are two ways to stand this up. The first creates a root in the cloud and an issuing authority beneath it, an entirely separate trust chain with no relationship to anything you own. The second, bring your own certificate authority, creates only the issuing authority in the cloud and has your existing hierarchy sign its certificate, so it becomes a subordinate of the authority you already run.
If you have no private PKI, the cloud root is the right answer and this article is not really for you. If you have just built the hierarchy described in this series, the second option is close to obvious, and the reason is that trust distribution is the expensive part of any PKI and you have already paid for it. Every domain member, every appliance you configured, every management platform you loaded the root into: all of them already trust the anchor. A cloud issuing authority signed by your hierarchy inherits all of that on the day it is created. A separate cloud root means doing the entire trust distribution exercise again, in parallel, for a second chain.
The second reason is operational rather than technical. One chain means one revocation story, one set of expiry dates to track, and one answer when somebody asks which authority issued a certificate. Two chains that serve overlapping populations is the kind of arrangement that is perfectly clear for the eighteen months during which the person who built it is still present.
What the signature actually commits you to
Here is the part that deserves the most attention and gets the least, and it is the same lesson this series has been repeating from the first article.
When your authority signs the cloud issuing authority’s request, it writes its own distribution points into the resulting certificate, exactly as it does for every certificate it signs. Those URLs are frozen at that instant. From then on, every device validating a certificate issued by that cloud authority walks the chain upward, reaches the cloud authority’s certificate, and follows the URLs your hierarchy stamped into it to find out whether that authority is still trusted.
It is worth being exact about who performs that walk, because the obvious answer is wrong and I got it wrong in the first version of this article. It is not the phones. Microsoft’s deployment model for a bring-your-own arrangement is that the managed device receives your entire private chain, root and issuing authority both, as trusted certificate profiles, along with the cloud authority’s own certificate. Trust arrives by delivery, not by retrieval. Android does not follow authority information access paths at all, and Microsoft’s guidance for every other platform is to deploy the certificate rather than rely on the chaining engine finding it, because that behaviour is explicitly not guaranteed and varies by operating system.
The population that actually resolves those URLs is the relying parties doing revocation checking on the chain: your network policy server, your VPN concentrator, the internal services validating a presented certificate. Those sit on your network, where a directory path resolves perfectly well. So the requirement is real but local, and it is much narrower than the version I originally wrote.
Microsoft publishes revocation for the certificates the cloud authority issues. Your hierarchy still vouches for the cloud authority itself, on your schedule, from your servers.
That split of responsibility is still the thing to carry away. Your annual root appointment, the one from the operations article that felt like a legacy chore, now sits underneath the authentication path for the managed fleet as well as the domain. Let the root’s revocation list lapse and the failure surfaces where a relying party checks the chain, which is the last place anyone will look, because the Microsoft half of the system is working correctly and says so.
What this does not require, and what I claimed it did when this article first published, is a distribution point reachable from the public internet. Microsoft documents no such prerequisite for a bring-your-own arrangement, and the deployment model makes it unnecessary: relying parties are expected to hold the private chain already, and managed devices are given it. The requirement I attached here belongs to a different feature. Entra certificate-based authentication really does walk the chain from the service side and really does need your revocation lists reachable over HTTP from outside, with size ceilings and a download timeout, and that is covered where it belongs, in the revocation article.
The narrower advice survives and is still worth taking. A Windows authority publishes to directory locations by default, an HTTP distribution point is the only one every relying party can use, and whatever your authority is configured with at the moment it signs is frozen into that certificate for its whole life. Configure it properly first because it is permanent, not because the fleet will fall over on Tuesday.
The decisions you cannot revisit
The cloud service has its own version of the permanent-decisions problem, and it is tighter than the on-premises one because the budget is smaller. A tenant may hold a small fixed number of certificate authorities, counting every kind, and the properties of each are immutable once created. The extended key usages in particular cannot be added later. Needing an additional purpose means creating another authority and spending another slot from a budget of three.
Two other constraints are worth knowing before you design. Key material is RSA only, with no elliptic curve option, which is adequate for endpoint authentication and is a real ceiling if your cryptographic roadmap has opinions. And validity and hash algorithm are not yours to choose in the bring-your-own arrangement; they are inherited from whatever signs the request, which here means your on-premises issuing authority and the one-year ceiling it enforces on everything it signs. That ceiling applies to a subordinate authority exactly as it applies to a web server, so producing a cloud authority with a usable lifetime is a deliberate, bounded exception made at the moment of signing rather than something the arrangement hands you.
What actually retires
The prize is the Network Device Enrolment Service, and it is a real prize. It is the most uncomfortable component in a traditional deployment: a single service account holding enrolment rights on every template it serves, a challenge model Microsoft’s own documentation acknowledges can be abused by anyone who obtains a password legitimately, and an endpoint that cannot support pre-authentication and therefore has to be published to the internet without it. Removing it eliminates that entire surface along with its reverse proxy, its registration authority certificates and their renewal cycle, and the service account.
What does not necessarily retire alongside it is the certificate connector, and this catches people who read the architecture summary literally. Microsoft describes the cloud components as replacing the need for an on-premises authority, the enrolment service and the connector, and that sentence is scoped to SCEP issuance whether or not it says so. If you issue certificates through PKCS profiles, or import certificate files for email encryption, neither is within the cloud service’s scope, and the connector stays. Email encryption in particular cannot use either SCEP or per-device delivery, because the same key has to exist on all of a user’s devices. The Intune-side half of this story, the profiles that actually deliver a certificate to a device and the migration off the enrolment service, is written up separately and this article deliberately does not restate it: [12.3] Microsoft Cloud PKI opens that family, and [12.3.4] Migrating Off NDES covers what retires and what only appears to.
So the accurate summary is that Cloud PKI retires the enrolment service. Whether it retires the connector depends entirely on what else you were using the connector for, and the answer is frequently no.
One template, published for ten minutes
There is a small piece of discipline in this ceremony that is worth naming because it is the doctrine from the templates article applied at exactly the right moment.
Signing a subordinate authority’s request requires the subordinate certification authority template to be published on your issuing authority. That template is not published in normal operation, and should not be, because it grants the ability to obtain a certificate that can itself issue certificates. It is the single most powerful thing your hierarchy can hand out.
So publish it for the ceremony and remove it immediately afterwards. Not at the end of the project, not when the change ticket closes. The certificate is signed in seconds and the template’s job is over. Leaving it published means your issuing authority carries a standing offer to sign subordinate authorities, which is the sort of thing that shows up in an assessment years later with nobody able to explain why it is there.
Where this leaves the hierarchy you just built
Exactly where it was, with one fewer server and a new dependent. The root still signs one thing and publishes one list a year. The issuing authority still serves the domain controllers, the internal services, the appliances and the machines. The two web servers still carry the whole validation load and now carry it for the managed endpoint fleet as well, which makes their availability more consequential rather than less.
The organisations getting this wrong are not the ones adopting Cloud PKI. They are the ones adopting it and then treating the on-premises hierarchy as legacy, deferring the renewals, letting the distribution points drift, and allowing the annual appointment to lapse, on the reasonable-sounding grounds that certificates come from the cloud now. They do. They come from an authority whose right to exist is asserted by a file published from a machine in a cupboard, once a year, by hand.
That is the note this series ends on, and it is the same note it started on. A private PKI is a small number of permanent decisions and a small number of dated obligations. Adding a cloud service does not change either. It just widens the population that notices when you get one wrong.
On-Prem PKI
‹ Previous: [P 6.2] Build Sheet: Renewing the Issuing CA, and the Root
Next: [P 7.1] Build Sheet: Signing the Cloud PKI CSR ›
