Cloud-based PKI – GCP, AWS, and Azure

Cloud-based PKI runs some or all of a certificate authority (CA) hierarchy on AWS, Azure, or GCP infrastructure instead of on-premises hardware. It matters because certificate lifespans are shrinking fast under the CA/Browser Forum’s validity schedule, and manual, hardware-bound PKI cannot keep pace. The recommended action: keep your Root CA (and ideally your Policy CA) offline regardless of which cloud you use, and pick the hybrid architecture that matches how much control you need over the Issuing CA.

Published: October 2020. Updated: August 2026. Reviewed by Encryption Consulting’s PKI Advisory Team.

If you would rather not build and operate this architecture yourself, our PKIaaS deployment models guide compares the fully managed alternative. And if HSM custody is the part you are still deciding on, Dedicated vs. Shared HSMs in PKIaaS goes deeper on that trade-off alone.

What Is Cloud-based PKI?

Public Key Infrastructure (PKI) is the set of hardware, software, policies, and procedures needed to create, distribute, and revoke digital certificates, which prove the identity of a person, device, or service on a network. A PKI’s core job is authentication and confidentiality: it lets two parties trust each other’s identity and encrypt what they exchange, and it delivers that through three properties known as the CIA triad, confidentiality (only the intended recipient can read the data), integrity (the data was not altered in transit), and availability (the systems that issue and validate certificates are up when needed).

Cloud-based PKI simply means one or more tiers of that CA hierarchy, most often the Issuing CA, run on AWS, Azure, or GCP infrastructure rather than on hardware you own and rack yourself. A few terms recur throughout this comparison: a Root CA is the trust anchor of the hierarchy and is normally kept offline; an Issuing CA (sometimes called a subordinate CA) is the CA that actually signs end-entity certificates; a Policy CA is an optional intermediate tier that constrains what an Issuing CA is allowed to issue; an HSM (Hardware Security Module) is the tamper-resistant hardware that generates and protects a CA’s private key; and CDP, AIA, and OCSP are the revocation and certificate-chaining services (CRL Distribution Point, Authority Information Access, and Online Certificate Status Protocol) that let relying parties check whether a certificate is still valid.

Why Do Organizations Move PKI to the Cloud?

Organizations move Issuing CAs to the cloud to trade capital-intensive, hands-on hardware management for a service that scales on demand and removes most of the maintenance burden. Unlike an on-premises deployment, a cloud-based Issuing CA does not require you to rack an HSM, patch an operating system, or plan hardware refresh cycles yourself, the cloud provider handles availability, scaling, and the underlying infrastructure, while you focus on certificate policy and issuance. That shift matters most for organizations whose certificate volume grows unpredictably, since a cloud-based Issuing CA can absorb a spike in enrollment (a new business unit, an IoT fleet, a Kubernetes cluster scaling out) without a hardware procurement cycle in the middle of it.

What Are the Common Challenges of Cloud-based PKI?

Most cloud PKI problems trace back to five recurring gaps: unclear design, ignoring HSMs, picking the wrong cloud for the requirement, poor integration with existing infrastructure, and no real certificate lifecycle process.

• Weak PKI fundamentals. Teams that skip a real design phase tend to also miss compliance requirements such as NIST SP 800-57’s cryptographic key management guidance, which is meant to be applied before deployment, not discovered afterward.
• Treating HSMs as optional. Skipping HSM-backed key storage for a CA’s private key means the CA is not FIPS 140 Level 3 compliant, full stop, software-only key storage cannot make that claim regardless of the cloud provider.
• Picking a cloud on convenience rather than fit. AWS, Azure, and GCP support meaningfully different CA services and HSM options; the right choice depends on where your workloads already live and what compliance regime applies, not which console your team happens to know best.
• Poor integration with the existing PKI. A cloud Issuing CA that is not correctly chained to your existing Root and Policy CAs creates a second, disconnected hierarchy instead of extending the one you already trust.
• No certificate lifecycle process. Choosing the right tools for discovery, issuance, renewal, and revocation matters as much as the CA architecture itself; an unmanaged certificate lifecycle causes outages regardless of how well the underlying PKI is designed.

How Do Native vs. External Key-Control Models Compare for Cloud PKI?

