PKIaaS Deployment Models Explained: Vendor-Hosted, Customer-Hosted, Hybrid, and Air-Gapped

When an organization decides to adopt PKI as a Service, the next decision is how PKIaaS gets deployed. The label “PKIaaS” covers a range of architectural models with meaningfully different properties across security boundary, key custody, compliance alignment, operational complexity, data residency, disaster recovery, and time to value. Choosing the wrong deployment model for your requirements creates problems that are expensive to fix: re-keying a CA hierarchy to move from one deployment model to another is a significant engineering program.

This guide covers the four main PKIaaS deployment models: vendor-hosted (the provider operates everything), customer-hosted (the customer operates the CA software and HSMs in their own environment), hybrid (split between provider and customer responsibility), and air-gapped (fully isolated from external networks). Each model is evaluated across the eight dimensions that matter most to security architects and compliance teams, with one architecture diagram per model.

Quick Answer: How Do the Four Deployment Models Differ?

The four models differ primarily on where the CA private keys live and who operates the infrastructure that protects them. In vendor-hosted, the provider’s HSMs hold the keys and the provider’s team operates everything. In customer-hosted, the customer’s HSMs hold the keys and the customer’s team operates the CA software. In hybrid, the root CA key is customer-held in an offline environment while the issuing CAs are vendor-operated. In air-gapped, all keys and infrastructure are physically isolated from any network. The right model for a given organization depends on its regulatory requirements, key custody policy, operational capacity, and time-to-deploy constraints.

Key Takeaways

• Deployment model selection is a compliance decision before it is a technical decision. FedRAMP High, CMMC Level 3, ITAR, some DORA/NIS2 national implementations, and classified program requirements create specific constraints on where CA keys can reside and who can administer the hardware holding them. These constraints must be confirmed with legal and compliance counsel before a deployment model is selected.
• Vendor-hosted is the correct default for most organizations without regulatory key custody requirements. It deploys faster, requires less internal operational expertise, includes built-in HA/DR, and produces a lower total cost of ownership than customer-hosted. The security properties of a well-implemented vendor-hosted PKIaaS (FIPS 140-3 Level 3 HSMs, M-of-N controls, SOC 2 Type II audited) are materially stronger than most organizations’ self-operated PKI programs.
• Customer-hosted is not the same as self-managed PKI. In a customer-hosted PKIaaS deployment, the provider supplies the CA software, the management platform, and operational support; the customer supplies the infrastructure (servers, HSMs, network). The customer does not need to build a PKI from scratch; they deploy the provider’s software in their environment.
• The hybrid model is the most common architecture for organizations with a specific root CA key custody requirement but no objection to vendor-operated issuing CAs. The root CA is customer-hosted and offline; the issuing CAs are vendor-hosted and always-on. This splits the operational burden appropriately: the customer manages the highest-value key (the root CA), the provider manages the operationally demanding components (the issuing CAs, OCSP, CRL, management plane).
• Air-gapped deployments require a fundamentally different operational model for certificate issuance and revocation. Certificates cannot be issued or revoked on demand over a network connection; every CA operation requires physical access to the air-gapped environment. This operational cost must be fully understood before air-gapped is selected as the deployment model.

Model 1: Vendor-Hosted PKIaaS

In the vendor-hosted model, the PKIaaS provider operates the complete CA infrastructure: root CA, intermediate CAs, issuing CAs, OCSP responders, CRL distribution points, the management console, and the HSMs that protect all CA private keys. The customer accesses the service over the internet through the provider’s management portal, API, and enrollment endpoints. No CA infrastructure is deployed in the customer’s environment beyond enrollment protocol agents (such as a WSTEP autoenrollment proxy for Windows Active Directory) where required.

Properties of the Vendor-Hosted Model

Security boundary: The provider’s cloud environment is the security boundary for CA key material. All CA private keys are stored in the provider’s FIPS 140-3 Level 3 validated HSMs. The customer has no physical access to the HSMs and relies on the provider’s security controls, SOC 2 Type II audit, and contractual commitments for key protection. In well-implemented vendor-hosted PKIaaS, this produces stronger security than most organizations’ self-operated PKI programs, because the provider’s security team and HSM infrastructure are purpose-built for CA key protection.

Key custody: The provider holds CA private keys on behalf of the customer. Customer-controlled key escrow (where the customer holds an independently recoverable copy of the root CA key material) is the standard mitigation for vendor lock-in risk. Confirm before engagement whether the provider supports customer-controlled key escrow and what the recovery procedure looks like.

