Multi-Cloud PKIaaS Architecture Guide for AWS, Azure, and GCP

Most enterprise environments are not single-cloud. They run workloads across AWS, Azure, and GCP simultaneously, alongside on-premises data centers, Kubernetes clusters in multiple regions, containerized microservices with service meshes, and IoT or edge deployments. Certificate infrastructure that works well in one environment and is bolted on separately in the others produces exactly the outcome organizations most want to avoid: fragmented certificate inventories, inconsistent policies, multiple audit log silos, and outage exposure in the environments that were never fully integrated.

A well-designed multi-cloud PKI as a Service architecture eliminates that fragmentation. A single PKIaaS root CA becomes the authoritative trust anchor for the entire estate. Cloud-native issuing CA integrations, direct protocol-level enrollment, and a CA-agnostic CLM layer above all of it produce unified certificate governance across every environment without requiring a separate PKI for each cloud or platform.

This guide covers the architecture patterns, integration points, enrollment protocol choices, and operational considerations for deploying PKIaaS across AWS, Azure, GCP, Kubernetes, service mesh environments, and on-premises infrastructure.

Quick Answer: What Does Multi-Cloud PKIaaS Architecture Look Like?

The canonical multi-cloud PKIaaS architecture is a hub-and-spoke model. The PKIaaS provider operates the offline root CA and manages issuing CA certificates for each cloud environment. Cloud-native private CA services (AWS ACM Private CA, GCP Certificate Authority Service) act as subordinate issuing CAs under the PKIaaS root, issuing certificates locally within each cloud environment. Kubernetes clusters use cert-manager with an ACME ClusterIssuer pointing to the PKIaaS endpoint. A CA-agnostic CLM layer sits above all of it, providing unified certificate discovery, expiration monitoring, automated renewal, and policy enforcement across the full multi-cloud estate regardless of which issuing CA issued each certificate.

Key Takeaways

• The multi-cloud PKIaaS architecture problem is fundamentally a trust anchor problem. If each cloud environment has its own root CA, certificates from one environment cannot be verified by systems in another without explicit cross-trust configuration. A single PKIaaS root CA as the universal trust anchor eliminates this.
• Cloud-native private CA services (AWS ACM Private CA, GCP Certificate Authority Service) can be subordinated to the PKIaaS root, allowing local certificate issuance within each cloud at cloud-native speed while preserving the unified chain of trust. Azure integration is primarily through Key Vault and Intune.
• cert-manager is the de facto certificate management controller for Kubernetes and integrates with PKIaaS through an ACME ClusterIssuer with External Account Binding, handling the CA/Browser Forum 47-day validity schedule (effective March 2029) transparently through automated renewal.
• Service mesh mTLS (Istio, Linkerd) can be integrated with PKIaaS through the service mesh’s pluggable CA interface, replacing the default self-signed mesh root with a PKIaaS-rooted hierarchy visible to the organization’s CLM inventory.
• A CA-agnostic CLM layer is the critical operational component. Without it, certificates from AWS ACM PCA, GCP CAS, Kubernetes pods, and Azure-managed devices each live in separate inventories that cannot be managed as a unified estate.

Architecture Overview: Hub-and-Spoke PKI for Multi-Cloud

The hub-and-spoke pattern places the PKIaaS root CA at the center of the trust hierarchy. Each cloud environment, Kubernetes cluster, and on-premises segment connects as a spoke, either through a subordinated cloud-native issuing CA or through direct enrollment protocol connectivity. The CA-agnostic CLM layer sits above the hub, collecting certificate inventory from every spoke through API connectors and providing unified governance regardless of which issuing CA served each certificate.

The diagram above shows the reference architecture. The PKIaaS root CA issues subordinate CA certificates to AWS ACM Private CA and GCP Certificate Authority Service, enabling local issuance within each cloud under the unified chain of trust. Azure workloads enroll directly via ACME or SCEP. Kubernetes clusters connect through cert-manager with an ACME ClusterIssuer. On-premises environments use EST, SCEP, or WSTEP. All spokes report certificate inventory to the CLM layer above.

AWS Integration: ACM Private CA as a Subordinate Issuing CA

Pattern 1: ACM PCA as a Subordinated Issuing CA

AWS Certificate Manager Private CA (ACM PCA) supports operating as a subordinate CA under an external root CA. This is the preferred integration pattern for AWS-heavy environments because it preserves the full AWS-native integration depth of ACM PCA (ECS container certificate provisioning, EKS integration, ALB/NLB TLS offload, IAM-policy-controlled issuance) while placing the root CA under PKIaaS governance.

