Multi-Cloud Certificate Inventory: Why It's Harder Than It Looks
Imagine you've stored your possessions across three garages owned by three different friends. The friend with the suburban house. The friend with the city flat. The friend with the holiday cabin. You know roughly what's in each. You don't know exactly what's in any of them. Each garage has its own access rules - one wants a key code, one wants a phone call ahead, one is open whenever you're in town. Getting everything back is a much bigger project than putting it there.
This is multi-cloud certificate inventory.
If your organisation is on AWS and Azure and GCP - or any two of these, plus maybe Cloudflare, plus an internal data centre - your cert inventory is spread across systems that don't talk to each other. Each cloud has its own cert manager, its own access controls, its own renewal mechanics, its own definition of "what we're tracking." There is no native "show me everything" button.
Most teams discover this the hard way: during an audit, an incident, or a migration project that requires "the full list of certs."
Here's why multi-cloud inventory is structurally harder than single-cloud, what each cloud's story actually looks like, and how to build the unified view that nobody ships out of the box.
Why multi-cloud is the default now
A decade ago, "the cloud" meant AWS for most teams. Some had Azure for Microsoft-shaped reasons. Few had both.
The default in 2026 is different. Most enterprises run on at least two clouds - for resilience, for cost negotiation, for the workloads that simply work better on one or the other. Plus they've kept some on-premises infrastructure. Plus they front external traffic through a CDN. Plus they have an internal PKI somewhere.
Each of these spawns certs. Each has its own cert management story. The inventory problem multiplies with each platform.
What each cloud's cert story looks like
A quick tour of the major players.
AWS Certificate Manager (ACM). Free certs for AWS services (ELB, CloudFront, API Gateway, etc.). Automatically renewed if the cert is "in use" by an AWS service. Cannot be exported - you can't take an ACM cert and install it on a server outside AWS. Inventory is per-region, per-account. With multi-account AWS organisations, you have an inventory per account, multiplied by every region you use. Listing them all requires AWS Organizations + cross-account access.
Azure Key Vault. Stores certs (and keys, and secrets) for Azure services. Can integrate with App Service, Application Gateway, Front Door. Renewal is integration-dependent - some integrations auto-renew via Key Vault's "auto-renewal" feature, some don't. Inventory is per Key Vault, per subscription. Listing requires Azure CLI or PowerShell across subscriptions.
GCP Certificate Manager. Manages certs for Google Cloud Load Balancing and related services. Supports both Google-managed certs (auto-renewed) and self-managed. Inventory is per-project. Cross-project visibility requires the right IAM grants and a script.
Cloudflare-managed certs. If you front your sites through Cloudflare, Cloudflare can manage the public-facing cert automatically. The cert lives in Cloudflare's edge. You don't really see it. Renewal is invisible. Inventory is per zone, accessible via Cloudflare's API.
Fastly and other CDNs. Same pattern as Cloudflare - managed certs at the edge, with their own API and dashboard.
Internal CAs (Vault PKI, ADCS, step-ca, EJBCA). Each has its own issuance log and inventory. Each has its own access pattern.
Direct-purchase certs (DigiCert, Sectigo, GoDaddy). Live wherever you installed them. The CA portal has a list. Your server has a copy. The two may not match.
That's seven distinct cert sources in a single mid-sized enterprise. Each has its own inventory mechanism. None of them talks to the others.
The gaps between them
The interesting failures live in the gaps.
Certs that exist in one cloud but reference services in another. A Cloudflare-managed cert for api.example.com that routes to an AWS load balancer. Cloudflare knows the cert exists. AWS doesn't see it. If you migrate the backend off AWS, who tells Cloudflare?
Certs that span clouds. A wildcard cert installed on AWS, Azure, and an on-prem load balancer. Same cert, three places. If you renew it on AWS, do the other two get the new version? When does AWS renew it - based on which service uses it?
Certs nobody's tool sees. Internal admin tools running on EC2 instances, with self-signed certs the engineers generated by hand. Internal CAs that don't have an API. Vendor appliances with embedded certs.
Renewal collisions. A cert exists in two places. One copy renews automatically; the other doesn't. After renewal, the two copies are different. Which one are clients seeing?
The pattern: every cloud knows about its own certs. None of them knows about anyone else's. The gaps are where outages live.
How to actually unify the inventory
Three layers, from cheapest to most thorough.
Layer 1: API pull. Write or buy a tool that polls each cloud's cert API on a schedule and writes the results to a single database. AWS ACM (per account, per region), Azure Key Vault (per subscription), GCP Certificate Manager (per project), Cloudflare API, your internal CAs' APIs. Reconcile in one place.
This is the right starting point. It catches everything the clouds know about. It does not catch the certs the clouds don't know about.
Layer 2: External scanning. From outside your networks, scan every endpoint you know about. Record the cert each one is actually serving. Compare against the cloud inventories.
This catches the certs the clouds don't know about (vendor-embedded, custom-installed, services running outside managed cloud platforms). It also catches the case where the cloud thinks one cert is serving and a different one actually is.
Layer 3: Certificate Transparency monitoring. Watch CT logs for any cert issued by a public CA for your domains. New certs that don't appear in any of your inventories are surprises worth investigating.
This catches certs that were issued but never made it into your cloud inventories - including certs issued by attackers for your domains, which is a different but related problem.
Together, these three layers give you a real inventory. None of them alone is sufficient. The point isn't to pick one - it's to run all three and reconcile them.
The "we're moving everything to one cloud" denial
A specific trap worth naming.
Many teams' answer to multi-cloud cert complexity is "we'll consolidate to one cloud." This is occasionally a real plan. Most of the time it's wishful thinking.
The reasons multi-cloud exists in the first place - acquired companies, business-unit autonomy, vendor lock-in concerns, regulatory requirements, sheer organisational momentum - don't disappear because someone drew an architecture diagram. The consolidation project, if it happens, takes years. During those years, the cert inventory problem is real.
The honest answer: build for multi-cloud now, even if you intend to consolidate. Multi-cloud inventory tooling pays back during the consolidation by surfacing what you actually have to migrate. Single-cloud assumptions during consolidation leave certs orphaned.
One small ask
Multi-cloud certificate inventory is one of those problems nobody owns until something breaks. The cheapest insurance is continuous discovery across all your platforms - cloud APIs, external scanning, CT logs - reconciled into one source of truth. TLS Radar does the external scanning and CT side and integrates with cloud APIs for the rest. Free tier covers three domains, which is enough to surface the gaps between what your cloud tools think you have and what you actually serve.
Related reading
Get the next post in your inbox
TLS monitoring tips and product updates. No spam, unsubscribe anytime.