Use native cloud HSM custody for the Issuing CA that needs to scale and integrate with cloud services, and keep external, on-premises custody for the Root (and usually the Policy) CA whose private key should never be reachable over a network at all.

Model	Where the private key lives	Typical use
Native (cloud HSM custody)	Generated and held inside AWS CloudHSM (behind ACM Private CA), Azure Managed HSM, or GCP Cloud HSM	Issuing CA that needs to scale, integrate with cloud-native services, and issue at volume
Imported (BYOK-equivalent)	Key material generated on your own HSM, then imported into the cloud HSM, or a CA installed on a cloud VM backed by an on-prem HSM	Migrating an existing CA’s identity into the cloud without regenerating trust, or satisfying a policy that requires customer-generated key material
External (HYOK-equivalent)	Never imported into the cloud; stays on an air-gapped, on-premises HSM used only during scheduled signing ceremonies	Root CA, and often the Policy CA, in every architecture below

The trade-off mirrors key management generally: native cloud custody gets you elastic scale and tight integration with cloud IAM and logging, while external custody gets you the strongest guarantee, a compromised cloud account still cannot touch your Root CA’s key, at the cost of a manual, ceremony-driven process every time that key needs to be used. Our Root CA ceremony guide covers what that process actually looks like in practice.

How Does IAM Control Access to Cloud PKI Private Keys?

A cloud PKI’s IAM design has to separate the people who administer the CA itself from the people and systems that only need to request a certificate, using whichever identity system the underlying cloud already provides.

• AWS: IAM policies control who can call ACM Private CA and CloudHSM APIs, while CloudHSM additionally enforces its own crypto officer and crypto user roles inside the HSM, so an AWS IAM permission alone is not enough to use the key.
• Azure: Azure RBAC governs who can manage the CA’s supporting resources, while Managed HSM enforces a separate, local RBAC model that even Azure subscription administrators cannot override by design.
• GCP: Cloud IAM roles scoped to Cloud HSM and Certificate Authority Service control both administrative actions (creating or disabling a CA) and issuance actions (requesting a certificate), and Google recommends keeping those two role sets separate.

A practical least-privilege setup follows the same five steps on any of the three clouds:

1. Inventory every identity, human or service, that currently has any permission touching the CA or its HSM.
2. Split “can administer the CA” (create, disable, rotate) from “can request a certificate” into separate roles, and assign no identity both.
3. Scope every grant to the specific CA or HSM resource, never a wildcard across all CAs in the account, subscription, or project.
4. Require a privileged-access workflow, and ideally multi-party approval, for any action that can disable or delete a CA.
5. Review CA-related IAM assignments on a fixed quarterly cadence, since access drift here is a direct path to certificate mis-issuance.

What Are the Cloud-based PKI Architecture Models?

Four architectures cover most cloud PKI deployments, and they differ mainly in how many tiers exist and how much of the hierarchy stays on-premises.

Model	Structure	Best fit
Simple Model	Root CA on-prem and offline; a single Issuing CA in the cloud, backed by a cloud HSM	Small-scale deployments where one Issuing CA can serve every certificate request
Two-Tier Hybrid Model	Root CA on-prem and offline; two Issuing CAs, one on-prem and one in the cloud, both online	Organizations that still have significant on-premises infrastructure (workstation authentication, domain certificates) alongside cloud workloads
Three-Tier Model	Root CA on-prem and offline; a Policy CA (also offline) explicitly constrains what the cloud Issuing CA can issue	Teams that need tight, auditable control over issuance policy while still using cloud infrastructure for the Issuing CA
Three-Tier Hybrid Model	Root CA and Policy CA on-prem and offline; two Issuing CAs, one on-prem and one in the cloud, each governed by the same Policy CA	Organizations that need policy-level control across both on-premises and cloud issuance simultaneously

For example, an Issuing CA built on AWS Certificate Manager Private CA stores its private key in AWS CloudHSM behind the scenes; the model you choose determines whether that is the only CA in the hierarchy (Simple) or one of several, each with a defined scope (the hybrid and three-tier variants).

How Should You Handle Certificate and CA Key Rotation in Cloud PKI?

Leaf certificate validity and CA key rotation run on completely different clocks, and treating them as the same problem is a common planning mistake.

