Cloud PKI vs On-Premises PKI: Operating Model, Risk and Migration Path

Most organisations run an internal certificate authority that was built years ago on Active Directory Certificate Services, and the question now is whether to keep operating it, move issuance to a managed cloud CA, or run something new on their own HSMs. The choice decides who protects the CA keys, who patches and monitors the CA, how fast certificates can be issued to machines and workloads, and how much work a migration will take. This guide compares cloud PKI (a CA run as a managed service) with on-premises PKI (a CA you operate, whether AD CS or open-source CA software) as an operating and migration decision. It is for PKI owners, identity architects and infrastructure leads. Whether a certificate should come from a public or private CA is covered in Private PKI vs Public PKI, and hierarchy design in the Enterprise PKI Design and CA Hierarchy Guide; this page does not repeat them. Services and products are listed alphabetically, and order is never a ranking.

Key takeaways

• Moving to the cloud changes who guards the key, not who owns the policy. A managed CA keeps signing keys in provider HSMs, but certificate profiles, enrolment rules, trust distribution and revocation decisions stay with you.
• AD CS risk is mostly configuration, not hosting. The ESC1 to ESC8 classes described by SpecterOps in 2021 come from templates, permissions, CA flags and web enrolment, so an untidy AD CS estate is a reason to fix or retire it, and a cloud CA only helps if you do not recreate the same mistakes.
• The identity behind issuance becomes the attack surface. On premises it is CA admins and template enrolment rights; in the cloud it is the cloud principals allowed to issue, approve or administer the CA.
• Windows authentication is the hardest workload to move. Since Microsoft's strong certificate mapping enforcement, certificates used for domain logon need a strong mapping, and Microsoft states that non-Microsoft CA deployments are not protected by its new SID extension.
• Migrate by workload, in parallel, with a chained or dual-trust phase. Run old and new CAs side by side, move one certificate population at a time, and decommission the old CA only after its last certificate has expired or been revoked and its CRL has been published for the last time.

The three operating models

In practice there are three options, not two. Open-source CA software is often lumped in with "on-premises", but it has a different operating profile from AD CS.

A hybrid is common: an offline root you hold, with issuing CAs in a cloud service or on your own hosts. Each of the cloud services below documents a way to chain to an existing root, which makes a hybrid the usual migration bridge.

Cloud CA services: how each is run

Each service has its own neutral how-to summary here, based on the provider's documentation as of November 2026. Settings change, so confirm against current documentation.

• AWS Private CA: creates private root and subordinate CA hierarchies for TLS, user, device and IoT authentication and code signing, with OCSP among its documented uses. AWS states that CA private keys are stored in AWS managed HSMs that comply with FIPS PUB 140-3 Level 3. CAs are Regional resources and cannot be copied between Regions, so plan Region choice and disaster recovery up front. Availability: a monthly charge applies per CA plus a charge per certificate issued. See the AWS Certificate Manager and Private CA Guide.
• Google Cloud Certificate Authority Service: runs CAs whose keys can be held in Cloud HSM (FIPS 140-2 Level 3), groups CAs into CA pools behind one issuance endpoint, supports bringing your own root, including one on premises, and controls access through IAM. Google documents up to 25 certificates per second per CA on the DevOps tier, and pooling CAs raises the effective issuance rate. Availability: Google publishes tier-specific capabilities and issuance quotas, so confirm the tier against the workload before creating pools.
• Microsoft Cloud PKI: issues and renews certificates for Intune-managed Android, iOS/iPadOS, macOS and Windows devices through a SCEP registration authority per issuing CA, as a cloud two-tier hierarchy or as an issuing CA chained to an existing private CA such as AD CS (bring your own CA). Licensed CA keys are provisioned in Azure Managed HSM, and Intune hosts the CRL distribution point (seven-day CRL validity, refreshed every 3.5 days) and AIA. Microsoft states it replaces the need for an on-premises CA, NDES and the Intune certificate connector for these devices. Availability: an add-on subscription to Intune Plan 1 or Plan 2, up to three CAs per tenant, trial CAs use software-backed keys that cannot be converted to HSM-backed keys, and Microsoft states a data residency option is not currently available. See the Microsoft Intune Guide.

