Public Key Infrastructure is one of those foundational technologies that most organizations installed once, pointed at Active Directory, and largely forgot about — until something breaks, a certificate expires at 2am on a Sunday, or an auditor starts asking uncomfortable questions about your root CA.
Now, with cloud-based PKI services maturing rapidly and Microsoft pushing hard toward cloud-native identity, the question of whether to keep running an on-premises AD-integrated PKI or migrate to a cloud-based alternative is coming up in more and more architecture conversations.
The honest answer is: it depends. But the factors it depends on are worth understanding clearly before you make the call.
In this blog I am focusing on certificates for end points for Wi-Fi authentication.
Over the years Microsoft has never made a big effort to b able to issue certificates to non-AD-integrated Windows platforms. This is something you should use a MDM solution for and that MDM solution can either use a cloud-based PKI or keep using the AD PKI. Other aspects like RADIUS authentication require a separate discussion. All cloud-based solutions are based on the number of users, while the AD PKI requires more or less only the server license.
What We Mean by "AD PKI"
When most organizations say they have a PKI, they mean Microsoft Active Directory Certificate Services (AD CS) — a Windows Server role that has been the default enterprise PKI for two decades. It integrates tightly with Active Directory, auto-enrolls certificates to domain-joined machines via Group Policy, and handles everything from user authentication certificates to machine identity, S/MIME email signing, Wi-Fi EAP-TLS, and internal TLS for servers and web applications.
It works well. It is deeply embedded. And for many organizations, it is also unmaintained, under-documented, and running on hardware that predates the current IT team.
Cloud-based PKI comes in several flavors: Microsoft Cloud PKI (part of Intune / Microsoft Entra Suite), Glueck Kanja SCEPman, SCEP and PKCS integrations with third-party services like DigiCert, Sectigo, or GlobalSign, and purpose-built cloud PKI platforms like Smallstep, Keyfactor, or Venafi. Each has a different architecture and a different value proposition, but they share a common premise: move certificate lifecycle management off your infrastructure and into a managed service.
The Case for Keeping AD PKI
It works — and you've already paid for it
AD CS is included in Windows Server. If you are running a hybrid Active Directory environment, you already have the licensing, the infrastructure, and the integration in place. For organizations with a significant on-premises footprint - domain-joined endpoints, on-premises servers, legacy applications - AD CS is the path of least resistance.
Deep Group Policy integration
AD CS integrates with Group Policy in ways that cloud PKI services cannot fully replicate for legacy workloads. Certificate auto-enrollment via GPO is mature, well-understood, and effectively zero-touch for end users and devices once configured correctly. For Windows environments with a large base of domain-joined endpoints, this integration eliminates a significant category of operational overhead. GPO deployment is not working anymore of all endpoints are becoming cloud-only.
Air-gapped and high-security environments
For organizations with genuine air-gap requirements — classified government environments, operational technology networks, critical infrastructure — an on-premises PKI is not optional, it is a compliance requirement. A cloud-based PKI that requires internet connectivity for certificate issuance is architecturally incompatible with these environments regardless of how mature the service is.
Control and auditability
With AD CS you own every component: the root CA (ideally offline), the issuing CA, the certificate database, the CRL distribution points. For organizations with strict compliance requirements around cryptographic key custody — financial services, healthcare, federal contractors — that level of control has real value. You know exactly where your private keys are. You can demonstrate it to an auditor. This also means on a lot of cases that Hardware Security Modules are required and adding complexity and costs.
The Case for Moving to Cloud PKI
AD CS has an operational debt problem
The average enterprise AD CS deployment was designed and implemented years ago by someone who may no longer work there. Certificate templates have accumulated. The root CA may be running on aging hardware with no documented recovery procedure. CRL distribution points may reference internal hostnames that no longer exist. The private keys for the root CA may be stored on the CA server itself rather than in an HSM.
None of this is unusual. It is, in fact, typical. And it means the organization is carrying significant operational and security risk in infrastructure that nobody owns, nobody reviews, and nobody has tested recovering from a failure.
Cloud PKI eliminates most of that operational burden. The provider manages the underlying infrastructure, handles availability, and maintains the service. You configure certificate profiles and policies; they handle the rest.
Modern device management requires cloud PKI
If your endpoint management strategy has shifted to Microsoft Intune — managing Entra-joined devices, BYOD, or remote workers who are never on the corporate network — AD CS creates a fundamental problem. Domain-joined auto-enrollment via GPO only works for devices that are on the domain. Intune-managed devices that are Entra-joined (not hybrid-joined) cannot reach an on-premises CA for SCEP or PKCS certificate issuance without a Network Device Enrollment Service (NDES) proxy or equivalent.
That proxy adds complexity, becomes a single point of failure, and requires ongoing maintenance. Microsoft Cloud PKI, by contrast, is natively integrated with Intune — no proxy, no on-premises dependency, no VPN requirement. For organizations moving toward a cloud-first or zero-trust endpoint posture, this is a significant architectural simplification.
Certificate lifecycle visibility
One of the most common failure patterns in enterprise environments is the unexpected certificate expiration — a server goes down, a Wi-Fi authentication policy stops working, an internal application throws TLS errors. AD CS does not provide enterprise-wide certificate visibility out of the box. You need additional tooling (or manual PowerShell scripting) to build a picture of what certificates have been issued, to what, and when they expire.
Modern cloud PKI platforms are built around visibility as a core feature. Certificate inventory, expiry alerting, and revocation management are first-class capabilities rather than afterthoughts.
Talent and knowledge transfer
AD CS expertise is narrowing. The pool of engineers who deeply understand certificate templates, OID structures, CDP and AIA extensions, and HSM integration is smaller than it was ten years ago and getting smaller. Cloud PKI services abstract away most of that complexity, which means more engineers on your team can own and operate the infrastructure without specialized PKI training.
The Middle Path: Hybrid PKI
For most organizations, the answer is not a binary choice. A practical approach that is gaining traction:
Keep the root CA on-premises, offline, and air-gapped. The root CA is the trust anchor for your entire PKI. It should be rarely used (only to sign issuing CA certificates), stored offline, and protected with the highest level of physical and cryptographic control your organization can provide. This part of the infrastructure rarely changes and benefits from the control that on-premises ownership provides.
Move issuing CA functions to the cloud. Microsoft Cloud PKI supports Bring Your Own CA (BYOCA) — you can subordinate a cloud issuing CA to your existing on-premises root, preserving your trust chain while offloading the operational complexity of certificate issuance and lifecycle management to a managed service.
Use cloud PKI for Intune-managed endpoints, AD CS for domain-joined legacy workloads. Run both in parallel during transition, with a defined roadmap for retiring the on-premises issuing CA as domain-joined workloads migrate to Entra join.
A Framework for the Decision
| Factor | Favor AD CS | Favor Cloud PKI |
|---|---|---|
| Endpoint management | Primarily domain-joined via GPO | Intune-managed, Entra-joined, or BYOD |
| Network model | On-premises or hybrid | Cloud-first, zero-trust, remote-heavy |
| Compliance / key custody | Strict HSM and key control requirements | Standard enterprise compliance posture, AKV HSM backed |
| Air-gap requirements | Present (OT, classified, critical infra) | Not applicable |
| PKI operational maturity | Well-documented, actively maintained | Undocumented, aging, no clear owner |
| Team expertise | AD CS skills in-house | Generalist team, cloud-native preference |
| Legacy app dependencies | Significant (Kerberos PKINIT, S/MIME), Data at rest encryption, contract signing | Minimal or already migrated, Authentication only |
AD PKI is not legacy technology that needs to be replaced on principle but we would like to reduce the dependency on it as we like to minimize or remove AD. In the right environment — hybrid, well-maintained, with genuine on-premises requirements — it is still the right answer. The problem is not the technology; it is the organizational reality that most AD CS deployments are not well-maintained, and the expertise to maintain them correctly is becoming harder to find and retain.
A Cloud-based PKI (SCEPman, Intune Cloud PKI, ...) is not a silver bullet. It introduces its own dependencies, its own vendor relationships, and its own constraints. But for organizations moving toward cloud-first endpoint management, a zero-trust network model, or simply trying to reduce the operational debt carried by aging infrastructure, it removes a category of complexity that has historically been a source of quiet, chronic risk.
The question worth asking is not "which is better?" It is: what does our PKI actually look like today, who owns it, and what would happen if we had to rebuild it from scratch tomorrow?
If you can answer all three confidently — keep what you have and invest in improving it. If you cannot — that is the case for change.
