BlogSupportDocumentation
TigerTrust
Solutions · Multi-Cloud

One certificate plane across every cloud you run.

AWS ACM, Azure Key Vault, GCP Certificate Manager, and on-prem CAs each speak their own dialect. TigerTrust unifies them under one policy, one inventory, one audit trail — without forcing you off cloud-native primitives.

Book a demoTalk to a cloud expert
The problem

Every cloud runs its own CA. And its own outage.

Multi-cloud enterprises maintain parallel PKI stacks in AWS, Azure, and GCP, plus on-prem for what won't move. No unified inventory, no consistent policy, and every audit becomes a three-way reconciliation exercise.

Without unified multi-cloud PKI
  • AWS ACM, Azure KV, and GCP CAS each maintained by different teams
  • Weak crypto slips into one cloud, everyone finds out at the next audit
  • No cross-cloud mTLS — workloads speak plaintext across cloud boundaries
  • Migration between clouds means re-issuing everything from scratch
  • Egress traffic terminated on stale certs no team owns
With TigerTrust multi-cloud PKI
  • Central control plane provisions into ACM, Key Vault, GCP CAS natively
  • One policy engine enforces crypto strength across every provider
  • Cross-cloud workload identity for consistent mTLS
  • Portable certificates — move workloads between clouds without reissuing
  • Unified inventory and audit across cloud, region, and account
Native provisioning

Issue directly into each cloud's native store

Provision into AWS ACM (public + private), Azure Key Vault, and GCP Certificate Manager using each provider's native APIs. Load balancers, CDNs, and API gateways see what they expect.

How it works
  • AWS ACM public and private
  • Azure Key Vault secrets and certificates
  • GCP Certificate Manager & CAS
  • Oracle, IBM, AliCloud support
Multi-cloud architecture spanning multiple providers
Unified inventory

One view across every cloud account

See every certificate in every account across every provider. Filter by expiry, cipher, key algorithm, or ownership. Answer the "what breaks tomorrow" question in one query.

How it works
  • Cross-cloud, cross-account inventory
  • Filter by any attribute
  • Ownership tagging from cloud IAM
  • CSV, API, and BI-tool export
Multi-cloud control plane dashboard
Cross-cloud identity

mTLS that works across cloud boundaries

Workloads in AWS EKS speak mTLS to workloads in Azure AKS using consistent SPIFFE identities. No cloud-specific quirks in your application code.

How it works
  • SPIFFE-compatible workload IDs
  • Cross-cluster mesh federation
  • Portable identities across clouds
  • Zero-trust across provider borders
Cross-cloud service-to-service communication
Portability

Move workloads without re-issuing certificates

Cloud migration doesn't mean starting over. Certificates issued by TigerTrust move with the workload, backed by a single root of trust that spans every provider.

How it works
  • Single root of trust across clouds
  • Migration without reissuance
  • Consistent chain of trust
  • Region-pinned when residency demands it
Workload migration across cloud providers
Multi-cloud, one experience

Every provider, one operating model.

Stop building cloud-specific PKI teams — hire one.

Provider integrations
Native APIs for AWS, Azure, GCP, Oracle, IBM.
  • ACM, KV, CAS
  • IAM/OIDC auth
  • Regional endpoints
Consistent policy
One rule set enforced everywhere.
  • Algorithm allow-lists
  • Validity windows
  • Approved issuers
Fleet inventory
Every cert in every account in every cloud.
  • Cross-cloud search
  • Ownership tagging
  • BI-tool export
Workload identity
SPIFFE identities that traverse cloud borders.
  • Mesh federation
  • Portable trust
  • Zero-trust ready
Hybrid friendly
On-prem CAs join the same control plane.
  • Bridge to legacy CAs
  • ADCS coexistence
  • Air-gapped ops
Residency & sovereignty
Region-pinned issuance for GDPR / Schrems II.
  • EU, US, APAC pinning
  • Sovereign clouds
  • Data localisation

From multi-cloud deployments

5+
Cloud providers supported
100+
Regions across clouds
1
Policy engine to run them all
<1s
Cross-cloud issuance
Case study
Fortune 500 · Multi-cloud consumer

Three clouds, one operating model, one on-call rotation.

“We used to run three cloud PKI teams — one per provider. TigerTrust let us go back to one team with better coverage than the three teams combined.”
— Chief Cloud Architect
5+
Cloud providers unified
100+
Regions across clouds
<1s
Cross-cloud issuance
Integrations

Fits your existing stack

Native APIs for every major cloud CA, plus the hybrid on-prem systems that will never move.

AWS ACM
AWS
AWS Private CA
AWS
Azure Key Vault
Azure
Azure Cert Services
Azure
GCP Cert Manager
GCP
GCP CAS
GCP
Oracle OCI
Cloud
IBM Cloud
Cloud
AliCloud
Cloud
HashiCorp Vault
On-prem
Microsoft ADCS
On-prem
Cloudflare
CDN
Explore all integrations
FAQ

Frequently asked questions

TigerTrust calls the native APIs on your behalf. For AWS: ACM public and private, IAM roles for cross-account trust. For Azure: Key Vault secrets and certificates with managed identities. For GCP: Certificate Manager and CAS with workload identity. The certificates end up where your load balancers, CDNs, and API gateways expect them, but under a unified policy engine.
No. SPIFFE-compatible workload identities are consistent across clouds — a pod in EKS presents an SVID that a pod in AKS trusts, because the root of trust is common. Mesh federation (Istio, Linkerd, Consul) uses standard SPIFFE trust bundles. Application code that already speaks mTLS keeps working; only the trust bootstrap changes.
Certificates issued by TigerTrust move with the workload. The chain of trust is a single TigerTrust root that spans every cloud, so a cert issued for a service in AWS remains valid when that service migrates to Azure. No mass re-issuance, no cutover ceremony, no lift-and-shift for the trust layer.
Region-pinned issuance keeps keys and audit logs in the region that generated them. Policy and reporting flow globally but the sensitive material stays local. Supports EU, US, APAC, sovereign clouds (AWS GovCloud, Azure Government, Oracle Gov), and BFSI-regulated regions. GDPR, Schrems II, and equivalent obligations are documented per deployment.
Yes. Microsoft ADCS is bridged via an auto-enrolment proxy, EJBCA via EST/SCEP, and HashiCorp Vault as a backend. On-prem workloads issue against the same policy engine as cloud workloads, and hybrid inventory flows into the same dashboard. This is how customers with 100+ on-prem CAs modernise without a big-bang migration.
Discovery agents deploy per cloud account and stream cert metadata to the central control plane. Inventory scales linearly with account count. Search, filter, and export work across every account and region. Ownership is inferred from cloud IAM (AWS resource tags, Azure resource groups, GCP labels) so the fleet inherits your existing organisational structure.
Related resources

Keep exploring

Product

PKI Management

The central control plane behind unified multi-cloud PKI.

Read more
Solution

Cloud-native

SPIFFE identities, mesh federation, and ephemeral certs.

Read more
Solution

Kubernetes

One control plane across EKS, AKS, GKE, and on-prem.

Read more
Solution

DevOps

IaC providers and CI plugins for multi-cloud pipelines.

Read more

End cloud silos at the certificate layer.

Request a multi-cloud demoTalk to a cloud expert