In my last post, I talked about how a chunk of what used to live only in the Intune Suite has quietly become part of standard Microsoft 365 E5 licensing. Cloud PKI is, for my money, one of the best of that bunch.

If you’ve ever built or inherited an AD CS environment, you’ll know exactly why.

The problem with “proper” PKI

PKI has underpinned enterprise security for decades. Certificate-based Wi-Fi, VPN, device trust — none of it works without a CA somewhere issuing and revoking certs.

The trouble has always been the “somewhere”. Traditional PKI means servers, patching, backups, disaster recovery plans, and usually at least one person who quietly dreads what happens if the CA falls over.

I’ve sat in more than one post-incident review where the root cause traced back to an expired intermediate certificate nobody was watching. It’s rarely glamorous, but it’s exactly the kind of thing that takes down authentication for an entire site.

Microsoft Cloud PKI is Microsoft’s attempt to take that operational weight off your plate and hand it back as a managed service inside Intune.

What it actually is

Cloud PKI is a certificate authority service that lives in Intune. You create root and issuing CAs, build certificate profiles, and push certificates to managed devices — no AD CS servers, no NDES box, no Certificate Connector sitting on a VM somewhere quietly getting forgotten about.

It covers the usual certificate workloads: Wi-Fi, VPN, device identity, user identity, and the passwordless and phishing-resistant scenarios everyone’s chasing at the moment.

Why this matters more than it might look

On paper it’s “PKI, but cloud”. In practice, it removes an entire category of infrastructure risk.

Every NDES server I’ve come across has been a bit of a soft spot — internet-facing, fiddly to patch, and rarely high on anyone’s priority list until something goes wrong. Cloud PKI takes it out of the equation entirely.

That matters for organisations trying to shrink their on-prem footprint generally, not just for PKI specifically. Fewer servers means fewer things that can be misconfigured, fewer patch cycles, fewer 2am calls.

How the hierarchy works

Cloud PKI keeps a structure that’ll feel familiar if you’ve worked with PKI before: a root CA, with one or more issuing CAs underneath it.

Microsoft hosts and manages the root — you control issuance policy and trust. Issuing CAs handle the day-to-day work of actually issuing certificates, and you can create more than one to split things by business unit, environment, region, or use case.

It’s the same design thinking as an on-prem PKI hierarchy, minus the servers.

What you actually gain

A few things stand out to me.

Automated lifecycle management is the big one. Renewal, revocation, issuance — all policy-driven. Expired certificates are one of the most avoidable causes of outage in enterprise IT, and this genuinely helps close that gap.

It’s also just… in Intune. Creating CAs, building profiles, assigning them, checking status, revoking — all in the same console you’re already living in. If you’re an Intune admin, there’s very little new to learn here, which isn’t something I say about many Microsoft security features.

And there’s the obvious security upside of certificate-based authentication over passwords: stronger device identity, harder to phish, and a genuine step towards passwordless.

Where I’d actually use it

Wi-Fi and VPN authentication are the obvious wins — push a certificate, users connect without ever seeing a credential prompt. I’ve seen how much support-desk noise disappears once Wi-Fi stops relying on users typing passwords correctly.

Device authentication for Conditional Access is the other one worth calling out — proving a device is what it claims to be before it gets anywhere near corporate resources.

Fitting into Zero Trust

Microsoft frames Zero Trust as verify explicitly, use least privilege, and assume breach. Certificates are a genuinely useful tool for the first of those — they give you cryptographic proof of identity, not just a password someone typed correctly.

Put it together with Entra ID, Conditional Access, Intune compliance policies, and Defender for Endpoint, and you get something like this: a device enrols, Cloud PKI issues it a certificate, the device becomes compliant, Conditional Access checks compliance and identity, and access is granted only to trusted users on trusted devices.

None of these pieces are new individually. What Cloud PKI does is make the certificate piece far less painful to stand up — which means more organisations will actually bother.

Before you migrate

I wouldn’t rip out an existing AD CS estate overnight, and I don’t think Microsoft expects anyone to either.

Worth checking before you commit: smart card requirements, any legacy applications tied to specific certificate templates, third-party network kit expecting a particular CA, and anything regulatory that dictates where and how your CA has to be hosted.

Most organisations I’ve spoken to are running Cloud PKI alongside their existing PKI for a while, migrating workload by workload rather than in one go. That’s the sensible approach.

Is it worth it?

If you’re already on Microsoft 365 E5, Cloud PKI is effectively sitting in your tenant right now, unused. That alone makes it worth a look.

More importantly, it removes one of the genuine, longstanding blockers to doing certificate-based authentication properly: the infrastructure overhead. I’ve watched plenty of good security initiatives stall because nobody wanted to own another CA server. This takes that excuse away.

It’s not going to replace every PKI deployment overnight, and it shouldn’t. But if you’re building out Wi-Fi, VPN, or device-identity scenarios and haven’t looked at Cloud PKI yet, it’s a genuinely worthwhile half hour of your time.