It replaces your certificate authority, NDES and the Intune certificate connector. There are three catches.
Cloud PKI issues, renews and revokes certificates for Intune-managed devices with no on-premises servers, connectors or hardware. The limits worth knowing before you plan: three certificate authorities per tenant, trial keys can never become hardware-backed, and there is currently no data residency option.
- Three CAsThe per-tenant limit, root included
- Four platformsWindows, macOS, iOS and Android
- No connectorReplaces on-premises CA, NDES and the connector
- No data residencyCurrently unavailable for Cloud PKI
The limits that decide whether this fits, and how it should be built.
All three are documented by Microsoft, all three are easy to miss, and all three are expensive to discover after you have built something.
- Three certificate authorities per tenant, total. Cloud PKI root CAs, Cloud PKI issuing CAs and bring-your-own-CA issuing CAs all count. A two-tier hierarchy of one root and one issuing CA leaves you exactly one spare, which forces a real decision about whether you need separate issuing authorities for different purposes.
- Trial certificate authorities use software-backed keys, and Microsoft states plainly that those keys remain software-backed after you buy a licence and cannot be converted to hardware-backed keys. Licensed CAs use Azure Managed hardware security module keys, and no Azure subscription is required for that. Treat any trial CA as disposable.
- There is currently no data residency option for Cloud PKI customers. In a market where data residency is a live question for regulated entities, government-adjacent work and some client contracts, this needs establishing before anything else, because it either rules the service in or rules it out.
- None of these are reasons not to use it. They are reasons to design once, deliberately, rather than to start clicking in a trial tenant and inherit a hierarchy you cannot change and keys you cannot upgrade.
Eight things about Cloud PKI, including the ones that constrain the design.
It replaces three pieces of infrastructure
Microsoft states directly that the Cloud PKI components replace the need for an on-premises certificate authority, NDES and the Intune certificate connector. For an organisation keeping a certificate authority alive purely to issue device and Wi-Fi certificates, that is a server, a service, a connector and a recurring source of outage removed rather than a feature added.
Three certificate authorities per tenant, and the root counts
You can create up to three certificate authorities in an Intune tenant, and Microsoft is specific that Cloud PKI root CAs, Cloud PKI issuing CAs and bring-your-own-CA issuing CAs all count towards that capacity. A standard two-tier hierarchy therefore uses two of your three. This is the constraint that shapes the design and it is the one people discover last.
Trial keys stay software-backed permanently
Certificate authorities created during a trial of the Intune Suite or standalone Cloud PKI use software-backed signing and encryption keys. Microsoft states you can continue using them after purchasing a licence, but that the keys remain software-backed and cannot be converted to hardware-backed keys. If you intend to run this in production, the trial CA is a throwaway, not a head start.
There is currently no data residency option
Microsoft lists this under known issues and limitations: a data residency option is currently not available to customers using Cloud PKI. For UAE organisations with a data residency requirement written into a regulatory expectation, a client contract or an internal policy, this is the fact that decides suitability, and it belongs at the start of the evaluation rather than in a footnote.
Bring your own certificate authority, if you have one worth keeping
You can anchor an Intune issuing CA to a private CA through Active Directory Certificate Services or a non-Microsoft certificate service, maintaining your existing root while creating an issuing CA that chains to it. Microsoft notes this includes support for external private multi-tier hierarchies, which matters if the existing root is genuinely established and trusted across systems beyond Intune.
Revocation infrastructure you do not have to host
Intune hosts the certificate revocation list distribution point for each certificate authority and the authority information access endpoint for each issuing CA. The revocation list has a seven day validity period, publishing and refresh happen every three and a half days, and the list is updated with every certificate revocation. That is the part of running a certificate authority most organisations get wrong.
The private key never leaves the device
Based on the SCEP profile, the device creates a certificate signing request, and Microsoft is explicit that the private key is created on the device and never leaves it. The validation service then verifies the request against the SCEP challenge, ensuring it comes from an enrolled and managed device and that the challenge is untampered, rejecting the request if any check fails.
Reporting, with one known limit worth knowing
A dashboard covers active, expired and revoked certificates, with reports updated every twenty four hours, and revocation can be done from there. Microsoft flags one limitation: viewing all certificates for an issuing CA shows only the first one thousand issued certificates, with the workaround being to use Devices, then Monitor, then Certificates instead.
Four things we establish before anybody creates a certificate authority.
We ask the data residency question first
Microsoft states that a data residency option is currently not available to customers using Cloud PKI. For a regulated entity, a firm with residency clauses in client contracts, or anybody with an internal policy on where cryptographic material lives, that is a gating question rather than a detail. We raise it before anything else because it can end the evaluation cheaply.
We design the hierarchy against the three CA limit
Three certificate authorities per tenant, with root, issuing and bring-your-own-CA issuing authorities all counting. That means a two-tier hierarchy leaves one spare, and any plan involving separate issuing authorities per business unit or per purpose has to fit inside that. Designing it once, on paper, is considerably cheaper than discovering the ceiling after two are built.
We never build production on a trial certificate authority
Trial CAs use software-backed keys, and Microsoft states those keys remain software-backed after purchase and cannot be converted to hardware-backed. Since licensed CAs use Azure Managed hardware security module keys with no Azure subscription required, building production on a trial CA permanently forfeits the stronger key protection for no benefit.
We find out what your existing certificate authority really issues
The business case is usually retiring an on-premises certificate authority, NDES and the Intune connector. Whether that is achievable depends entirely on what else the existing authority issues, and there is almost always something: an internal web service, a code signing certificate, a legacy application. Establishing that early determines whether this is a replacement or an addition.
Six UAE situations where Cloud PKI resolves a real problem.
A certificate authority kept alive purely for Wi-Fi
A server, NDES, the Intune connector, and an annual scare when something expires, all so devices can authenticate to the wireless network with a certificate rather than a shared password. This is the textbook case, and Cloud PKI replacing the on-premises authority, NDES and the connector removes the whole chain.
An organisation with no certificate authority and no appetite to build one
Wanting certificate-based Wi-Fi or VPN authentication and currently using pre-shared keys or passwords because building and running a certificate authority looked disproportionate. Cloud PKI makes the outcome available without the infrastructure, which changes the answer for a lot of mid-sized organisations here.
A mixed platform estate where certificates only work on Windows
The existing certificate infrastructure grew around Windows and domain-joined machines, and the Macs, iPhones and Android devices were never brought into it. Cloud PKI supports Windows, macOS, iOS and iPadOS, and Android, provided devices are Intune enrolled and the platform supports the SCEP profile.
A business whose certificate expiry caused an outage
A recognisable and expensive event. Intune hosting the revocation list distribution point and authority information access endpoints, refreshing the list every three and a half days and updating it on every revocation, removes a category of self-inflicted failure that depended on somebody remembering a date.
A regulated firm that needs the residency answer first
Where cryptographic material location is a live regulatory or contractual question, the absence of a data residency option for Cloud PKI is the deciding fact. That may rule it out, or it may be acceptable once articulated. Either way it is better established in the first conversation than during a compliance review after deployment.
An organisation with an established root it wants to keep
Where the existing root certificate authority is genuinely trusted across systems well beyond Intune, bring your own CA lets you anchor an Intune issuing authority to it through Active Directory Certificate Services or a non-Microsoft service, including external multi-tier hierarchies, so device certificate issuance modernises without disturbing the trust chain.
How device certificates are actually issued in UAE organisations.
| Feature | Cloud PKI | On-premises CA with NDES | No device certificates |
|---|---|---|---|
On-premises servers required | None | Certificate authority and NDES | Not applicable |
Intune certificate connector required | No | Yes | Not applicable |
Revocation list hosting | Hosted by Intune | Your responsibility | Not applicable |
Issues to Windows, macOS, iOS and Android | Yes | Usually Windows-centric | No |
Hardware security module protected keys | Yes, when licensed | Rarely in practice | Not applicable |
Certificate expiry causes an outage | Managed by the service | Regularly | Not applicable |
Data residency option available | Not currently | Yes, it is your infrastructure | Not applicable |
Certificate-based Wi-Fi and VPN possible | Yes | Yes | No, passwords instead |
Number of certificate authorities possible | Three per tenant | As many as you build | None |
Frequency in the UAE market | Uncommon | Common | Common in SMEs |
What you can build within three certificate authorities.
| Configuration | What it uses and suits | |
|---|---|---|
| One root, two issuing CAs | Uses all three. Suits separating issuing authorities by purpose or by business unit. | |
| One root, one issuing CA, one bring-your-own CA | Uses all three. Suits running cloud alongside an anchored existing hierarchy. | |
| Three bring-your-own CAs | Uses all three. Suits an organisation with an established root it intends to keep. | |
| One root, one issuing CA | Uses two, leaving one spare. The most common starting design. | |
| Supported algorithms | RSA with key sizes 2048, 3072 and 4096, and SHA-256, SHA-384 or SHA-512. | |
| Licensed key protection | Azure Managed hardware security module keys, with no Azure subscription required. | |
| Trial key protection | Software-backed, permanently, and not convertible to hardware-backed later. |
Five steps, and the design happens before anything is created.
- 1
Establish suitability and what the current authority does
The data residency position, the licensing requirement of a subscription in addition to Intune Plan 1 or Plan 2, whether devices are enrolled and the platforms support the SCEP profile, and crucially what your existing certificate authority issues beyond device certificates, which determines whether it can actually be retired.
- 2
Design the hierarchy on paper
Two-tier cloud root and issuing, or an issuing authority anchored to your existing root through bring your own CA, and whether more than one issuing authority is genuinely needed. All of this against the three certificate authority limit, in which root, issuing and bring-your-own-CA issuing authorities all count.
- 3
Create the authorities, licensed rather than trial
So the keys are Azure Managed hardware security module keys rather than software-backed ones that can never be converted. Then trust certificate profiles for the root and issuing authorities, and platform-specific SCEP certificate profiles, assigned to the right device groups.
- 4
Issue to a pilot, then to the estate
Devices receive the trust and SCEP profiles, generate a certificate signing request with the private key created on the device and never leaving it, and the validation service confirms the request came from an enrolled managed device before the issuing authority signs it. A pilot confirms the whole chain works for each platform before widening.
- 5
Set up permissions, monitoring and retirement
Role-based permissions for reading, creating and revoking, scope tags where the estate is divided, and the certificate dashboard for active, expired and revoked certificates, noting reports update every twenty four hours. Then the plan for retiring the on-premises authority, NDES and the connector, once everything they served has moved.
What organisations ask about Microsoft Cloud PKI.
Fifteen questions worth answering first.
Suitability
- Do you have a data residency requirement?No data residency option is currently available.
- Are your devices enrolled in Intune?A prerequisite for issuing to them.
- Do all your platforms support the SCEP profile?Windows, macOS, iOS and Android are supported.
- Do you have Intune Plan 1 or Plan 2?Cloud PKI requires a subscription in addition.
- Have you already created a trial CA?Its keys can never become hardware-backed.
Your existing certificate estate
- What does your current CA actually issue?Frequently more than device and Wi-Fi certificates.
- Do you run NDES and the Intune certificate connector?Both are replaced by Cloud PKI.
- Is your existing root trusted beyond Intune?That is the case for bring your own CA.
- Who currently owns certificate renewals?Usually somebody who inherited it.
- Has a certificate expiry ever caused an outage?Almost always yes, and worth naming.
Design
- Two-tier cloud, or anchored to your existing root?Both are supported and they use CA capacity differently.
- Do you need more than one issuing CA?The three CA limit makes this a real choice.
- Which key size and hash algorithm?RSA 2048, 3072 or 4096, and SHA-256, 384 or 512.
- Who gets CA permissions and scope tags?Read, create and revoke are separate permissions.
- Will you exceed a thousand issued certificates?The CA view shows only the first thousand.
The pages around this one.
Intune Suite and advanced capabilities
Where Cloud PKI is licensed from, alongside the other advanced capabilities and their trial terms.
Microsoft Intune
The platform this runs in, and the enrolment that is a prerequisite for issuing certificates to a device.
Defender Vulnerability Management
The certificate inventory across your whole estate, including expiry and weak signature algorithm detection.
Ask the residency question and count your certificate authorities.
Those two answers determine whether Cloud PKI fits and how it should be designed. Both take a short conversation, and both are considerably cheaper to establish now than after somebody has built a hierarchy that cannot be changed.
Related Services
Explore more solutions that work great with this service
Intune Suite
Eight advanced capabilities, and one trial each per tenant
Microsoft Intune
Device management and endpoint security
Defender Vulnerability Management
Certificates, browser extensions and firmware, not just patching
MDM Solutions Dubai
Device management across Windows, Apple and Android
Enterprise WiFi
Survey-first WiFi design with 802.1X auth
Endpoint Security
Defender for Endpoint and Intune managed
Passwordless and Passkeys
Three seconds instead of sixty nine, and it cannot be phished
Intune Compliance Policies
The default that lets unassessed devices through Conditional Access