Cloud PKI gives you three certificate authority slots, no ability to edit a CA after you create it, and one algorithm family. Hierarchy design is therefore a one-shot decision made inside a hard budget, and the discipline is to make it on paper before you touch the service.
In the Cloud PKI overview I described what the service is and the boundary it lives inside: a certificate issuer for your enrolled endpoints, not a certificate authority for your enterprise. This article is about the first decision the service actually puts in front of you, which is what your hierarchy looks like and where its trust is anchored. It is a smaller-looking decision than it is. Most Intune constructs forgive iteration: you rename a policy, retarget an assignment, version a baseline. Cloud PKI does not belong to that world. It belongs to the PKI world, where the artifacts you create are trusted by other systems for years and the service deliberately refuses to let you bend them afterward.
Three slots, fixed at birth
Two constraints shape everything, so I will state them before any architecture. First, a tenant can hold three certificate authorities in total, and every kind counts against that number: a cloud-hosted root, a cloud-hosted issuing CA, and an issuing CA anchored to your own private root all consume a slot each. A conventional hierarchy of one root and one issuing CA spends two of the three immediately, and the remaining slot is your entire margin for the future: a second issuing CA for a separate population, a bridge CA during a migration, or a replacement if you ever need to rebuild. Second, a CA’s properties are fixed at creation. The key size, the validity period, and the extended key usages it can issue cannot be edited later. If you discover six months in that you need an EKU you did not select, the answer is not a settings change. The answer is a new CA, paid for out of a budget of three.
The EKU decision deserves particular care because it is nested: an issuing CA can only offer usages that its root was created with, so a narrow root constrains every issuing CA you will ever chain under it. The service refuses the overly permissive Any Purpose usage outright, which is the right instinct, and I would carry that instinct further than the product forces you to. Select the usages you can name a concrete scenario for, client authentication first among them, and resist padding the list with usages you might want someday. A root created with a thoughtful set costs you nothing extra. A root created carelessly either carries authority it should not have or lacks authority you will later need, and both mistakes are permanent.
Cloud root or your root
With the budget understood, the real question is where trust is anchored, and the honest way to decide is to ask what already trusts what. A fully cloud-hosted hierarchy, root and issuing CA both inside the service, is the clean answer for an estate that is building fresh: a cloud-native deployment standing up certificate-based Wi-Fi for the first time, with network infrastructure that has never heard of your certificate authorities and will be taught to trust whichever chain you hand it. In that situation a cloud root is strictly less work and strictly less risk. There is no root private key in your custody because the service holds it in a managed hardware security module, there is no root ceremony, and there is nothing on-premises to protect or lose.
Bringing your own CA inverts the logic. Here the issuing CA is created in Cloud PKI as a subordinate, its signing request is taken to your existing private CA, and the certificate that comes back anchors the cloud issuer inside the hierarchy your environment already trusts. The signer does not have to be your root, and your hierarchy does not have to be two tiers: the service accepts multi-tier private hierarchies, and any tier of them can sign. What you gain is continuity. Every RADIUS server, VPN concentrator, and appliance that was taught to trust your root years ago will accept the certificates the cloud issuer produces without anyone redistributing a new anchor. That is worth a great deal during a migration, which is why the bring-your-own model is often less a destination than a bridge, a subject I will treat properly when this family reaches the migration piece. Be aware of what you inherit along with the continuity: the hash algorithm and the validity period of a bring-your-own issuing CA are set by the CA that signs it, not by anything you choose in Intune, so the quality of the cloud issuer is bounded by the discipline of the PKI that signs for it.
The two models are not exclusive. A tenant can run a cloud-rooted hierarchy and bring-your-own issuing CAs side by side, inside the same budget of three, and during a transition that is often exactly the right shape: the old-trust bridge carries existing infrastructure while the cloud root becomes the long-term anchor for everything new.
You are not picking a feature. You are picking the anchor other systems will trust for the next decade.
The fine print that follows your root
If you take the bring-your-own path, the responsibility split is the part nobody writes down. Microsoft hosts and publishes revocation for the certificates the cloud issuer produces. But the certificate that vouches for the cloud issuer itself was signed by your CA, which means its revocation checking runs against your infrastructure, published on your schedule, at the locations baked into that certificate. The relying parties that perform that check are the ones validating a presented certificate: your network policy server, your VPN concentrator, the internal services. Let the root’s revocation list lapse and those checks start failing against certificates that are perfectly valid, with the Microsoft half of the system healthy and saying so.
There is a related point about Active Directory Certificate Services defaults, and I stated it too strongly when this article first published. AD CS publishes its authority and revocation information to directory locations by default, which domain-joined machines resolve happily and nothing else can. Whatever your CA is configured with at the moment it signs is written into the cloud issuer’s certificate and frozen there for that certificate’s whole life, so an HTTP distribution point at a name you control is the right thing to have in place first. It is the only scheme every relying party can use, and Intune will show you afterwards exactly what you stamped.
What I previously said, and withdraw, is that those URLs must be reachable from the public internet before you sign, on the grounds that roaming non-domain-joined devices would be fetching them. Microsoft documents no such prerequisite, and the deployment model makes it unnecessary. The requirement I had in mind belongs to Entra certificate-based authentication, which genuinely does walk the chain from the service side and genuinely does need your revocation lists reachable over HTTP from outside, subject to size ceilings and a download timeout. That is a different feature with a different trigger. If you followed my on-premises PKI builds, the web-hosted CRL and AIA infrastructure you stood up there is still what you want, for reasons that are about permanence and universal reach rather than about the managed fleet. [P 3] Revocation Is a Distribution Problem is where that design is argued out, and its build sheet stands up the two web servers behind one name.
Which makes the real bring-your-own homework the trust delivery, and it is the step people skip. Every certificate authority in the private chain above the cloud issuer needs a trusted certificate profile delivered to every platform you serve, and so does the cloud issuer’s own certificate once it exists. A two-tier private hierarchy means two profiles per platform on top of the SCEP profile itself. Relying parties need the same material by group policy or by hand. There is a documented fallback where the chaining engine retrieves a missing issuer certificate from the authority information access URL, but Microsoft is explicit that the behaviour is not guaranteed and varies by platform, and Android does not do it at all. Deploy the certificates rather than relying on discovery. It is bookkeeping that a fully cloud-hosted hierarchy simply does not have.
Keys, algorithms, and the clock
The cryptographic menu is short, and its shortness is information. Licensed CAs hold their keys in a managed hardware security module, which is the arrangement you want and one of the cleaner arguments for the service. Trial CAs do not: their keys are software backed and can never be promoted to hardware afterward, so treat any hierarchy you build during a trial as a sketch you will throw away, never as a foundation you will license later. Key material is RSA only, at 2048, 3072, or 4096 bits with correspondingly fixed hash pairings, and there is no elliptic curve support. For endpoint authentication certificates that is adequate today. But if your cryptographic roadmap has opinions, curves now or post-quantum algorithms later, that work stays with your own PKI for the foreseeable future, and the algorithm ceiling is worth knowing about before you commit a decade-scale root to the service.
Validity is the other clock you set once. Roots run five to twenty-five years, issuing CAs two to ten, never longer than the root above them. My counsel is to give the root the longest validity you can defend, and the reason is asymmetry: issuing CAs can now be renewed in place, keys rotated and profiles untouched, but roots cannot. A root reaching end of life means a new root, a new trust distribution to every device and every relying party, and effectively a second migration you scheduled for yourself the day you created it. Twenty-five years on the root and a comfortable middle value on the issuing CA leaves the renewals where the service can actually help you with them.
Where the service runs, and where it answers from
Two operational facts belong in the design conversation because they surprise people later. The service currently offers no data residency choice, so if certificate authority metadata falls under a residency commitment you have made, you need to know that before a compliance review discovers it for you. And availability follows the commercial cloud: government cloud coverage is still ahead, planned for GCC High with nothing stated for DoD, which makes Cloud PKI a non-answer today for estates in those environments. Meanwhile every endpoint the service exposes, enrollment, revocation lists, authority information, lives on the public internet. That is mostly a virtue, since roaming devices validate chains without VPNs or split-DNS contortions. But it also means anything inside your network that validates these certificates must be allowed to reach out to check revocation, and that single sentence carries more design weight than it appears to. It is where the next article but one will spend most of its time.
Design the hierarchy, then, as the one-shot it is: name what must trust the certificates, anchor where that trust already lives or plant a clean cloud anchor where nothing is inherited, spend the three slots deliberately, choose usages you can defend, and set the clocks knowing which renewals the service will help you with and which one it will not. Everything after this decision is recoverable. This one is not, and treating it with the seriousness of a PKI decision rather than the casualness of an Intune policy is most of what there is to get right. Next comes the certificate lifecycle itself: how issuance, renewal, and revocation actually behave once the hierarchy is live, including the places where the behavior is quieter than the documentation implies.
Intune Deployment Guide · Phase 12: The Intune Suite
‹ Previous: [12.3] Microsoft Cloud PKI: A Managed Certificate Authority for Your Endpoints
Next: [12.3.2] Certificate Lifecycle: Issuance, Renewal, and the Revocations That Do Not Happen ›
