Blog

Hybrid Cloud PKI Services in 2026: A Complete Guide

How to design and govern PKI across on-premises and cloud environments, covering deployment models, key custody, lifecycle automation and compliance.

The short answer

Hybrid cloud PKI operates certificate authorities across on-premises infrastructure and cloud platforms under a single trust architecture. The root certificate authority typically remains offline and physically controlled, while issuing authorities operate wherever the workloads sit.

The model exists because most enterprises face two requirements at once. Critical systems that cannot move to the cloud still need certificates, and cloud-native workloads need automated, API-driven issuance at a pace manual processes cannot match.

Four decisions shape a hybrid design:

  1. Where keys reside. Data residency, regulatory obligation and classification requirements determine which keys can sit in cloud hardware security modules and which must remain on-premises.
  2. Where issuance happens. Issuing authorities can be placed close to the workloads they serve, reducing latency and improving resilience.
  3. How policy stays consistent. Certificate profiles, validity periods and approval workflows need to apply identically regardless of which authority signs.
  4. How the estate stays visible. Discovery and lifecycle management must span every environment, or the parts outside coverage become the source of outages.

This guide sets out the components, deployment models and evaluation criteria that matter, and the sequence Unsung follows when designing hybrid architectures.

What hybrid cloud PKI services provide

A hybrid architecture allows certificate authorities to operate across on-premises infrastructure and cloud platforms while remaining part of one hierarchy. The root certificate authority stays offline in a secure, physically controlled environment. Issuing authorities subordinate to that root operate in the cloud, on-premises, or both, according to what they serve.

The result is centralised policy enforcement alongside distributed issuance. Control over the root of trust remains with the organisation, while the scalability and automation benefits of cloud-based certificate operations become available to the workloads that need them.

Why enterprises adopt hybrid architectures

Many organisations inherit on-premises PKI built years ago, frequently on Microsoft Active Directory Certificate Services. These environments often operate reliably while lacking the automation, integration and visibility that current security programmes require. Our article on Active Directory Certificate Services in modern IT covers where those environments typically fall short and what can be addressed without replacement.

Cloud adoption then introduces requirements the original design never anticipated. Kubernetes clusters, serverless functions and microservices each require machine identities, frequently short-lived and issued at high frequency. Managing those alongside network devices, VPN endpoints and user certificates creates operational complexity that manual processes absorb poorly.

A hybrid approach preserves the investment in existing infrastructure while extending capability to cloud environments. It also allows modernisation to proceed in stages rather than as a single replacement programme, which materially reduces delivery risk. Where full re-platforming is the right answer, our Entrust to EJBCA migration case study describes how a twenty root certificate authority migration was delivered without operational impact to business services.

Core components of a hybrid architecture

Root and issuing certificate authorities

The root certificate authority establishes the foundation of trust for the hierarchy. In hybrid deployments it usually remains offline and on-premises, brought online only to sign subordinate certificates or handle revocation.

Issuing authorities subordinate to that root handle day-to-day operations and can be deployed across on-premises datacentres, private cloud and public cloud platforms. Each operates under policy defined at the root while being optimised for the environment it serves.

Hierarchy design determines how well the architecture accommodates growth, segmentation and regulatory separation. Our PKI design and build service covers hierarchy structure, certificate profiles and the governance framework that supports them.

Hardware security modules and key custody

Hardware security modules protect the private keys that underpin the hierarchy. In hybrid deployments, placement requires careful consideration.

Root certificate authority keys demand the highest level of protection, typically using on-premises FIPS 140-3 validated modules under documented key ceremony procedure. Organisations operating older estates should confirm whether their modules hold current validations or legacy FIPS 140-2 certificates, since certification status affects compliance position.

Cloud issuing authorities can use cloud-native key protection services, allowing key custody to be retained while certificate issuance operates in the cloud. Integration requires planning to ensure keys never exist outside protected boundaries at any point in the lifecycle, including during backup and recovery.

Our hardware security modules service covers selection, deployment, key ceremony execution and integration across hybrid estates.

Certificate lifecycle management platform

A CLM platform is what holds a hybrid architecture together operationally. It discovers certificates across all environments, tracks expiry, automates renewal and applies policy consistently, becoming the control plane for the entire estate.

When evaluating platforms, support across every deployment environment is the primary criterion. The platform should integrate with cloud provider APIs, on-premises certificate authority installations, network devices and container orchestration systems. Our guidance on how to evaluate CLM vendors and licensing models sets out the wider criteria.

Deployment models

On-premises root with cloud issuing authorities

This model keeps the root, and frequently a policy certificate authority, on-premises while deploying issuing authorities in cloud environments. Certificate requests from cloud workloads are handled close to the workload, reducing latency and improving resilience.

The root remains offline throughout normal operation, which provides strong protection for the trust anchor while enabling cloud-native issuance. This is the most common starting point for organisations extending an established PKI into cloud environments.

Managed PKI services with on-premises integration