• Leaf certificate validity is set by the CA/Browser Forum’s published glide path: a maximum of 200 days today, dropping to 100 days on March 15, 2027, and to 47 days on March 15, 2029. At 47-day validity, manual renewal is not viable at any real scale, which is why ACME-based automation is effectively mandatory for any Issuing CA on this schedule.
• CA key rotation operates on a much longer cycle, tied to the Root or Issuing CA’s own validity period (commonly 10 to 20 years for a Root, 3 to 5 years for an Issuing CA) and to the cost of running a new key ceremony, not to the CA/Browser Forum’s leaf-certificate schedule. Rotating a CA key means generating a new key pair, issuing a new CA certificate, and re-chaining every dependent certificate, so it is planned deliberately rather than automated the way leaf renewal is.

What Should You Log and Monitor in a Cloud-based PKI?

Every layer of a cloud PKI, the CA itself, the HSM protecting its key, and the cloud platform hosting both, needs its own logging enabled before the first certificate is ever issued.

• CA-level logs: every issuance, revocation, and policy change should be recorded with the requesting identity, independent of which cloud hosts the CA.
• HSM-level logs: AWS CloudTrail captures CloudHSM and ACM Private CA API calls, Azure Monitor captures Managed HSM operations through its diagnostic settings, and GCP Cloud Audit Logs captures Cloud HSM and Certificate Authority Service activity, in all three cases this needs to be explicitly routed to a SIEM, not left in the default retention window.
• Public-facing checks: Certificate Transparency logs give you an independent, append-only record of every publicly trusted certificate issued under your domains, which is worth monitoring even for certificates you did not intend to issue.

Alert specifically on CA key export attempts, unexpected certificate issuance outside your normal enrollment workflow, and any change to a Policy CA’s issuance constraints, these are the events that turn routine PKI operation into an incident.

How Do AWS, Azure, and GCP Compare on Cost for Cloud-based PKI?

Cloud-based PKI replaces most of the large, upfront cost of an on-premises deployment with recurring HSM and CA service fees that scale with usage rather than with headcount or hardware refresh cycles.

Cost driver	Approximate model
AWS (ACM Private CA + CloudHSM)	ACM Private CA bills per CA per month plus per-certificate issuance fees; CloudHSM bills per HSM instance per hour if you need dedicated HSM control beyond ACM PCA’s managed option
Azure (Managed HSM)	Billed per HSM pool per hour rather than per key, commonly cited around $3 to $3.20 per hour for the standard tier, regardless of certificate volume
GCP (Cloud HSM + Certificate Authority Service)	A single-tenant Cloud HSM runs roughly $3,500 per month flat and includes a large number of key versions at no extra charge; Certificate Authority Service adds its own per-CA and per-certificate fees on top
On-premises PKI (for comparison)	Our own breakdown of internal PKI costs puts the all-in gap at roughly $300,000 more than a comparable managed service, once HSMs, PKI engineering staff, root ceremonies, and audits are counted

Treat the cloud figures above as directional and confirm current regional pricing before budgeting; the more durable comparison is structural, cloud-based PKI converts most PKI cost into a predictable, usage-linked fee, while on-premises PKI concentrates cost into large, infrequent capital events (HSM purchases, root ceremonies, hardware refreshes).

What Does a Multi-Cloud Cloud-based PKI Architecture Look Like?

Running PKI across GCP, AWS, and Azure at once extends the Three-Tier Hybrid model rather than replacing it: one offline Root CA and Policy CA still anchor the hierarchy, and each cloud gets its own Issuing CA underneath, scoped to the workloads that actually run there.

The failure mode we see most often is not architectural, it is governance: three Issuing CAs provisioned independently by three different cloud teams, each with its own certificate profiles, rotation habits, and logging setup, drifting apart until an auditor (or an outage) forces reconciliation. For the full reference architecture and how to avoid that drift, see our Multi-Cloud PKIaaS Architecture Guide for AWS, Azure, and GCP.

What Are the Limitations of Cloud-based PKI?

