Microsoft Intune Cloud PKI Now Free for E5: Pros, Cons, and Better Alternatives for Intune Admins
What is Microsoft Cloud PKI and What’s Changing on July 1st, 2026?
If you manage a Microsoft 365 E5 environment, mark your calendar: Microsoft Cloud PKI is becoming part of your license at no additional cost in one month, on July 1st, 2026. Before you treat that as a green light to deploy it everywhere, there is a conversation worth having. Cloud PKI is genuinely useful for a specific set of scenarios… but genuinely limited for everything else. This post breaks down exactly what you are getting, what you are not getting, and how to make the right call for your organization before that entitlement goes live.
What Is Microsoft Intune Cloud PKI?
Microsoft Cloud PKI is Microsoft’s managed, cloud-hosted certificate authority built specifically for Intune-managed devices. It allows Intune admins to issue SCEP certificates to Windows, macOS, iOS, and Android devices without standing up on-premises AD CS infrastructure. For organizations that have spent years wrestling with NDES servers, CRL distribution points, and aging certificate authorities, it sounds pretty nice: you hand Microsoft the operational burden and get certificates without managing a single server.
If you want to go deeper on how Intune issues SCEP certificates, our guide on how Intune works with SCEP covers the full mechanics.
What Pricing Changes for Microsoft Cloud PKI Are Coming on July 1st, 2026?
Microsoft has announced that Cloud PKI will be included in the Microsoft 365 E5 license beginning July 1st, 2026. In just over a month, you will have access to Cloud PKI at no additional cost. Previously, accessing Cloud PKI required an additional Intune Suite add-on on top of your existing Office licenses, usually $2 USD per user per month. For an organization with 5,000 users, that add-on cost is $10,000 per month. That is a significant cost that may not outweigh the costs of maintaining your own AD CS servers.
For E5 customers, that cost now goes to zero. That is a meaningful change, and it is exactly the right moment to decide whether Cloud PKI is the right PKI, or whether you need something more.
Is Microsoft Cloud PKI Free for E3 or Lower?
No. If you’re on E3 or lower, nothing changes for you and Microsoft Cloud PKI still requires an add-on purchase, Whether that cost makes sense depends entirely on your user count and what you actually need from a certificate authority. Once you pass roughly 100 users, the per-user add-on cost typically exceeds what a flat-rate alternative like EZCA charges for the same workload, at just $200 per certificate authority per month, with unlimited certificates and users. If you are on E3 or lower, the decision is not “Cloud PKI or nothing”. It is “Cloud PKI or an alternative like EZCA that covers the full scope of your PKI needs for a predictable monthly cost”. For many E3 customers, that alternative is the better choice.
The Real Pros and Cons of Microsoft Cloud PKI for Intune Admins
If you’re an Intune admin, you are probably asking: “Is Cloud PKI good enough for my needs, or do I need to look at alternatives?” The answer is: it depends. Cloud PKI has some real advantages, but it also has some significant limitations that affect the majority of enterprise environments. Let’s break down both sides of the equation so you can make an informed decision.
The Pros of Microsoft Cloud PKI
Let’s give credit where it is due. Cloud PKI does several things well.
- Zero infrastructure to manage. No AD CS or NDES servers, no CRL distribution points, no Windows Server licensing for your CA tier. Microsoft handles availability, patching, and key storage in Azure-backed HSMs.
- Native Intune integration. Cloud PKI is built directly into the Intune portal. Creating a CA and pushing SCEP certificate profiles to devices takes minutes, not days. For teams without a dedicated PKI engineer, this is a genuine advantage.
- Already in your E5 budget. For E5 customers, there is no added cost if you already pay for E5. If your requirements fit within what Cloud PKI supports, this is a straightforward win.
The Cons of Microsoft Cloud PKI
This is where it gets complicated. Cloud PKI has real limitations that affect the majority of enterprise environments, and being honest about them now saves you from a painful architecture decision later.
- It Doesn’t Work for Other MDM Platforms - This is the biggest constraint, and it affects nearly every organization. Microsoft Cloud PKI is Intune-exclusive. If you have any non-Intune devices — Jamf-managed Macs, ManageEngine endpoints, Linux servers, domain controllers, or network infrastructure — Cloud PKI cannot issue certificates to them. You will still need a separate PKI for anything outside of Intune, which means you have not simplified your PKI at all. You have added a second CA. Most organizations discovering this limitation mid-migration end up running Cloud PKI alongside a legacy ADCS or third-party CA, which is more complexity than they started with.
- No Server Certificate Support - Cloud PKI only issues SCEP certificates for device authentication. If you need SSL certificates for internal web servers, RADIUS server certificates for network hardware, or other server certificates, Cloud PKI does not support that. You will need a second CA such as AD CS or EZCA to cover those use cases.
- No OCSP - Online Certificate Status Protocol (OCSP) is the modern standard for checking whether a certificate has been revoked in real time. Microsoft Cloud PKI relies solely on CRLs, which are less efficient and harder to distribute in dynamic environments. For organizations adopting certificate-based authentication at scale, this is a meaningful operational limitation — revoked certificates remain trusted until the next CRL update.
- No ACME Support - ACME automates certificate issuance and renewal for internal web servers and services. Every modern private CA supports it. Microsoft Cloud PKI does not. If you want to automate SSL certificate rotation for internal workloads — the kind of automation that prevents 2 AM outage calls — Cloud PKI leaves you doing it manually or maintaining a separate toolchain alongside your new CA.
- No Azure Key Vault Integration - Azure Key Vault has supported automated certificate rotation with third-party CAs for years. You might reasonably expect Microsoft’s own Cloud PKI to integrate with Microsoft’s own Key Vault. It does not. If you manage application or service certificates in Key Vault, Cloud PKI does not help you there — you will need a different CA for that use case regardless.
- No Smartcard or YubiKey Certificate Distribution - If you are deploying phishing-resistant authentication using physical security keys or smartcards with Entra CBA, Cloud PKI does not issue those certificates. This is a significant gap for any organization pursing hardware-backed, unphishable authentication at scale.
- No Azure IoT Hub Integration - IoT is the second largest certificate workload in Azure after Intune. Microsoft Cloud PKI does not support Azure IoT Hub. If devices are connecting to Azure IoT Hub using certificate-based authentication, you need a different CA for that regardless of what you choose for Intune.
Taking a look at the cons, it is clear that Microsoft Cloud PKI is not a full replacement for a traditional CA. It is a useful tool for a specific set of Intune-only scenarios, but it does not cover the full scope of certificate needs that most organizations have. If you adopt it without considering those limitations, you may find yourself with more complexity than you started with, not less.
Should I Use Microsoft Cloud PKI?
Here is a direct decision framework.
Use Microsoft Cloud PKI if:
- You are on E5 and all your certificate-issuing devices are Intune-managed
- Your certificate needs are limited to endpoint authentication: Wi-Fi, VPN, device identity
- You do not need IoT certificates, smartcard certificates, ACME, OCSP, or Azure Key Vault integration
- You want the simplest possible setup with zero infrastructure to own
Look at EZCA if:
- You have any non-Intune devices: Jamf, ManageEngine, Linux, domain controllers, network gear
- You need OCSP, ACME, Azure Key Vault rotation, or smartcard certificate distribution
- You are on E3 or lower and the per-user add-on cost exceeds what a flat-rate alternative would cost
- You are modernizing your entire PKI and want one CA that covers everything — not two
EZCA, built by ex-Microsoft PKI engineers, is Azure-native and covers the full PKI surface that Cloud PKI does not: Jamf SCEP, ACME, Azure Key Vault rotation, Azure IoT Hub, smartcard certificates, domain controller certificates, and OCSP. It is designed to fully replace ADCS, not just augment Intune. For organizations that want a single cloud CA that handles both what Cloud PKI does and everything Cloud PKI cannot do, EZCA is the right architecture.
See How EZCA Compares to Microsoft Cloud PKIWhat About RADIUS for Wi-Fi and VPN Authentication?
If you are deploying certificate-based Wi-Fi or VPN authentication, you need a cloud RADIUS server alongside your PKI. Microsoft has not released a cloud RADIUS service, so this is a gap you will need to fill regardless of which CA you choose.
EZRADIUS Works Out of the Box with Microsoft Cloud PKI
EZRADIUS, our cloud RADIUS service, works with both Microsoft Cloud PKI and EZCA. If you have already invested in Cloud PKI certificates and need RADIUS now, you can connect EZRADIUS to your Cloud PKI setup.
Extend Your Wi-Fi and VPN Certificates with EZCA for a Seamless RADIUS Experience
That said, the integration between EZRADIUS and EZCA is significantly deeper than with Cloud PKI. When EZCA is your CA:
- EZRADIUS automatically trusts new EZCA-issued CAs without manual configuration changes every time you add a new certificate template.
- Revocation checking uses EZCA directly, so revoked certificates are rejected immediately — not at the next CRL publication window.
- Server certificates for EZRADIUS are provisioned directly from within the EZCA and EZRADIUS portals, eliminating the manual export-and-import workflow that comes with Cloud PKI.
In short: EZRADIUS works with Microsoft Cloud PKI, but it was built to work best with EZCA. If RADIUS is part of your certificate use-case, the native integration with EZCA removes the friction points that come with treating your CA and your RADIUS server as unrelated systems.
How to Prepare for July 1st, 2026: A Checklist for Intune Admins
Whether you are planning to adopt Cloud PKI or evaluate an alternative, here is what we recommend doing before that E5 entitlement goes live:
- Audit your current certificate inventory. Identify where certificates are being issued today: ADCS, NDES, third-party CAs, or ad hoc, and understand which workloads are genuinely Intune-only versus broader.
- Decide whether Cloud PKI covers your full scope. If the answer is yes, start planning your migration from AD CS or NDES. If the answer is no, even for one workload, evaluate whether a single CA like EZCA is a cleaner architecture than running Cloud PKI in parallel with a second solution.
- Sort out your RADIUS situation. If you are doing certificate-based Wi-Fi today with NDES and a legacy RADIUS server, this is the moment to modernize both at once, not just the CA.
- Account for non-Intune devices explicitly. Jamf-managed Macs, Linux endpoints, domain controllers, and network infrastructure all need certificates. Do not discover mid-migration that Cloud PKI cannot issue to them.
Now that Microsoft Cloud PKI is free for Microsoft E5, it’s the right time to make this decision and plan your architecture. If you have a simple, Intune-only environment and want the easiest possible setup, Cloud PKI is a solid choice. If you have any non-Intune devices or need features like OCSP, ACME, or Azure Key Vault integration, an alternative like EZCA is likely a better fit.
Want to Talk It Through Before You Decide?
If you want to talk through your specific environment before you commit, schedule a FREE consultation with one of our identity experts. They have helped countless organizations make this exact decision and can walk you through the right PKI architecture for your setup.