The terminology problem with cloud-based PKI
If you’ve started researching cloud-based public key infrastructure (PKI), you’ve probably noticed something frustrating: the terms PKIaaS, SaaS PKI, and Cloud PKI are used everywhere, often without explaining what they are. Are they the same? Or do they refer to different concepts? In this blog, we will explore these questions and explain in details what their differences actually are. The TL:DR is that they are not the same: they get used interchangeably, even though they describe meaningfully different deployment models.
This matters because each model carries distinct implications for security, control, operational burden, and cost. Choosing the wrong one, or misunderstanding what a vendor means when they say “cloud PKI,” can leave you with a deployment that doesn’t meet your needs or your compliance requirements, locks you into a vendor relationship you can’t exit, or saddles your team with operational complexity you weren’t expecting.
This guide breaks down what each term actually means, where they differ, and how to match the right model to your organization’s needs.
Defining the three models
What is Cloud PKI?
Cloud PKI is the broadest umbrella term. It refers to any PKI deployment that runs in a cloud environment rather than on-premises. This includes everything from self-managed PKI deployed in your own AWS or Azure account to fully managed vendor-hosted services.
The key distinction is that Cloud PKI describes where the infrastructure lives, not who manages it.
That umbrella stretches across a spectrum of who does the work. At one end you operate everything yourself, at the other a provider operates everything for you, and hybrid models sit in between. It is worth walking that spectrum from most control to least, because the choice is really about how much operational burden you want to trade away and, critically, who ends up holding the CA private keys.
In a self-managed cloud deployment, you stand up your CA software on compute you rent in AWS, Azure, or GCP, and you back the private keys with a cloud HSM service such as AWS CloudHSM, Azure Managed HSM, or GCP Cloud HSM. The cloud provider supplies the raw ingredients: virtual machines, storage, networking, and partitioned HSM hardware. You own everything that turns those ingredients into a PKI: the hierarchy design, certificate profiles, issuance policies, CA configuration, availability, backups, and disaster recovery. The critical point is that your private keys never leave your control boundary. The provider is your landlord for infrastructure, not the operator of your trust anchor. Self-managed cloud PKI is essentially the on-premises operating model lifted into rented infrastructure. You shed the data center and the hardware refresh cycles while keeping the same responsibilities for software and keys.
Hybrid deployments mix models on purpose; the most common pattern keeps an offline root CA on-premises while running online issuing CAs in self-managed cloud, giving you a strongly protected root without the operational cost of running issuing CAs on bare metal. At the other end of the spectrum sits vendor-managed PKI, usually sold as PKI-as-a-Service (PKIaaS) or SaaS PKI. These are explained below.
What is SaaS PKI?
SaaS PKI is a turnkey, cloud-delivered PKI platform where the vendor manages the underlying infrastructure on your behalf. The vendor handles the compute, databases, networking, load balancers, and HSMs. You retain administrative access to the PKI application itself, configuring CAs, certificate profiles, validation authorities, and enrollment workflows.
Think of it as subscribing to the PKI software rather than buying and hosting it. It comes with minimal requirements: you need an active cloud account and an internet connection. You do not need any supporting infrastructure to get started, because the vendor manages the full technology stack behind the application.
In a SaaS deployment, you are responsible for the configuration of your PKI (your CAs, RAs, and VAs) but not for the operations of the supporting systems. Upgrades are handled by the vendor through planned service windows. The subscription model means you pay for what you use and can scale up or down on demand.
SaaS PKI is well suited for organizations that want to maintain control of their PKI policy and governance without managing the underlying infrastructure, need an SLA they don’t have to maintain themselves, or have an immediate need and lack the time to assemble a full PKI environment from scratch.
What is PKIaaS (PKI as a Service)?
PKIaaS is a fully managed PKI service where the vendor handles everything: PKI design, deployment, ongoing operations, and 24/7 monitoring. This goes beyond SaaS PKI in a critical way. With SaaS PKI, the vendor manages the infrastructure layer. With PKIaaS, the vendor also manages the PKI layer itself, including root CA ceremonies, certificate policy and certification practices statements (CP/CPS), issuing CA maintenance, CRL management, and incident response.
The operating model follows a clear division: the vendor builds it, deploys it, and maintains it. Your teams run it by discovering, issuing, and automating the lifecycles of certificates. You retain ownership of root CA keys and recovery materials through key escrow, ensuring you can bring your PKI back in-house if the vendor relationship changes.
PKIaaS is a service relationship, not just a software delivery model. It’s designed for organizations that want to fully offload PKI operations to experts while maintaining control over their trust anchors.
If you’re considering migrating from legacy PKI, PKIaaS offers the fastest path to a modern, well-architected deployment without requiring deep in-house PKI expertise.
Key differences at a glance
The table below summarizes the critical distinctions across the three models:
| Dimension | Cloud PKI (self-managed) | SaaS PKI | PKIaaS |
| Infrastructure management | Customer manages all cloud resources | Vendor manages infrastructure | Vendor manages infrastructure |
| PKI operations management | Customer handles all PKI operations | Customer configures PKI; vendor manages supporting systems | Vendor handles all PKI operations |
| Root CA ownership | Customer retains full control | Varies by vendor | Customer retains keys via escrow |
| Deployment speed | Weeks to months (requires in-house expertise) | Days to weeks | Weeks (vendor-led, best-practice design) |
| Customization flexibility | Maximum flexibility | High (application-level control) | Moderate (vendor-guided best practices) |
| Compliance responsibility | Fully customer-owned | Shared between customer and vendor | Primarily vendor-owned |
| Typical pricing model | Opex (cloud compute + HSM usage) | Subscription (opex) | Subscription (opex) |
| Ideal organization profile | In-house PKI expertise, cloud-first, maximum control needs | Rapid deployment, limited infrastructure resources, PKI application control | Full operational offload, enterprise security, partner relationship |
The most important line separating these models is the key custody and control axis. Self managed cloud PKI keeps everything in your hands. SaaS PKI delegates infrastructure but preserves application control. PKIaaS delegates both infrastructure and operations while preserving your ownership of trust anchors.
Single-tenant vs. multi-tenant: why it matters for PKI
Infrastructure isolation is a critical evaluation criterion, and it applies regardless of which deployment model you choose. Your private PKI is the trust anchor for your organization: its CA keys authenticate your devices, users, and workloads. How thoroughly that infrastructure is isolated from other customers directly shapes your risk, so it is worth being precise about which layers of isolation matter and why.
The layer that is non-negotiable is key custody. Your CA private keys must live in HSMs where no other tenant can extract or exercise them: dedicated HSMs, or dedicated partitions, validated to FIPS 140-2/3 Level 3. If that boundary holds, an attacker sitting in another tenant cannot sign as your CA, which is the outcome that matters most.
Beyond the keys, a single-tenant deployment isolates the surrounding environment: dedicated network and access controls under a least-privilege model, and no compute or storage shared with other customers. This is defense in depth rather than one hard boundary, and for an enterprise’s private PKI it is the sound default:
- Smaller blast radius. A vulnerability in a shared platform can potentially expose every tenant on it. A dedicated environment contains the failure to you.
- Easier to demonstrate. Auditors will accept HSM-backed key isolation in a multi-tenant design, but proving the isolation of your trust infrastructure is cleaner and faster when the environment is dedicated rather than shared.
- More room to customize. Multi-tenant platforms tend toward one size fits all. A single-tenant environment gives you more freedom over custom CA hierarchies, unusual certificate profiles, and issuance policies specific to your needs.
One scoping note: this is guidance for your private PKI, the internal trust root you own and operate. Publicly trusted PKI works differently by design, since public CAs are inherently multi-tenant and issue for many organizations at once under strict, audited controls. So the point is not that multi-tenancy is universally wrong, but that your organization’s private trust anchor deserves a dedicated environment. When evaluating any cloud-based private PKI, confirm at minimum that CA keys are isolated in dedicated HSMs, and prefer single-tenant isolation for the surrounding environment.
Control and key ownership across deployment models
Control exists on a spectrum across the three models, and understanding where each one falls is essential for making the right choice.
Cloud PKI (self-managed): You own everything. Your keys, your policies, your infrastructure, your availability. This is maximum control, but also maximum responsibility. You need in-house PKI expertise to run it well.
SaaS PKI: You control the PKI application (configuring CAs, certificate profiles, enrollment workflows) but not the infrastructure. The vendor manages servers, databases, HSMs, and availability. You still have administrative access to the PKI itself, but you’re relying on the vendor for uptime and security of the underlying systems.
PKIaaS: The vendor manages everything, but you retain ownership of what matters most: your root CA keys and recovery materials. Through customer-controlled key escrow, a copy of your root CA cryptographic materials is held by a trusted third party. This means you can bring your PKI back in-house if the situation arises.
This last point is non-negotiable regardless of model. Any vendor that does not give you the right to own your PKI should be excluded from consideration. Your PKIaaS platform must give your business complete control over root CA keys and PKI recovery materials. The design, deployment, and management tasks remain the responsibility of the vendor, while you stay in control of your trust anchors.
Security, compliance, and assurance levels
Each model distributes the compliance burden differently, and understanding this distribution is essential for your audit and regulatory planning.
SOC 2 Type II certification provides assurance about the controls at a service organization relevant to security, availability, and processing integrity. While SOC 2 Type I attests to the design effectiveness of a vendor’s controls, Type II provides a more rigorous scope and attests to the operating effectiveness of those controls. For SaaS PKI and PKIaaS, your vendor should hold SOC 2 Type II certification at minimum.
CP/CPS frameworks (Certificate Policy and Certification Practices Statements) define the requirements governing a PKI and the means by which an implementation meets those requirements. With PKIaaS, the vendor typically develops and maintains the CP/CPS on your behalf, tailored to your organization’s requirements. With SaaS PKI or Cloud PKI, you’re responsible for creating and maintaining your own.
Offline root CA protection is a foundational security control. A well-designed PKIaaS solution protects your root CA with an always-offline, fully air-gapped system. The root keys are stored in dedicated FIPS 140-2 Level 2 HSMs within facilities featuring GSA level-5 security vaults, fireproof protection, two-key controlled cabinets, tamper-evident bags, and 24/7 on-site security personnel.
Regular PKI health checks ensure your deployment stays secure over time. PKI is not a “set and forget” security tool. Continual monitoring and management are critical. PKIaaS providers typically include health checks as part of their service engagement, while self-managed models put this responsibility entirely on your team.
Here’s how compliance responsibility breaks down:
| Compliance area | Cloud PKI (self-managed) | SaaS PKI | PKIaaS |
| SOC 2 Type II | Customer’s responsibility | Vendor holds for infrastructure | Vendor holds for full service |
| CP/CPS development | Customer owns | Customer owns | Vendor develops with customer input |
| HSM management | Customer manages (cloud HSMs) | Vendor manages | Vendor manages (dedicated FIPS 140-2) |
| Root CA protection | Customer designs and operates | Varies by vendor | Vendor operates offline root with multi-layered security |
| Health checks and monitoring | Customer runs | Shared | Vendor provides continuous monitoring |
| Audit evidence production | Customer produces all evidence | Shared effort | Vendor produces most evidence |
Which model fits your organization?
Use these guidelines to match your situation to the right deployment model:
Choose Cloud PKI (self-managed) if you:
- Have in-house PKI expertise and dedicated staff
- Already run cloud infrastructure on AWS, Azure, or GCP
- Want maximum control over keys, policies, and configurations
- Can invest the time and budget to build and maintain the environment
- Have strict data sovereignty requirements that demand keys stay in your own cloud tenancy
Choose SaaS PKI if you:
- Need rapid deployment and lack time to build a PKI environment from scratch
- Want to maintain control of your PKI application without managing servers and databases
- Don’t have the budget or staff to support underlying infrastructure
- Need a subscription-based model with the ability to scale up or down on demand
- Have PKI experience (or access to professional services) to configure and manage the PKI application
Choose PKIaaS if you:
- Want to fully offload PKI operations to a team of experts
- Need enterprise-grade security and compliance (SOC 2 Type II, FIPS 140-2 HSMs, offline root CA)
- Lack in-house PKI expertise or can’t justify dedicated PKI headcount
- Want a partner relationship rather than a software tool
- Need your PKI to be post-quantum ready without managing the transition yourself
Many organizations ultimately run a hybrid model, using PKIaaS for their primary enterprise PKI while maintaining self-managed cloud deployments for specific use cases. The key is choosing a platform that supports multiple deployment options and can unify certificate management across all of them.
How Keyfactor can help
Keyfactor supports all three deployment models, giving organizations the flexibility to start where they are and evolve over time. Whether you need a self-managed PKI in your own cloud, a SaaS-delivered platform, or a fully managed PKIaaS, Keyfactor provides a single platform that scales with your needs.
Keyfactor’s PKIaaS offering stands out for several reasons:
- Fully managed, end-to-end: Keyfactor builds, deploys, and maintains your PKI. Your teams run it by issuing and automating certificates. Every deployment starts with a robust CP/CPS and an always-offline, fully air-gapped root CA protected by dedicated FIPS 140-2 Level 2 HSMs.
- Built in-house, from bottom to top: Keyfactor develops and maintains the entire PKI stack, from the cryptography libraries (Bouncy Castle) to the CA software (EJBCA). This means no reliance on third-party components, faster updates, and long-term reliability as a PKI partner.
- Post-quantum ready: With a fully managed, PQC-capable PKI and advanced certificate discovery and automation capabilities, Keyfactor helps you identify and migrate certificates to quantum-safe standards without burdening your internal teams.
- Ranked #1 in Enterprise PKI by ABI Research, and delivering 356% ROI per the Forrester Total Economic Impact study.
- PKI + certificate lifecycle automation in one platform: Rather than bolting on separate tools, Keyfactor combines PKIaaS with certificate lifecycle automation for a seamless experience across discovery, issuance, renewal, and revocation.
As David Yu, VP of Security Architecture at EQ Bank, put it: “Keyfactor worked with us every step of the way from kick-off to production, and they were extremely proactive. Their expertise and support made an immeasurable difference in the success of our teams.”
Whether you’re evaluating PKI for the first time or planning a phased migration from legacy PKI, Keyfactor brings over 20 years of PKI expertise to help you design, deploy, and manage a solution that fits.
Got cloud PKI questions? We’ve got answers.
Q: What is the difference between PKIaaS and SaaS PKI?
PKIaaS is a fully managed service where the vendor handles all PKI operations, from root CA ceremonies to 24/7 monitoring and maintenance. SaaS PKI is a cloud-delivered PKI platform where the vendor manages the infrastructure, but the customer is responsible for configuring and operating the PKI itself. PKIaaS is a service relationship; SaaS PKI is a software delivery model.
Q: Is Cloud PKI the same as PKIaaS?
Not exactly. Cloud PKI is the broadest term, referring to any PKI deployed in a cloud environment. This includes self-managed deployments in your own AWS or Azure account, vendor-managed SaaS PKI, and fully managed PKIaaS. Cloud PKI describes where the infrastructure lives; PKIaaS describes who manages it and how.
Q: Should I choose single-tenant or multi-tenant PKI?
For enterprise PKI, single-tenant is strongly recommended. PKI is mission-critical trust infrastructure, and shared, multi-tenant environments introduce security risks and compliance complications. A dedicated, single-tenant deployment provides isolation, flexibility, and the ability to meet audit requirements without dependencies on other tenants.
Q: Can I keep control of my root CA keys with a managed PKI service?
Yes, with the right provider. A well-designed PKIaaS solution includes customer-controlled key escrow, where a copy of your root CA cryptographic materials is held by a trusted third party. This ensures you can bring your PKI back in-house if the vendor relationship changes. Any provider that does not offer key ownership should be excluded from consideration.
Q: How does PKIaaS help with post-quantum cryptography readiness?
A fully managed PKIaaS provider stays current with evolving cryptographic standards, including the transition to post-quantum algorithms. Because the provider manages the PKI stack end to end, they can identify and migrate certificates to quantum-safe standards on your behalf, reducing the burden on your internal teams.
Q: What should I look for when evaluating a PKIaaS provider?
Key evaluation criteria include: single-tenant infrastructure, offline root CA protection with HSMs, customer-controlled key escrow, SOC 2 Type II certification, a robust CP/CPS framework, SLA-backed uptime (look for 99.5% to 99.9% guaranteed availability), integrated certificate lifecycle automation, and a proven track record of PKI expertise.
Q: Can I combine different PKI deployment models?
Yes. Many organizations run a hybrid model where they use PKIaaS for their primary enterprise PKI while maintaining self-managed Cloud PKI or on-premises deployments for specific use cases. The key is choosing a platform that supports multiple deployment options and can unify certificate management across all of them.
Q: How quickly can I deploy PKIaaS compared to building PKI in-house?
PKIaaS deployments can be significantly faster than building PKI in-house. The vendor brings pre-built best practices, established CP/CPS frameworks, and existing security infrastructure, which eliminates the need to design and procure everything from scratch. Some vendors can have your PKI production-ready in weeks rather than months.