• Root CA security still depends on process, not the cloud. Moving an Issuing CA to the cloud does nothing to secure a Root CA that is still handled carelessly on-premises; the offline, ceremony-driven discipline has to hold regardless of where the rest of the hierarchy lives.
• Cross-cloud consistency is not automatic. AWS, Azure, and GCP each expose CA and HSM services differently, so certificate profiles, rotation policy, and logging format need to be deliberately standardized across clouds; nothing enforces that for you.
• Vendor lock-in at the HSM layer. A CA’s key material generated inside one cloud’s HSM is not simply portable to another cloud’s HSM, migrating later means a new key ceremony, not a lift-and-shift.
• The 47-day glide path is a hard automation requirement, not a preference. Any cloud PKI design that assumes manual certificate renewal will fail once the CA/Browser Forum’s shorter validity periods take effect.

Decision Checklist: Choosing a Cloud-based PKI Architecture

1. Confirm your Root CA (and Policy CA, if you have one) stays on-premises, offline, and ceremony-controlled, regardless of which model you choose below.
2. If your infrastructure is entirely cloud-native, start with the Simple Model; if you still have meaningful on-premises infrastructure, use the Two-Tier Hybrid Model instead.
3. Add a Policy CA (the Three-Tier or Three-Tier Hybrid Model) only if you need explicit, auditable constraints on what an Issuing CA can issue, not by default.
4. Map your certificate renewal process to the current CA/Browser Forum validity ceiling, and treat ACME-based automation as a requirement, not a future improvement.
5. If you run more than one cloud today, or expect to, design the multi-cloud governance layer, shared certificate profiles, consistent rotation policy, unified logging, before each cloud team provisions its own Issuing CA independently.

What Would Encryption Consulting Recommend?

For most organizations, we recommend starting from the Three-Tier Hybrid Model: an offline Root and Policy CA anchoring the hierarchy, with cloud-based Issuing CAs scoped per workload and per cloud. The mistake we see most often is not the choice of AWS, Azure, or GCP, it is skipping the Policy CA and the governance discipline that comes with it, which is what actually keeps a multi-cloud PKI from drifting into three disconnected, inconsistently managed hierarchies. If you are building this yourself, our PKI-as-a-Service and HSM-as-a-Service offerings can take over the pieces that carry the most operational risk, HSM custody, root ceremonies, and certificate profile governance, while you keep control of issuance policy.

Frequently Asked Questions

Can I use a single Root CA across AWS, Azure, and GCP?

Yes, and it is the recommended approach. Your Root CA stays on-premises and offline regardless of cloud; each cloud then gets its own Issuing CA that chains up to that same Root (through a Policy CA, if you use one), so trust is unified even though issuance happens in three separate places.

Do I need a dedicated HSM if I am already using a managed CA service like AWS ACM Private CA?

Not necessarily. ACM Private CA already stores its private key in AWS CloudHSM behind the scenes, so you get HSM-backed custody without provisioning a separate CloudHSM cluster. A dedicated HSM becomes worth adding when you need control over the HSM itself, for example a specific compliance mandate, custom key ceremony requirements, or workloads outside ACM Private CA that need to share the same HSM.

How often should I rotate my CA’s private key versus my leaf certificates?

These run on different schedules and should not be conflated. Leaf certificates now follow the CA/Browser Forum’s compressed validity schedule (200 days today, heading to 47 days by March 2029) and need automated renewal. A CA’s own key typically rotates far less often, on the order of years, tied to its certificate validity period and the cost of running a new key ceremony.

Is cloud-based PKI FIPS 140-3 compliant?

It can be, but compliance depends on which HSM option you choose, not the cloud provider generally. Using a software-only key store instead of an HSM-backed CA means the CA is not FIPS 140 Level 3 compliant regardless of which cloud hosts it; confirm the specific validation level of the HSM service (CloudHSM, Managed HSM, or Cloud HSM) you actually deploy.

What happens to my PKI if I later add a fourth cloud, or move a workload back on-premises?

If your Root (and Policy) CA were kept on-premises and offline from the start, adding a new Issuing CA anywhere, a fourth cloud or back on-premises, is a matter of chaining a new subordinate CA to your existing Root, not rebuilding trust from scratch. This is the main reason we recommend keeping the trust anchor off any single cloud in the first place.

Have a specific cloud PKI architecture or migration question? Reach our team at [email protected].