The subordination flow works as follows. An ACM PCA CA is created with CA type SUBORDINATE. ACM PCA generates a CSR for the subordinate CA. That CSR is submitted to the PKIaaS provider, which signs it using the PKIaaS issuing CA and returns the signed subordinate CA certificate. The signed certificate is imported into ACM PCA, activating it. From this point, ACM PCA issues end-entity certificates within the AWS environment under the PKIaaS chain of trust. AWS services that natively integrate with ACM PCA (ALB, NLB, API Gateway, CloudFront) can be configured to use subordinated ACM PCA certificates directly. The PKIaaS CLM layer receives certificate inventory from ACM PCA through the AWS ACM PCA List Certificates API.

Pattern 2: Direct ACME Enrollment from AWS Workloads

EC2 instances can authenticate to the PKIaaS ACME endpoint using the Instance Metadata Service (IMSv2) to obtain signed instance identity documents that serve as proof of identity for ACME External Account Binding. EKS pods use OIDC-based Workload Identity tokens from the EKS OIDC provider. Certificates obtained through direct ACME enrollment are stored in AWS Secrets Manager, which can be configured to call the PKIaaS ACME endpoint at renewal time for automated rotation.

Azure Integration: Key Vault, Intune, and AKS

Pattern 1: Azure Key Vault Certificate Issuance

Azure Key Vault supports certificate lifecycle management with external certificate issuers through its non-integrated issuer model. The PKIaaS provider is configured as a certificate issuer in Azure Key Vault. Key Vault generates the key pair within Key Vault (keeping the private key in the Azure HSM boundary), constructs a CSR, and sends the CSR to the PKIaaS issuance endpoint. The PKIaaS CA signs the CSR and returns the certificate. Azure services that integrate with Key Vault certificates (App Service, Application Gateway, Azure Front Door, Azure Container Apps) can reference the Key Vault certificate directly.

Pattern 2: Microsoft Intune Device Certificate Enrollment

PKIaaS with native Intune integration provides automated certificate provisioning for Windows, macOS, iOS/iPadOS, and Android devices. The enrollment flow uses the PKIaaS SCEP endpoint configured as the certificate authority in the Intune SCEP profile. PKIaaS providers that support native Intune integration handle the SCEP challenge password validation directly, eliminating the need for an on-premises NDES server. Device certificates are used for 802.1X network authentication, VPN authentication, and MDM-managed application access.

Pattern 3: AKS Certificate Management via cert-manager

AKS clusters follow the same cert-manager integration pattern described in the Kubernetes section below. The Azure AD Workload Identity federation model allows AKS pods to exchange their Kubernetes service account tokens for Entra ID access tokens, which can be used to authenticate to PKIaaS endpoints that support Azure AD as an external IdP for ACME EAB.

GCP Integration: Certificate Authority Service as a Subordinate CA

Pattern 1: GCP CAS as a Subordinated Issuing CA

A GCP CAS Enterprise-tier CA pool is created with CA type SUBORDINATE. GCP CAS generates a CSR, which is signed by the PKIaaS issuing CA and imported back into GCP CAS. GCP services that integrate natively with CAS include GKE, Cloud Load Balancing, API Gateway, and Certificate Manager. GCP CAS’s certificate issuance API is IAM-policy-controlled, enabling fine-grained access control over which GCP service accounts and workloads can request certificates from each CA pool.

Pattern 2: GKE Workload Identity for ACME Authentication

GKE’s Workload Identity feature allows Kubernetes service accounts in GKE to impersonate GCP service accounts, providing a cryptographically verifiable identity for GKE pods without requiring service account key files. GCP-native OIDC tokens issued by the GKE OIDC provider can be used as proof of identity for ACME EAB authentication to the PKIaaS endpoint, eliminating the need for static credentials in Kubernetes Secrets.

Kubernetes Integration: cert-manager and PKIaaS

cert-manager is the Kubernetes-native certificate management controller that handles certificate request, issuance, storage, and renewal for Kubernetes workloads. It is the standard integration path for PKIaaS in any Kubernetes environment, regardless of which cloud the cluster runs on. A Certificate resource or Ingress annotation triggers cert-manager, which sends an ACME Order to the PKIaaS endpoint. The PKIaaS provider issues an ACME challenge (HTTP-01 or DNS-01), cert-manager completes it, the PKIaaS CA signs the CSR, and the resulting certificate is stored as a Kubernetes Secret.

cert-manager Configuration for PKIaaS

The cert-manager ClusterIssuer resource for PKIaaS ACME integration requires the PKIaaS ACME server URL, an External Account Binding key ID and HMAC key stored in a Kubernetes Secret, and the challenge solver configuration (HTTP-01 with Ingress class, or DNS-01 with the appropriate DNS provider webhook).

apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: pkiaas-acme-issuer
spec:
  acme:
    server: https://acme.pkiaas-provider.example.com/acme/directory
    externalAccountBinding:
      keyID: <EAB-key-id>
      keySecretRef:
        name: pkiaas-eab-secret
        key: hmac-key
    solvers:
    - http01:
        ingress:
          class: nginx

For production deployments, EAB credentials should be provisioned using a secrets management solution (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault, or GCP Secret Manager) rather than stored directly as static Kubernetes Secrets. At 47-day certificate validity, cert-manager renewals occur approximately every 17 days per certificate, entirely automated and transparent to the application.

Service Mesh Integration: Istio and Linkerd mTLS

Service meshes provide mutual TLS (mTLS) between microservices by issuing short-lived workload identity certificates to each service’s sidecar proxy. By default, Istio and Linkerd use self-signed root CAs for the mesh trust domain, making mesh certificates invisible to the organization’s PKI governance. Integrating the mesh with PKIaaS changes this: all workload identity certificates are issued under the organization’s PKIaaS chain of trust, and the CLM layer can inventory and audit mesh certificates alongside infrastructure and application certificates.

Istio Integration via cert-manager istio-csr

The cert-manager istio-csr agent is the recommended integration approach. istio-csr intercepts workload certificate signing requests from istiod and fulfills them using cert-manager Issuer resources. The chain is: Istio sidecar requests workload cert from istiod, istiod delegates to istio-csr, istio-csr uses cert-manager to request from PKIaaS ACME, PKIaaS signs the CSR under the mesh intermediate CA, the certificate is returned to the sidecar. Workload identity certificates in the mesh are short-lived (typically 24-hour validity) and rotated automatically by istiod. Alternatively, a Vault PKI Secrets Engine backed by PKIaaS as the root can serve as the Istio external CA for high-volume mesh environments.

Linkerd Integration via cert-manager Trust Anchor

Linkerd uses a trust anchor (root CA) and an identity issuer (intermediate CA). cert-manager issues and automatically rotates the Linkerd identity issuer certificate from the PKIaaS CA. A Certificate resource in the linkerd namespace requests a CA certificate (IsCA=true) from the PKIaaS ACME ClusterIssuer. cert-manager stores it as a Kubernetes Secret in the linkerd namespace. Linkerd reads the identity issuer certificate from that Secret and uses it to sign workload certificates. cert-manager rotates the identity issuer automatically before expiry without service disruption.

HashiCorp Vault PKI Engine as an Intermediate Layer

HashiCorp Vault’s PKI Secrets Engine can act as an intermediate CA subordinated to the PKIaaS root, issuing short-lived certificates to DevOps pipelines, service mesh workloads, and infrastructure automation at high volume and low latency without a network round-trip to the PKIaaS endpoint. Vault’s PKI engine is configured with an intermediate CA certificate signed by the PKIaaS issuing CA. Applications request certificates from the Vault PKI endpoint; Vault signs the CSR locally and returns the certificate, which is in the PKIaaS chain of trust. Vault’s authentication methods (Kubernetes auth, AWS IAM auth, Azure MSI auth, GCP service account auth) verify requestor identity before issuing. The CLM layer polls the Vault PKI API to include Vault-issued certificates in the unified inventory.

On-Premises Integration: EST, SCEP, and WSTEP

EST (RFC 7030) is the preferred protocol for on-premises servers, network devices, and IoT endpoints with internet connectivity. Infrastructure management tools (Ansible, Puppet, Chef, Terraform) can call the EST API directly. SCEP is preferred for network devices and legacy management platforms, typically flowing through a SCEP proxy or registration authority that validates enrollment requests against Active Directory before forwarding to the PKIaaS SCEP endpoint. WSTEP with an on-premises PKIaaS agent supports Windows Active Directory environments: the agent connects via LDAPS to validate user and device identity, then forwards approved requests to the PKIaaS issuance endpoint, replacing ADCS while retaining Group Policy-driven certificate auto-enrollment.

Unified CLM Across the Multi-Cloud Estate

A CA-agnostic CLM platform connects to each certificate source through API integrations and provides unified inventory, monitoring, and automation regardless of which issuing CA signed each certificate. The CLM connectors needed for a full multi-cloud PKIaaS deployment are: PKIaaS provider API; AWS ACM PCA API; GCP CAS API; Azure Key Vault API; Kubernetes cert-manager Secret scanner; HashiCorp Vault PKI API; and on-premises network discovery. Encryption Consulting’s CertSecure Manager provides these connectors plus unified certificate discovery, expiration monitoring with configurable advance alerts, automated renewal, policy enforcement, and a single audit log across the multi-cloud estate.

Post-Quantum Readiness in a Multi-Cloud PKIaaS Architecture