Operations: The provider manages all CA operations: HA/DR for the issuing CA infrastructure, CRL and OCSP responder availability, security patching, HSM firmware updates, and the management platform. The customer’s operational responsibility is limited to certificate policy governance (defining what gets issued to whom) and CLM monitoring.

Data residency: CA key material and certificate metadata are stored in the provider’s infrastructure. For organizations with geographic data residency requirements, confirm whether the provider can restrict CA key storage to a specific region or country, and whether that commitment is contractual.

Compliance: Appropriate for most enterprise compliance frameworks (SOC 2, PCI DSS, HIPAA, CMMC Level 2, ISO/IEC 27001). May not satisfy frameworks that require the regulated entity to control CA keys directly (some FedRAMP High implementations, CMMC Level 3 in certain assessment scopes, ITAR for defense programs, classified program requirements).

Time to deploy: Fastest of the four models. A vendor-hosted PKIaaS deployment can be operational in days to 2 weeks, including CA hierarchy setup, root CA key ceremony, and initial certificate profile configuration. Enrollment protocol agents (WSTEP proxy for Windows, MDM profile configuration for Intune/Jamf) add 1 to 2 weeks for integration.

Best fit: Cloud-connected enterprises without specific key custody regulatory requirements; organizations replacing aging self-managed PKI with a lower-operational-overhead model; organizations that need PKI operational quickly in response to a compliance deadline.

Model 2: Customer-Hosted PKIaaS

In the customer-hosted model, the customer deploys and operates the CA software and HSMs in their own environment, either on-premises or in their own cloud infrastructure. The PKIaaS provider supplies the CA software platform and the management interface, but the hardware running that software, the HSMs protecting CA keys, and the network segment the CA operates in are all the customer’s responsibility. The provider’s management platform connects to the customer-hosted CA through a secure connector or agent installed in the customer’s environment.

Properties of the Customer-Hosted Model

Security boundary: The customer’s environment is the security boundary for CA key material. The customer controls the physical hardware, the network segment, and access to the systems. The provider’s management platform connects through a secure connector (typically a lightweight agent or sensor installed in the customer’s network) and does not have direct access to the CA private keys.

Key custody: The customer holds CA private keys in their own FIPS 140-3 Level 3 HSMs. The customer controls who has physical access to the HSMs and what M-of-N configuration governs high-privilege operations. This is the model required by compliance frameworks that mandate customer control of cryptographic key material.

Operations: Significantly higher operational burden than vendor-hosted. The customer’s team must manage HSM hardware (procurement, maintenance, firmware updates, HA failover), CA software installation and patching, OCSP and CRL infrastructure, network security for the CA segment, and the connector agent that links the customer environment to the provider’s management platform. The provider supplies software updates and support, but the customer’s team executes them.

Data residency: CA key material and certificate operations are fully within the customer’s environment. This satisfies the strictest data residency requirements because the customer controls every system where key material exists.

Compliance: Appropriate for FedRAMP High (where multi-tenant provider infrastructure complicates ATO boundaries), CMMC Level 3 for high-assurance CUI environments, ITAR for defense programs where key material must not reside on provider systems, and national implementations of DORA or NIS2 with physical key control requirements.

Time to deploy: Slowest of the four models. Procurement and deployment of HSM hardware, server infrastructure, and network security controls typically adds 2 to 4 months to the deployment timeline compared to vendor-hosted.

Best fit: Regulated organizations with documented key custody requirements; defense contractors with ITAR or DFARS constraints; organizations with data sovereignty requirements that prohibit key material from residing on provider infrastructure.

Model 3: Hybrid PKIaaS

The hybrid model places different components of the CA hierarchy in different environments based on their security requirements. The most common hybrid pattern is a customer-hosted offline root CA with vendor-hosted issuing CAs. The root CA is kept offline in the customer’s environment, protecting the highest-value cryptographic asset (the root CA private key) under customer control. The issuing CAs are vendor-hosted, providing the operational simplicity, HA, and management platform integration of the vendor-hosted model for the components that must be always-on.

Properties of the Hybrid Model

Security boundary: Split. The root CA is in the customer’s security boundary; the issuing CAs are in the provider’s. The root CA private key never enters the provider’s environment; the provider’s issuing CA private keys never enter the customer’s environment. The boundary between the two is the signed subordinate CA certificate: the customer’s offline root CA signs the issuing CA CSR during an offline ceremony, producing a signed certificate that is transferred to the provider (out-of-band, not over a network connection) to activate the issuing CA.