On-premises options: how each is run

• Active Directory Certificate Services: the Windows Server CA role, with Enterprise CAs publishing templates to Active Directory for autoenrolment. Its strength is deep Windows integration; its operating load is template governance, CA permissions, CRL and AIA publication, NDES for SCEP devices and Windows Server patching. Hardening is covered in the AD CS Security Guide and How to audit AD CS certificate templates.
• EJBCA Community: open-source PKI software that its publisher describes as platform-independent and scalable, installable from Docker Hub, GitHub or SourceForge, with Helm charts and Ansible playbooks for automated deployment. Availability: the publisher states that as of EJBCA 9.6.2 all use of HSM crypto tokens requires EJBCA Enterprise Edition.
• step-ca: an open-source online CA for X.509 and SSH certificates. Its documentation lists provisioners that issue certificates in exchange for ACME challenge responses, OIDC tokens, cloud instance identity documents and single-use JWK tokens, supports short-lived certificates with passive revocation, and protects signing keys through PKCS #11 HSMs, cloud KMS services or YubiKey PIV. See SSH Protocol and Certificate Authority Guide for the SSH side.

Day-to-day operation of a self-run CA (ceremonies, backups, monitoring) is in the Private CA Design and Operations Guide.

Threat model: on-premises PKI

An on-premises CA is a tier 0 system. SpecterOps' 2021 Certified Pre-Owned research recommended treating CA servers, including subordinate CAs, as Tier 0 assets with the same protections as domain controllers.

• Template and permission abuse (ESC1 to ESC7): templates that let requesters supply the subject, allow broad usages or grant wide enrolment or edit rights; weak access control on PKI objects; the CA-wide flag that accepts user-defined subject alternative names; and CA officer or manager rights that let a principal change CA settings or bypass approval. All are configuration, and all produce certificates that authenticate as someone else (MITRE ATT&CK T1649 Steal or Forge Authentication Certificates).
• Relay to web enrolment (ESC8): HTTP enrolment endpoints without HTTPS and relay protections can be abused to obtain a certificate as a relayed account (T1557 Adversary-in-the-Middle). Remove unused web enrolment roles or require HTTPS with Extended Protection for Authentication. See the NTLM Relay Guide.
• CA key theft: a stolen CA key lets an attacker forge certificates for any identity that cannot be revoked because the CA never issued them. SpecterOps notes that root key theft likely means rebuilding the PKI, and that keys without TPM or HSM protection are easier to extract.
• Certificate spoofing through mapping weaknesses: CVE-2022-26923, listed in the CISA Known Exploited Vulnerabilities catalogue on 18 August 2022, let certificates be spoofed through machine account attributes. Microsoft's KB5014754 response added strong mapping and a SID extension.
• Neglect: CA servers rebuilt rarely, CRLs published by a scheduled task nobody owns, NDES servers left internet-facing. The Internal PKI and certificate authority health check gives a quick baseline.

Threat model: cloud PKI

A managed CA removes server patching and key extraction from a box you own, but the attack paths move to identity and supplier trust.

• Cloud principal abuse: any role that can call the issue API, approve requests, import a CA certificate or change a CA's policy can mint trusted certificates. That makes those roles tier 0, protected with phishing-resistant MFA, just-in-time elevation and separate admin identities.
• Over-broad issuance policy: a CA or pool that accepts any subject from any caller recreates ESC1 in the cloud. Constrain subjects, key usages, lifetimes and which workloads may request what.
• Tenant and MDM compromise: where enrolment is driven by device management, an attacker with MDM admin rights controls who gets device certificates. The Stryker cyberattack of 2026 showed how much a single hijacked device management admin account can do, which is why certificate profile changes in MDM deserve the same alerting as CA changes.
• Supplier and concentration risk: you depend on the provider's HSM operations, staff controls and availability, evidenced through audit reports rather than inspection. Regional scoping (as AWS documents for Private CA) affects disaster recovery.
• Lock-in at the root: if the provider holds your root key, leaving means re-issuing every certificate and redistributing a new root to every trust store. Holding the root yourself and putting only issuing CAs in the cloud avoids this.