Managed services allow certificate authority operations to be run by a specialist provider. The organisation defines certificate policy and templates while the provider handles infrastructure, availability and security operations.

In hybrid scenarios, these services connect to on-premises systems through registration authority components or API integration. This model suits organisations that need robust PKI without building dedicated internal capability. Our PKI management and hosting service operates environments under agreed service levels while the organisation retains control of policy and full visibility of operations.

Multi-cloud with centralised governance

Organisations operating across several cloud providers need architectures that behave consistently everywhere. This model establishes a governance layer enforcing policy across all platforms and on-premises environments.

Centralised governance keeps certificate profiles, validity periods and approval workflows consistent regardless of which authority issues. Security teams retain visibility and control while workload teams gain self-service access, which is usually what makes the model sustainable in practice.

Evaluating certificate authority services for hybrid environments

Integration and protocol support

A hybrid PKI has to serve diverse systems. Support for standard enrolment protocols matters: ACME for automated web server certificates, EST for device enrolment, SCEP for legacy systems and mobile device management, and CMP for enterprise applications. Our comparison of certificate management protocols covers where each is appropriate.

Beyond protocols, API quality determines what automation is achievable. Modern workloads require programmatic certificate requests, and delivery teams will expect integration with deployment pipelines and infrastructure-as-code tooling.

Policy enforcement and governance

Hybrid environments amplify governance complexity, since business units, application teams and geographic regions may each carry distinct requirements. The platform needs granular policy controls that accommodate this variation while holding security standards constant.

Role-based access control, approval workflows for sensitive certificate types and comprehensive audit logging all become more important when operating across multiple trust boundaries.

Scalability and performance

Certificate volumes grow as organisations adopt automation and machine identities. The CA/Browser Forum decision under ballot SC-081v3 to reduce maximum public TLS certificate validity to 47 days by March 2029, with domain validation reuse falling to ten days, will multiply renewal operations considerably. Our article on the reduction of public TLS certificate lifetimes sets out the schedule and its practical effect.

Evaluation should therefore cover issuance throughput, OCSP response latency and CRL distribution capability. Cloud components should scale during demand spikes without manual intervention.

Certificate lifecycle management across hybrid estates

Discovery across cloud and on-premises systems

Certificates that are unknown cannot be managed, and they are a frequent cause of outage. Discovery must span the full infrastructure, combining network scanning for on-premises devices, cloud provider API integration for cloud-hosted certificates, and container orchestration platforms for service mesh identities.

Effective discovery finds more than the certificates the organisation issued. It also identifies certificates obtained from external certificate authorities, self-signed certificates created during development, and certificates embedded in application configuration. Our guidance on building a cryptographic inventory covers how to approach this systematically.

Automation for renewal and revocation

Manual certificate management does not scale across hybrid environments. Automation handles routine renewal, reducing expiry-related outage risk, and enables rapid revocation when an incident requires it.

Automation depends on integration touchpoints throughout the estate. Load balancers, web servers, application servers and container platforms each need a method of receiving and deploying renewed certificates. Planning these integrations early avoids the common outcome where automation covers issuance but stops short of deployment. Our article on making automation work across silos addresses that gap.

Monitoring and alerting

Certificate monitoring should feed into existing security operations. Expiring certificates, failed renewals, policy violations and unusual issuance patterns each warrant alerting, and integration with security monitoring platforms ensures certificate events receive proportionate attention.

Alerting thresholds should allow adequate response time, with different handling for a certificate expiring in thirty days and one expiring in seven. Tiered alerting prevents both alert fatigue and missed renewals.

Security and compliance considerations

Data residency and key custody

Regulatory requirements frequently dictate where cryptographic keys may reside. Root certificate authority keys may need to remain within defined geographic boundaries or under direct organisational control, and hybrid architectures accommodate those constraints while still enabling cloud operations.

Key custody should be documented explicitly, identifying which keys require on-premises protection, which may use cloud key protection services, and what controls govern backup and recovery. That documentation supports both compliance audit and security review, and it is frequently the first thing an assessor asks for.

Audit logging and compliance reporting

Hybrid PKI generates audit data across multiple systems, and compliance reporting requires that data to be aggregated into a coherent view. Issuance, renewal, revocation and administrative actions all need audit trails.

Audit logs from cloud components should integrate with on-premises logging infrastructure. Centralised log management simplifies both compliance reporting and incident investigation.

Post-quantum readiness

Current public key algorithms face a long-term threat from cryptographically relevant quantum computers, and hybrid designs should incorporate crypto agility from the outset so that algorithms can change without infrastructure replacement.

NIST has published its initial post-quantum standards, and NIST Internal Report 8547 proposes deprecating RSA and elliptic curve cryptography from 2030 and disallowing them from 2035. UK organisations should also align to NCSC milestones expecting discovery and planning by 2028, high-priority migration by 2031, and full migration by 2035.

Practical preparation begins with knowing what is deployed. A Cryptographic Bill of Materials catalogues algorithms, key sizes and dependent systems across the hybrid estate, providing the baseline for transition planning. Our article on what crypto agility actually means in practice examines the design implications.