Key custody: Split. The customer holds the root CA private key; the provider holds the issuing CA private keys. For organizations whose key custody requirement is specifically about the root CA (the highest-value cryptographic asset), this satisfies the requirement. For organizations whose requirement covers all CA keys at all levels, this model does not satisfy it and customer-hosted is required.

Operations: Moderately split. The customer’s team manages the offline root CA and its HSM (a low-frequency operational burden, since the root CA is only used for periodic ceremonies to issue or renew issuing CA certificates). The provider manages the issuing CAs, OCSP, CRL, management platform, and HA/DR. The balance is weighted heavily toward the provider for day-to-day operations.

Data residency: Root CA key material is in the customer’s environment; issuing CA key material and certificate metadata are in the provider’s. For organizations with geographic restrictions on root CA key material specifically, this satisfies the requirement. Confirm what certificate issuance data (CSRs, certificate records, audit logs) the provider’s management platform stores and in which geographic region.

Compliance: Appropriate for organizations that require customer control of the root CA key specifically, without requiring customer control of all CA operations. This covers many enterprise risk policies and some regulatory frameworks that focus on root CA governance. Confirm with compliance counsel whether issuing CA keys in the provider’s environment satisfies the applicable framework.

Time to deploy: Moderate. The provider-side issuing CA infrastructure deploys as quickly as vendor-hosted. The customer-side root CA hardware procurement and setup adds 4 to 8 weeks. The subordination ceremony (offline root signing the issuing CA certificates) adds one scheduled event. Total deployment timeline is typically 6 to 10 weeks.

Best fit: Organizations with a specific root CA key custody requirement that does not extend to issuing CA keys; organizations whose risk policy requires customer-held root CA but not full on-premises deployment; organizations that want the operational simplicity of vendor-hosted issuing CAs while retaining root CA control.

Model 4: Air-Gapped PKIaaS

The air-gapped model operates the CA infrastructure on systems that are physically disconnected from external networks. No network connection exists between the air-gapped CA environment and the internet, the provider’s management platform, or any external system. Certificate issuance, revocation, and CA administration all require physical access to the air-gapped environment. Certificates and revocation data are moved between the air-gapped environment and connected systems using removable media (USB drives, optical discs) transported through a documented physical transfer procedure.

Properties of the Air-Gapped Model

Security boundary: The most restrictive of the four models. The air-gapped environment has no network attack surface because it has no network connectivity. Physical security controls (access-controlled rooms, two-person integrity rules for CA operations, electronic media controls) replace network security controls as the primary defense mechanism. The threat model is physical: unauthorized physical access to the air-gapped environment is the primary attack vector.

Key custody: Fully customer-held. All CA private keys are in the customer’s air-gapped environment and are never connected to any external system. This is the maximum key custody model, required by classified programs, some defense programs, and highly regulated environments where no external connectivity to CA infrastructure is acceptable under any circumstances.

Operations: Most operationally intensive of the four models. Every CA operation (certificate issuance, revocation, CRL publication, CA renewal) requires physical access to the air-gapped environment and a documented physical procedure. Certificate requests must be delivered to the air-gapped zone on removable media, processed by the CA operator, and the resulting certificates transported back out on removable media. This physical workflow adds hours to days to certificate operations that are instantaneous in the vendor-hosted model. There is no automated renewal; every certificate issuance is a manual operation performed by a human in a controlled environment.

Data residency: Complete. All CA operations occur within the customer’s physically controlled environment. No CA key material, certificate metadata, or audit data ever leaves the air-gapped zone except as explicitly transported on controlled media.

Compliance: Required for classified government programs (U.S. Secret and Top Secret networks), some defense programs with specific ITAR constraints that prohibit network-connected CA operations, and industrial control system environments with IEC 62443 security level requirements that prohibit external connectivity to CA infrastructure.

Time to deploy: Longest of the four models. In addition to the hardware procurement and setup time of the customer-hosted model, the air-gapped model requires designing and implementing the physical media transfer procedures, access control policies, and two-person integrity rules for CA operations. Deployment timelines of 3 to 6 months are typical for a well-designed air-gapped PKI program.