Machine identity scale and short lifetimes

The driver for many moves is volume. Containers, service meshes and automated pipelines can need thousands of certificates an hour with lifetimes of hours or days, which AD CS autoenrolment was not designed around. Cloud services publish issuance rates (Google documents 25 certificates per second per CA on its DevOps tier) and step-ca pairs short-lived certificates with passive revocation, where expiry replaces revocation lists. Short lifetimes shrink the value of a stolen key but make the CA a runtime dependency: if it is down for longer than your shortest certificate lifetime, services fail. See Short-Lived vs Long-Lived Certificates and, for workloads that can use attested identity instead of a CA-issued certificate, the SPIFFE and SPIRE Guide.

Where identity fits

Every certificate a CA issues is a credential for a machine, workload or person, and the issuing path is itself a set of non-human identities: SCEP and ACME provisioner secrets, cloud roles used by pipelines to request certificates, NDES service accounts and connector identities. Inventory these alongside the certificates. Incident response must also cover certificates: SpecterOps notes that resetting a password does not invalidate a certificate held by a compromised identity, so revocation of certificates tied to compromised accounts belongs in the playbook. Lifecycle practice is in the Machine Identity, PKI and Certificate Lifecycle Guide.

Decision guidance

Small vs large organisations: a small organisation with a few hundred device and server certificates usually gains the most from a managed CA, provided it keeps the root (or at least an exit plan) and locks down issuing roles. A large estate rarely moves in one go: expect AD CS to remain for Windows logon while device, workload and service mesh certificates move to managed or open-source CAs. Commercial evaluation questions are in the PKI and Managed PKI Buyer's Guide.

Migration approach

1. Inventory: list every CA, template, issued certificate population, enrolment path (autoenrolment, NDES, manual) and relying party, plus CRL and AIA locations embedded in existing certificates. The Certificate Inventory Register Template helps.
2. Fix the old CA in place: remove unused templates, tighten enrolment and edit rights, clear the CA-wide subject alternative name flag, and remove or harden web enrolment, so the estate stays safe while you migrate.
3. Decide the trust anchor: keep your existing root and chain a new cloud or self-run issuing CA to it (the bring-your-own-root options above), or build a new root and distribute it to trust stores ahead of time through MDM, Group Policy and configuration management.
4. Write certificate profiles in the new CA: subjects, key usages, lifetimes and who may request each, mapped from the old templates rather than copied wholesale.
5. Pilot one population: for example Wi-Fi certificates for one site, running new and old profiles side by side so devices hold both during the pilot. Test connection success, renewal and revocation checking.
6. Move Windows logon last: confirm strong mapping works end to end (KB5014754 describes X509IssuerSerialNumber, X509SKI and X509SHA1PublicKey as the strong altSecurityIdentities mappings) before cutting over any domain authentication certificates.
7. Roll back by population: keep the old template issuing until the new profile has run through at least one renewal cycle; rollback means re-enabling the old profile for that group.
8. Decommission: stop issuance on the old CA, wait for the last certificate to expire or revoke it, publish a final long-lived CRL, keep AIA and CDP URLs reachable as long as relying parties check them, then retire and securely destroy keys. Full steps are in the Internal PKI and certificate authority migration playbook.

Worked scenario: splitting a 6,000-device AD CS estate

A manufacturer runs a two-tier AD CS hierarchy with 37 templates, NDES for mobile devices and smart card logon for 400 administrators. It is moving workloads to one public cloud and managing laptops and phones through MDM.

