Retire the on-premises CA, NDES and the certificate connector. Just know the three constraints first.
Certificates for your Intune-managed fleet, issued, renewed and revoked from the cloud, with zero servers, connectors or hardware left to babysit. Before anyone designs anything, three published limits matter: a tenant holds at most three certificate authorities, a trial CA keeps software-backed keys forever, and no data residency option exists today.
- 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
What decides whether Cloud PKI fits you, and what shape it should take.
Each of the three is in Microsoft's own documentation, each is routinely overlooked, and each costs real money to discover once something is already built.
- The tenant ceiling is three certificate authorities, full stop, and root CAs, issuing CAs and bring-your-own-CA issuing CAs all draw from the same pool. Stand up one root and one issuing authority and a single slot remains, so whether different purposes deserve their own issuing authorities becomes a genuine decision, not a habit.
- Keys created for a trial CA are software-backed, and Microsoft says without qualification that they stay software-backed even after you buy a license, with no conversion path to hardware-backed keys. A licensed CA gets keys from Azure Managed HSM, with no Azure subscription needed. So a trial CA should never graduate into production.
- Cloud PKI offers no data residency option at present. If a contract, a defense-adjacent engagement or an internal policy pins down where cryptographic material may live, resolve this question before spending an hour on anything else, because it alone can rule the service in or out.
- None of this argues against adopting the service. It argues for one deliberate design pass up front, instead of experimenting in a trial tenant and waking up owning a hierarchy that cannot change and keys that cannot improve.
Eight facts about Cloud PKI, including the ones that box in the design.
Three pieces of infrastructure go away
Microsoft is explicit: the components of Cloud PKI remove the need for an on-premises certificate authority, for NDES, and for the Intune certificate connector. If the only reason a CA server still exists in your rack is Wi-Fi and device certificates, what disappears is a server, a service, a connector and a whole class of recurring outage, not merely a feature swap.
A hard ceiling of three certificate authorities, root included
An Intune tenant supports at most three CAs, and Microsoft spells out exactly what draws from that pool: a Cloud PKI root CA, a Cloud PKI issuing CA, and a bring-your-own-CA issuing CA each take a slot. Build the classic two-tier root-plus-issuing design and two of your three slots are gone on day one. Nothing shapes the architecture more, and nothing gets noticed later.
A trial CA is permanently stuck with software-backed keys
Spin up certificate authorities during a trial and their signing and encryption keys are software-backed. Microsoft allows you to keep using those CAs once you license the product, but the keys stay software-backed forever, with no path to convert them to hardware-backed. Treat anything built in a trial as disposable if production is the destination.
No data residency choice exists right now
Under known issues and limitations, Microsoft records that Cloud PKI customers currently have no data residency option. When a government contract, a client agreement or an internal cryptography standard dictates where key material must live, this single line settles the question of fit, so surface it at the very start of the evaluation instead of finding it in a footnote.
An existing root you trust can stay in charge
Bring your own CA anchors an Intune issuing authority to a private CA you already operate, whether that is Active Directory Certificate Services or a non-Microsoft certificate service, so the root you have stays the root. Microsoft includes support for external private hierarchies of any tier depth, which is exactly what you want when that root is trusted by systems far beyond Intune.
Revocation plumbing runs itself
Every certificate authority gets its revocation list distribution point hosted by Intune, and every issuing authority gets a hosted authority information access endpoint too. The list carries a seven-day validity, gets published and refreshed on a three-and-a-half-day cycle, and picks up each revocation as it happens. Historically, this is the piece of CA operation that in-house teams fumble most.
Private keys are born on the device and stay there
Working from the SCEP profile, each device generates its own certificate signing request, and Microsoft states outright that the private key is created on the device and never leaves it. A validation service then checks the request against the SCEP challenge, confirms it originates from a device that is enrolled and managed, verifies the challenge is intact, and refuses anything that fails.
Reporting is solid, with one documented gap
The dashboard tracks active, expired and revoked certificates, refreshing its reports on a twenty-four-hour cycle, and revocation can be triggered from the same place. One caveat is documented: the view-all-certificates screen for an issuing authority caps out at the first thousand certificates issued, and the published workaround is the path through Devices, then Monitor, then Certificates.
Four checks we run before a single certificate authority exists.
The residency question comes first, every time
No data residency option is available to Cloud PKI customers today; that is Microsoft's published position. A firm carrying residency clauses in client or government contracts, or a policy dictating where key material sits, needs that answer before any other work happens. Asked early, it costs a conversation. Asked late, it costs a rebuild, which is why it opens every engagement we run.
The hierarchy gets designed against the ceiling, on paper
Root, issuing and bring-your-own-CA issuing authorities all count against the three-per-tenant cap, so a two-tier build banks exactly one spare slot. Any ambition to give each business unit or purpose its own issuing authority has to survive that math. An hour of whiteboard work beats finding the ceiling with two authorities already deployed and a third request pending.
Production never inherits a trial CA
The keys behind a trial certificate authority are software-backed, remain so after purchase, and cannot be converted, per Microsoft. A licensed authority gets Azure Managed HSM keys at no extra Azure subscription cost. Carrying a trial CA into production therefore trades away hardware key protection permanently and gains nothing, so we simply never do it.
We inventory what the old CA does before promising its retirement
Decommissioning the CA server, NDES and the connector is usually the pitch. Whether it happens hinges on everything else that CA quietly signs, and something always turns up: a code signing certificate here, an internal web service there, a legacy application nobody mentioned. Surfacing that list early tells you honestly whether you are replacing infrastructure or adding to it.
Six US situations where Cloud PKI earns its place.
The CA that exists only so Wi-Fi works
One server, an NDES role, the Intune connector, and a yearly panic when a certificate quietly expires, and the entire apparatus exists so laptops can join wireless with certificates instead of a shared password. This is the canonical migration: Cloud PKI takes over issuance and the whole on-premises chain, CA, NDES and connector, gets switched off.
A company that never built a PKI and does not want to start
Certificate-based Wi-Fi or VPN authentication is the goal, but standing up and operating a certificate authority always looked like more infrastructure than the outcome justified, so pre-shared keys and passwords survived. Cloud PKI delivers the outcome minus the infrastructure, which flips the calculation for many mid-sized American businesses.
Certificates that stop at the Windows boundary
A PKI built years ago around domain-joined Windows machines, with the Mac, iPhone and Android population left outside it ever since. Cloud PKI issues to Windows, macOS, iOS and iPadOS, and Android alike, with two conditions: Intune enrollment, and platform support for the SCEP certificate profile.
The company that has lived through an expiry outage
Everyone who has had one remembers the cost. With Intune operating the revocation distribution points and authority information access endpoints, republishing the list on a three-and-a-half-day rhythm and folding in every revocation immediately, the failure mode where an outage hinged on a human remembering a date simply goes away.
A firm whose contracts ask where the keys live
In government-adjacent work, defense supply chains and certain financial services agreements, the physical location of cryptographic material is a contract term, and Cloud PKI currently offers no residency choice. Sometimes that ends the conversation; sometimes the position is defensible once written down. Both outcomes are cheaper to reach in week one than in a post-deployment compliance review.
A root worth keeping, with issuance worth modernizing
When the incumbent root authority is trusted by systems far beyond device management, bring your own CA chains an Intune issuing authority to it, via Active Directory Certificate Services or a non-Microsoft service, with multi-tier external hierarchies supported. Device certificate issuance gets modern machinery while the trust chain everyone depends on stays exactly where it was.
Where device certificates actually come from in US organizations.
| 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 |
How common this is in practice | Uncommon | Common | Common in smaller businesses |
The hierarchies that fit inside a three-CA ceiling.
Configuration
One root, two issuing CAs
- What it uses and suits
- All three slots consumed. Fits a design that splits issuance by purpose or business unit.
Configuration
One root, one issuing CA, one bring-your-own CA
- What it uses and suits
- All three slots consumed. Fits cloud issuance running beside an anchored existing hierarchy.
Configuration
Three bring-your-own CAs
- What it uses and suits
- All three slots consumed. Fits a company committed to a root it already operates.
Configuration
One root, one issuing CA
- What it uses and suits
- Two slots used, one held in reserve. Where most first designs should land.
Configuration
Supported algorithms
- What it uses and suits
- RSA at 2048, 3072 or 4096 bits, hashed with SHA-256, SHA-384 or SHA-512.
Configuration
Licensed key protection
- What it uses and suits
- Keys provisioned in Azure Managed HSM, and no Azure subscription is needed for it.
Configuration
Trial key protection
- What it uses and suits
- Software-backed for the life of the CA, with no upgrade path to hardware backing.
Five steps, with all the design work front-loaded.
- 1
Settle fit, and audit the incumbent authority
Confirm the residency position, the licensing (a subscription on top of Intune Plan 1 or Plan 2), Intune enrollment across the fleet, and SCEP profile support per platform. Then the decisive question: everything the current certificate authority signs beyond device certificates, because that inventory decides whether it can genuinely be retired.
- 2
Put the hierarchy on paper
Cloud root with a cloud issuing authority, or an issuing authority chained to your established root via bring your own CA, and an honest case for any second issuing authority. Each choice gets tested against the three-slot ceiling, where root, issuing and bring-your-own-CA issuing authorities all take a slot.
- 3
Create licensed authorities, never trial ones
Licensed creation puts the keys in Azure Managed HSM instead of the software-backed state a trial locks in permanently. From there, trust certificate profiles cover the root and issuing authorities, and SCEP certificate profiles, built per platform, go out to the appropriate device groups.
- 4
Prove the chain on a pilot, then widen
Pilot devices pick up the trust and SCEP profiles and produce signing requests, each private key generated on its device and staying there, while the validation service gates every request back to an enrolled, managed device before signature. Each platform proves the full chain end to end before the rollout grows.
- 5
Wire up permissions, monitoring and the retirement plan
Grant read, create and revoke as separate permissions to a deliberately small group, apply scope tags where business units divide the estate, and put the certificate dashboard, refreshed every twenty-four hours, in front of a named owner. Then schedule the decommissioning of the old CA, NDES and connector for the day their last dependent workload moves.
What organizations ask about Microsoft Cloud PKI.
Fifteen questions worth answering first.
Suitability
- Do you have a data residency requirement?Cloud PKI currently offers no residency option.
- Are your devices enrolled in Intune?Issuance depends on it.
- Do all your platforms support the SCEP profile?Coverage spans Windows, macOS, iOS and Android.
- Do you have Intune Plan 1 or Plan 2?The Cloud PKI subscription comes on top of one of them.
- Have you already created a trial CA?Its keys are software-backed for good.
Your existing certificate estate
- What does your current CA actually issue?Usually more than Wi-Fi and device certificates.
- Do you run NDES and the Intune certificate connector?Cloud PKI eliminates both.
- Is your existing root trusted beyond Intune?If so, bring your own CA is the fit.
- Who currently owns certificate renewals?Often somebody who inherited the job.
- Has a certificate expiry ever caused an outage?The answer is nearly always yes. Say so.
Design
- Two-tier cloud, or anchored to your existing root?Both work, and they spend CA slots differently.
- Do you need more than one issuing CA?With three slots total, this is a genuine trade-off.
- Which key size and hash algorithm?RSA 2048, 3072 or 4096, with SHA-256, 384 or 512.
- Who gets CA permissions and scope tags?Read, create and revoke are separately grantable.
- Will you exceed a thousand issued certificates?The CA view stops listing at one thousand.
The pages around this one.
Intune Suite and advanced capabilities
The licensing home of Cloud PKI, with the rest of the advanced capabilities and the trial terms each carries.
Microsoft Intune
The management platform underneath, and the device enrollment every certificate issuance depends on.
Defender Vulnerability Management
Estate-wide certificate inventory, catching expiring certificates and weak signature algorithms wherever they hide.
Two questions settle this: where must your keys live, and how many CAs do you need?
Between them, those answers tell you whether Cloud PKI is viable and what hierarchy to build. Each takes minutes to work through in conversation, and each is vastly cheaper to answer now than after a hierarchy exists that nobody can restructure.
Related Services
Explore more solutions that work great with this service