Common challenges in hybrid deployments

Bridging legacy systems and modern protocols

Older systems frequently lack support for current enrolment protocols. Network devices may require SCEP while newer applications expect ACME, and the architecture has to bridge that difference without creating security gaps.

Registration authority components can translate between protocols, presenting a consistent interface to the certificate authorities while accommodating diverse client requirements. Protocol bridging should be designed in from the start rather than added when a system fails to enrol.

Managing certificate profiles and templates

Web server, code signing, client authentication and device identity certificates each require distinct configurations, and managing these consistently across environments challenges many organisations.

A profile governance process addresses this. Define who may create new profiles, how they are tested, and where they may be deployed. Centralised profile management prevents the configuration drift that otherwise develops between environments.

Maintaining consistent policy

Policy inconsistency creates security gaps. A certificate request approved in one environment and refused in another indicates a governance problem rather than a technical one.

Centralising the policy decision point, even where issuance remains distributed, resolves this. A central policy engine evaluates requests against consistent rules regardless of which issuing authority ultimately signs.

Implementing hybrid cloud PKI

Assess the current estate. Discover certificates across all environments, document certificate authority configuration and identify integration points. A PKI health check establishes a documented baseline covering security gaps, configuration issues and operational maturity, with findings categorised by risk and accompanied by recommended mitigation. That baseline informs the architecture rather than following it.

Define governance before technology. Establish certificate policies, naming standards, validity periods and approval workflows. Document roles and responsibilities for administration. The questions of who may request certificates, who approves them and how disputes are resolved need answers before implementation begins.

Select technology and design the architecture. With requirements defined, evaluate certificate authority software, cloud services, CLM platforms and key protection options against them. Design for growth, since certificate volumes will increase, new use cases will emerge and post-quantum migration will eventually be required.

Implement, test and operationalise. Build development and test environments before production, and validate integrations thoroughly. Document operational procedures for routine tasks and incident response. Plan the operational handover from the outset, covering team training, runbooks for common scenarios and clear escalation paths ahead of go-live.

Building a resilient hybrid architecture

Hybrid cloud PKI addresses the practical reality of enterprise IT, where controlled trust anchors and cloud-native automation are both required. Connecting on-premises and cloud certificate management under unified governance provides the security benefits of the former alongside the operational agility of the latter.

Success depends on architecture, governance and operational process working together. The technologies serve the security and business objectives rather than defining them, which is why requirements should be established before platforms are evaluated.

As certificate lifetimes shorten and machine identity populations grow, the demands placed on hybrid architectures will increase. Designing for that trajectory now positions the organisation to adapt as requirements change.

Unsung is a UK-based specialist consultancy focused entirely on Public Key Infrastructure, working with government and enterprise organisations across defence, financial services, healthcare, transport and critical national infrastructure. We are vendor-neutral, and our recommendations reflect your requirements rather than a platform roadmap.

Contact us to discuss designing, implementing or operating PKI across your hybrid estate.

Frequently asked questions

What is the difference between hybrid cloud PKI and PKI as a Service?

Hybrid cloud PKI describes an architecture spanning on-premises and cloud environments under the organisation's control. PKI as a Service is a delivery model where a provider operates certificate authority infrastructure on the organisation's behalf. The two combine, since managed cloud authorities can form part of a hybrid architecture connected to on-premises systems.

Should the root certificate authority be on-premises or in the cloud?

Most organisations keep root certificate authorities offline and on-premises. The root key is the foundation of trust for the entire hierarchy, and physical control reduces exposure to cloud provider incidents. Regulatory and classification requirements frequently make this mandatory rather than preferable.

Which certificate lifecycle management capabilities matter most in hybrid deployments?

Discovery across every environment is the foundation, since certificates outside visibility cannot be governed. Renewal automation prevents outages as volumes grow, and consistent policy enforcement keeps governance coherent across on-premises and cloud components.

How should a hybrid PKI be prepared for post-quantum cryptography?

Begin with a complete cryptographic inventory covering algorithms, key sizes and dependent systems. Design for crypto agility so algorithms can be updated without infrastructure replacement. Align planning to NIST Internal Report 8547, which proposes deprecating RSA and elliptic curve cryptography from 2030 and disallowing them from 2035, and to NCSC milestones for 2028, 2031 and 2035.

Which compliance standards affect hybrid cloud PKI?

Requirements vary by sector and geography. Financial services organisations address PCI DSS alongside regional regulation, healthcare organisations consider patient data obligations, and government suppliers frequently require FIPS 140-3 validated cryptographic modules. Applicable requirements should shape the design from the outset rather than being addressed retrospectively.

How does Unsung support hybrid PKI implementations?

Unsung provides vendor-neutral PKI advisory, design, implementation and managed services for hybrid environments, covering requirements assessment, architecture design, technology selection and ongoing operation. Our exclusive focus on PKI and cryptographic infrastructure means engagements are led by consultants who work in this domain full time.
Author
-