Best fit: Classified government programs; defense programs with physical network separation requirements; critical infrastructure environments where CA operations must occur on isolated operational technology networks. Any environment where the operational cost and complexity is justified by a genuine physical network isolation requirement.

Deployment Model Comparison

Dimension	Vendor-Hosted	Customer-Hosted	Hybrid	Air-Gapped
CA key custody	Provider HSMs	Customer HSMs (all keys)	Customer HSM (root only); provider HSM (issuing)	Customer HSMs (all keys, offline)
Security boundary	Provider cloud	Customer environment	Split: root in customer; issuing in provider	Physically isolated customer zone
Operational burden	Low (provider manages)	High (customer manages CA software + HSMs)	Moderate (customer manages root; provider manages issuing)	Very high (all operations manual, physical)
Data residency	Provider geography (may be configurable)	Fully customer-controlled	Root key in customer; other data in provider	Fully customer-controlled, physically isolated
Compliance fit	SOC 2, PCI DSS, HIPAA, CMMC L2, ISO 27001	FedRAMP High, CMMC L3, ITAR, strict data residency	Root CA key custody requirements without full on-prem	Classified, defense with physical separation, critical ICS
Disaster recovery	Provider manages HA/DR	Customer must design and operate DR	Provider manages issuing CA DR; customer manages root	Customer manages all DR, including media procedures
Integration complexity	Low: native API, no connector for cloud CLM	Moderate: CA connector required for management platform	Moderate: provider-side native; customer-side connector for root	High: all integration via out-of-band media transfer
Time to deploy	Days to 2 weeks	2 to 4 months	6 to 10 weeks	3 to 6 months
ACME / automated enrollment	Native	Supported via connector	Supported (issuing CA side)	Not supported (manual issuance only)
Air-gapped CA support	No	Yes	Yes (root CA only)	Yes (entire CA hierarchy)

Deployment Model Decision Guide

Work through the following questions in order. The first question that produces a constraint typically determines the deployment model.

1. Does your compliance framework require your organization to physically control all CA private keys? If yes, choose customer-hosted. If only the root CA key must be customer-controlled, choose hybrid. If no specific key custody requirement applies, continue.

2. Does your compliance framework or security policy require physical network isolation of CA operations (no network connectivity to any external system)? If yes, choose air-gapped. If no, continue.

3. Does your data residency requirement restrict where CA key material can be stored geographically, and can the vendor-hosted provider satisfy that restriction contractually? If the provider can satisfy the restriction, continue with vendor-hosted. If not, choose customer-hosted or hybrid.

4. Does your organization have the internal operational capacity to manage HSM hardware, CA software, and the supporting network infrastructure on an ongoing basis? If yes, customer-hosted or hybrid is operationally viable. If no, vendor-hosted is the only model that does not require that capacity.

5. Do you have a specific time-to-deploy constraint (for example, a compliance deadline, a contractual requirement, or an incident response timeline)? If the deployment must be operational in less than 4 weeks, only vendor-hosted can reliably meet that timeline. Customer-hosted, hybrid, and air-gapped all require hardware procurement that cannot be accelerated below 4 to 6 weeks minimum.

How Encryption Consulting Can Help

Encryption Consulting helps organizations select and implement the right PKIaaS deployment model for their specific regulatory environment, operational capacity, and timeline. We offer all four deployment models and provide independent advisory support for organizations selecting between providers.

• PKI as a Service: Encryption Consulting’s PKIaaS offering supports vendor-hosted, customer-hosted, and hybrid deployment models. Our vendor-hosted deployment uses FIPS 140-3 Level 3 HSMs, always-offline root CA with M-of-N key ceremony documentation, customer-controlled key escrow, and SOC 2 Type II certified infrastructure. Contact us at Encryption Consulting to discuss which deployment model fits your requirements.
• PKI Assessment Service: For organizations evaluating deployment model options, Encryption Consulting’s PKI Assessment Service maps your compliance framework requirements (FedRAMP, CMMC, ITAR, DORA, HIPAA) against each deployment model’s properties, producing a deployment model recommendation with documented justification that can be presented to auditors and executive leadership.
• HSM as a Service: For organizations selecting the customer-hosted or hybrid model and needing FIPS 140-3 Level 3 certified HSM capacity without managing hardware procurement, Encryption Consulting’s HSM as a Service provides dedicated HSM capacity with full customer control over partition configuration, credentials, and audit log access. This enables a customer-hosted key custody model without the full operational burden of hardware ownership.
• PKI Services: For organizations implementing air-gapped PKI or complex customer-hosted deployments that require expert design and implementation support, Encryption Consulting’s PKI Services provide advisory and hands-on support through CA hierarchy design, physical media transfer procedure development, key ceremony execution, and ongoing operational governance.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides CA-agnostic CLM across all four deployment models, with connectors for vendor-hosted PKIaaS APIs, customer-hosted CA connector APIs, and offline certificate database imports for air-gapped environments. This provides unified certificate inventory and expiry monitoring regardless of which deployment model is in use.

