The Intune Cloud PKI cost question has a different answer since 1 July 2026, and most of the guidance still online predates the change. Microsoft moved Cloud PKI into Microsoft 365 E5 at no extra charge, while leaving it a paid add-on for everyone else. The obvious follow-up, that you can now retire your NDES server, does not follow automatically. What follows is what the licence actually covers, the three ceilings nobody mentions, and the one setup decision you cannot reverse.
The larger question underneath this one, how much on-premises infrastructure you keep and for how long, is covered in why co-management is a valid end state. Certificates are usually the last thing tying a domain-joined estate to on-premises servers, so this is where that argument tends to get settled.
What the Intune Cloud PKI cost actually covers
There are now four routes to the same feature, and they are priced very differently. Figures below are from Microsoft’s Intune pricing page as it stood on 24 August 2026, in US dollars, and licensing terms in this area have changed twice in eighteen months.
| Route | Cost | Base licence still required |
|---|---|---|
| Microsoft 365 E5, from July 2026 | Included | Nothing further |
| Cloud PKI standalone add-on | $2.00 per user per month, paid yearly | Intune Plan 1 or Plan 2 |
| Microsoft Intune Suite | $10.00 per user per month | Includes Plan 2 and the rest of the suite |
| Microsoft 365 E3 | Not included | Add-on or Suite required |
The July 2026 change is the part worth reading carefully, because it is asymmetric. E3 tenants gained Remote Help, Advanced Analytics and the Intune Plan 2 capabilities such as Tunnel for MAM and firmware-over-the-air updates. E5 tenants gained all of that plus Endpoint Privilege Management, Enterprise App Management and Cloud PKI. Cloud PKI sits on the E5 side of that line, not the E3 side.
If you are weighing the uplift itself rather than this one feature, the three cliff edges that actually justify E5 is the wider version of that calculation. Cloud PKI is a real addition to the E5 column, but $2.00 per user per month is not on its own an argument for a $21.00 per user per month uplift.
The three ceilings nobody mentions
The walkthroughs that dominate this search result will get you a working issuing CA in an afternoon. None of the ones I read state the limits, and all three bite after the build rather than during it.
- Three certificate authorities per tenant. That total covers everything: the Cloud PKI root CA, the Cloud PKI issuing CA, and any issuing CA you anchor to your own external root through Bring Your Own CA. A standard two-tier build consumes two of the three on day one.
- The admin centre lists only the first 1,000 issued certificates per issuing CA. Beyond that the list simply stops. Certificates continue to issue normally, so the failure looks like missing certificates when it is a display cap. Devices then Monitor then Certificates is the way round it.
- No data residency option. Microsoft documents this plainly for Cloud PKI. For a UK public sector or regulated tenant with a residency commitment written into a contract, that is a gate rather than a footnote, and it is not one you can configure your way past.
Two further numbers are worth knowing before anyone asks you for a recovery time. Revocation is published through certificate revocation lists hosted by Intune, with a seven day validity period and a refresh every three and a half days. Revocation is therefore not instant, and it is not designed to be. The reporting dashboard updates every 24 hours, so an issuance problem you fix this morning will still look broken this afternoon.
Where Intune Cloud PKI cost lands against keeping NDES
NDES appears free because Active Directory Certificate Services ships with Windows Server and carries no separate licence. That comparison is where most of the reasoning in vendor posts goes wrong, in both directions.
What NDES actually costs you is the server, the reverse proxy or Application Proxy in front of it, a publicly trusted certificate for that endpoint, the Intune Certificate Connector, the patch cycle for all of it, and the fact that a certificate enrolment path is now a production dependency with an availability target. Cloud PKI removes every one of those. Microsoft’s documentation is explicit that it requires no on-premises servers, no connector and no NDES.
What Cloud PKI does not remove is a reason to keep AD CS. If you issue certificates to anything that is not enrolled in Intune, domain controllers, network appliances, internal web servers, print servers, RADIUS infrastructure, then Cloud PKI does not serve those and AD CS stays. A large number of estates fall into that category and discover it after buying, because the walkthroughs are all written from the endpoint side.
I have not migrated an estate off NDES, and my tenant is a lab with no enrolled devices, so I have no first-hand figure to give you for how long that takes or what it saves. What the documentation supports is narrower and still useful: if every certificate you issue goes to an Intune-enrolled device, the on-premises path has no remaining function. If even one does not, you are running both, and the Intune Cloud PKI cost is additive rather than a replacement.
The failure modes
The trial is a one-way door. Certificate authorities created during a trial use software-backed keys. They cannot be converted to hardware security module backed keys once you buy. Microsoft documents this as a limitation rather than a known issue, which is the correct classification and also the reason it is easy to skim past. A CA built during evaluation and then kept because it works is a permanent downgrade in key protection, and the only fix is to build a new hierarchy and reissue every certificate. Treat trial CAs as disposable and plan to delete them.
Planning the hierarchy after creating it. Three CAs is not many. A root created to try something out, then a second root because the first had the wrong name, leaves you one slot for the issuing CA that has to serve the whole estate. Names, key sizes and validity periods on a CA are fixed at creation.
Certificates that appear not to arrive. A SCEP profile that shows as pending on a device is very often not a PKI problem at all. It is the device not checking in. The three problems that look exactly like a sync failure covers that diagnosis order, and it is worth exhausting before anyone starts reading CA logs.
Delegation that quietly does not apply. Certificate authority administration is a sensitive permission and the instinct is to scope it to one team. Scope tags do not work the way most people assume when they set them, and the way they fail is documented in what scope tags actually scope.
Assuming platform parity. Cloud PKI supports Android, iOS and iPadOS, macOS and Windows, which reads like full coverage. Profile behaviour and trust store handling differ per platform, and macOS in particular tends to expose assumptions built on Windows. The same pattern shows up in custom compliance settings for macOS.
What I would do differently
I would decide the AD CS question first and the licensing question second. The interesting number is not $2.00 per user per month. It is whether your certificate estate is genuinely endpoint-only, because that single answer decides whether Cloud PKI removes a server or adds a bill alongside one you are still running. Inventory what your existing CA issues to before you look at a price at all.
I would also treat the E5 inclusion with some caution rather than as a windfall. A capability that arrives at no marginal cost tends to get deployed because it is there, and a certificate authority is not a good candidate for that. The hierarchy you create in the first hour is the one you live with, the three CA ceiling gives you very little room to correct a mistake, and there is no rename. Free changes the procurement conversation. It should not change the design review.
For anything beyond endpoint certificates, my expectation is that most organisations end up running both for longer than they planned, and the honest version of the business case says so rather than promising a decommission date.
Last verified: 24 August 2026 against Microsoft Cloud PKI for Microsoft Intune, Microsoft Intune pricing and Microsoft Intune licensing plans and options. Prices are US list and licensing in this area changes frequently.