• Template clean-up: an audit finds 11 templates unused for two years and three that allow requester-supplied subjects; all are disabled before any migration work starts.
• Devices to the cloud CA: Wi-Fi and VPN certificates for 5,200 laptops and phones move to the MDM-integrated cloud CA, chained to the existing offline root so no trust store changes are needed. NDES is retired after the last SCEP certificate expires.
• Workloads to the provider CA: service-to-service TLS in the cloud moves to the provider's managed CA with a seven-day lifetime, requested by workload roles scoped to their own DNS names.
• Logon stays on AD CS: smart card logon stays on a reduced, hardened AD CS issuing CA treated as tier 0, with HSM-protected keys, until strong mapping on the new CA is proven in a test forest.
• Outcome measured: templates down from 37 to 6, two internet-facing servers removed, and issuing roles in both clouds limited to named admin groups with just-in-time access.

Detection and measurement

On AD CS, enable CA auditing and forward certificate request, issuance, template change and CA configuration change events to the SIEM. On cloud CAs, forward the provider's audit logs for issue, revoke, CA create, policy change and IAM changes on CA resources. In both, alert on certificates for privileged identities issued outside expected profiles, new templates or profiles, and issuance from unexpected callers. Certificate analysis techniques are in D3-CA Certificate Analysis.

• Templates or profiles with requester-supplied subjects: target zero outside documented exceptions.
• Principals able to issue or administer each CA: count, reviewed quarterly, trending down.
• Automated renewal coverage: percentage of certificates renewed without human action.
• Migration progress: certificate populations moved, and certificates still valid on the old CA.
• Revocation publication health: CRL and OCSP availability and freshness against their validity periods.
• CA key protection: percentage of CA keys in HSM or managed HSM; target 100% for production.

Framework mapping

Common failure patterns

• Lifting templates straight into the new CA: a profile that accepts any subject is as dangerous in a managed service as in AD CS.
• Treating cloud issuing roles as ordinary permissions: a pipeline role with broad issue rights is a CA administrator in all but name.
• Letting the provider hold the only root: the exit then requires re-issuing everything and pushing a new root to every device.
• Breaking Windows logon: moving smart card or device logon certificates to a new CA without validating strong mapping under enforcement.
• Decommissioning too early: switching off the old CA while its certificates are still valid, so CRL and AIA URLs disappear and relying parties fail revocation checks.
• Forgetting the CA during incident response: resetting passwords for compromised accounts while their certificates remain valid.

Practitioner checklist

• Inventory CAs, templates, certificate populations, enrolment paths and embedded CRL and AIA URLs.
• Audit and fix AD CS templates, permissions, CA flags and web enrolment before migrating anything.
• Decide who holds the root, and prefer a design where leaving a provider does not mean replacing the root.
• Treat CA servers and cloud CA issue and admin roles as tier 0, with phishing-resistant MFA and just-in-time access.
• Write new certificate profiles from requirements, constraining subjects, usages, lifetimes and requesters.
• Migrate one certificate population at a time with parallel issuance and a rollback per population.
• Validate strong certificate mapping before moving any Windows logon certificates.
• Forward CA audit and cloud CA logs to the SIEM and alert on profile changes and unexpected issuance.
• Keep the old CA's CRL and AIA endpoints available until its last certificate has expired or been revoked.
• Add certificate revocation for compromised identities to incident response playbooks.

Standards and references

• NIST: SP 800-53 Rev. 5 Security and Privacy Controls
• Microsoft: KB5014754 Certificate-based authentication changes on Windows domain controllers
• SpecterOps: Certified Pre-Owned
• MITRE ATT&CK: Steal or Forge Authentication Certificates
• AWS: What is AWS Private CA
• Google Cloud: Certificate Authority Service overview
• Microsoft Learn: Overview of Microsoft Cloud PKI for Microsoft Intune
• Smallstep: step-ca documentation

Related NHI Mgmt Group resources: Private PKI vs Public PKI · AD CS Security Guide · Internal PKI and certificate authority migration playbook · PKI and Managed PKI Buyer's Guide