Conclusion

PKIaaS deployment model selection is one of the most consequential early decisions in a PKI program because the model determines who controls the keys, where data lives, who operates the infrastructure, and what compliance frameworks can be satisfied. Getting it wrong creates a rebuild program that is significantly more expensive than getting it right at the start.

The vendor-hosted model is right for most organizations without specific regulatory key custody requirements: it deploys fastest, requires the least internal operational expertise, and produces strong security properties when the provider operates FIPS-validated HSMs with M-of-N controls under a SOC 2 Type II audit framework. The customer-hosted model adds key custody control at the cost of significant operational burden and extended deployment timelines. The hybrid model optimizes for key custody control on the highest-value asset (the root CA key) while preserving vendor-hosted operational simplicity for the issuing CA layer. The air-gapped model is a specialized choice for environments where physical network isolation is a genuine requirement, not a preference.

The deployment model decision should be made with compliance counsel, not by the PKI team alone, because the regulatory frameworks that create key custody requirements (FedRAMP, CMMC, ITAR, DORA) are legal and contractual obligations, not purely technical ones. A well-documented deployment model selection decision, supported by the PKI Assessment analysis and the compliance framework mapping, is itself a compliance artifact that demonstrates due diligence in PKI governance.

If your organization is working through a PKIaaS deployment model selection and needs structured support, reach out to Encryption Consulting.

This post is reviewed on a six-month cadence and when material changes in FedRAMP, CMMC, ITAR, DORA, or NIS2 guidance affect deployment model compliance alignment, or when PKIaaS providers materially change their deployment model options.

Frequently Asked Questions

What are the four PKIaaS deployment models?

The four PKIaaS deployment models are: vendor-hosted (provider operates all CA infrastructure including HSMs in their cloud); customer-hosted (customer deploys and operates CA software and HSMs in their own environment using the provider’s software and management platform); hybrid (customer-hosted offline root CA with vendor-hosted issuing CAs); and air-gapped (entire CA infrastructure physically isolated from external networks, with certificates and CRLs transferred out-of-band on physical media).

Which PKIaaS deployment model is right for my organization?

The right model depends on regulatory key custody requirements, data residency constraints, operational capacity, and time-to-deploy. Organizations without specific key custody regulatory requirements should default to vendor-hosted. Organizations with documented key custody requirements should evaluate customer-hosted or hybrid. Organizations with physical network isolation requirements (classified programs, some defense and ICS environments) require air-gapped. Confirm the applicable requirements with legal and compliance counsel before selecting a model.

What is the difference between vendor-hosted and customer-hosted PKIaaS?

In vendor-hosted PKIaaS, the provider operates CA software, HSMs, CRL/OCSP, and the management console on their infrastructure. In customer-hosted, the customer deploys and operates the CA software and HSMs in their own environment; the provider supplies the software and management platform, accessible through a secure connector. The primary differentiator is key custody: vendor-hosted has provider HSMs holding CA keys; customer-hosted has customer HSMs holding them.

What is a hybrid PKIaaS deployment?

A hybrid deployment places the offline root CA in the customer’s environment (giving the customer custody of the root CA private key) while the issuing CAs are vendor-hosted (providing operational simplicity and HA for the always-on issuing infrastructure). The vendor’s issuing CAs are subordinated to the customer’s root CA through an offline signing ceremony. The root CA is used only periodically for issuing CA certificate ceremonies; the issuing CAs handle all day-to-day certificate issuance under the provider’s management.

When is an air-gapped PKI deployment required?

Air-gapped PKI is required when CA infrastructure must operate with no network connectivity to external systems. Required scenarios include classified government networks, defense programs with ITAR restrictions prohibiting network-connected CA operations, and industrial control system environments with IEC 62443 security level requirements prohibiting external CA connectivity. Air-gapped PKI is operationally intensive and should be chosen only when a genuine physical isolation requirement exists, not as a default security preference.