NIST finalized FIPS 203 (ML-KEM), FIPS 204 (ML-DSA), and FIPS 205 (SLH-DSA) in August 2024. NIST IR 8547 guidance points toward deprecating RSA and ECC around 2030. For a multi-cloud PKIaaS architecture, the PQC migration must be coordinated across every spoke simultaneously: PKIaaS HSMs (ML-DSA firmware support), AWS ACM PCA and GCP CAS (cloud vendor roadmaps), cert-manager and the Kubernetes API server, service mesh proxies (Envoy for Istio, Linkerd proxy), and HashiCorp Vault PKI engine. Hybrid certificates combining classical and ML-DSA algorithms in a single certificate are the recommended migration bridge, allowing gradual rollout rather than a hard cutover. Encryption Consulting’s PQC Readiness service and PQC Center of Excellence provide multi-cloud PQC migration assessments mapped to each layer.

How Encryption Consulting Can Help

• PKI as a Service: Encryption Consulting’s PKIaaS offering provides the root CA and issuing CA infrastructure described in this guide, with support for AWS ACM PCA subordination, GCP CAS subordination, cert-manager ACME integration, Intune MDM enrollment, HashiCorp Vault PKI integration, and on-premises EST/SCEP/WSTEP enrollment. Contact us at Encryption Consulting.
• CertSecure Manager: Encryption Consulting’s CertSecure Manager provides the CA-agnostic CLM layer with connectors for PKIaaS, AWS ACM PCA, GCP CAS, Azure Key Vault, Kubernetes Secrets, HashiCorp Vault PKI, and on-premises network discovery.
• PKI Architecture Advisory: For organizations designing a multi-cloud PKI architecture from scratch or modernizing a fragmented PKI estate. See our PKI Services for scope details.
• HSM as a Service: Dedicated FIPS 140-3 Level 3 certified HSM capacity for the PKIaaS root CA or Vault PKI intermediate CA. See HSM as a Service.
• PQC Readiness: Encryption Consulting’s PQC Readiness service maps the PQC readiness of each layer and produces a coordinated migration roadmap aligned to the NIST IR 8547 timeline.

Conclusion

A multi-cloud PKIaaS architecture built on the hub-and-spoke pattern delivers what fragmented cloud-specific PKI cannot: a single chain of trust verifiable across every environment, a unified CLM layer providing operational visibility and automation across the full estate, and a single governance framework for certificate policy, audit, and compliance evidence. AWS ACM PCA subordination, GCP CAS subordination, cert-manager ACME integration, service mesh CA plugins, Vault PKI intermediate CA, and on-premises EST/SCEP/WSTEP enrollment are all documented, production-tested patterns. The operational complexity is in running each integration without a CA-agnostic CLM layer above them. Reach out to Encryption Consulting to discuss your multi-cloud PKI architecture.

This post is reviewed on a six-month cadence and immediately when AWS, Azure, or GCP add material PKI-related integrations; when cert-manager, Istio, or Linkerd release major CA integration changes; or when NIST updates PQC algorithm support timelines relevant to multi-cloud PKI infrastructure.

Frequently Asked Questions

What is multi-cloud PKIaaS architecture?

A design pattern in which a single PKIaaS provider acts as root CA across AWS, Azure, GCP, on-premises, Kubernetes, and edge environments through enrollment protocols (ACME, EST, SCEP) and a CA-agnostic CLM layer, producing a unified certificate inventory, consistent policy, and a single audit log across the entire estate.

How does PKIaaS integrate with AWS?

Via ACM PCA subordination (PKIaaS root signs the ACM PCA subordinate CA CSR, preserving cloud-native AWS service integration) or direct ACME enrollment using IMSv2 or EKS OIDC tokens for EAB authentication.

How does PKIaaS integrate with Azure?

Via Azure Key Vault non-integrated external issuer, Microsoft Intune SCEP enrollment for managed devices, and AKS cert-manager ACME with Azure AD Workload Identity Federation.

How does PKIaaS integrate with GCP?

Via GCP CAS subordination (PKIaaS root signs the CAS subordinate CA CSR) or direct ACME enrollment using GKE Workload Identity OIDC tokens for EAB authentication.

How does cert-manager integrate with a PKIaaS provider?

Via an ACME ClusterIssuer with External Account Binding credentials. cert-manager automatically requests, renews, and stores certificates as Kubernetes Secrets, handling the CA/Browser Forum 47-day validity schedule transparently through automated renewal triggered 30 days before expiry.

What is the best multi-cloud PKI architecture pattern for an enterprise?

Hub-and-spoke: PKIaaS root CA at the hub, cloud-native issuing CAs (ACM PCA for AWS, GCP CAS for GCP) as spokes, direct ACME or SCEP for Azure and other environments, and a CA-agnostic CLM layer above all of it for unified inventory, monitoring, and policy enforcement.