Cross-CA Certificate Inventory: One Queryable Estate Across Every Issuance Source

A cross-CA certificate inventory is a single, reconciled record of every certificate in the organisation regardless of which authority issued it — public CAs, AD CS, HashiCorp Vault PKI, cloud CAs, service mesh issuers, OEM device CAs. It is the prerequisite for every other certificate decision: outage prevention, PQC migration planning, SC-081 readiness, and audit evidence all consume it. Most enterprises don't have one; they have five partial inventories that disagree.

AxelSpire's position: The industry sells this problem as "buy a CLM platform". That conflates two different layers. Lifecycle management renews certificates; an inventory tells you what your estate is. You can build the second without buying the first — and if you buy the first without the second, the CLM manages the subset it can see and your risk lives in the remainder.

Part of: PKI assessment methodology — the inventory is Sprint 1, Day 1–2 of the assessment.

Why single-source inventories fail

Enterprises don't have a CA. They have an average of five or more issuance sources, accumulated rather than designed:

Each source has an inventory of itself. None has an inventory of the others, and several — ephemeral Vault certificates, mesh certificates — deliberately don't keep one. The CMDB, meanwhile, records what someone once registered. In AxelSpire's assessment work, discovery scans consistently find materially more certificates than the tracked count, and the overflow always comes from the same places: DevOps-issued public certs, mesh auto-issuance, acquisitions, and device fleets.

Discovery finds certificates. Inventory reconciles them.

The two are routinely conflated. Discovery is the scanning function — CT logs, network scans, cloud API enumeration, endpoint stores. Its output is a pile of observations. An inventory is what you get after four reconciliation steps that the scanners can't do:

1. Deduplication. The same certificate observed on a load balancer, in a CT log, and in the issuing CA's records is one certificate, not three. Key: fingerprint, not subject name.
2. Chain and issuer resolution. Every leaf mapped to its actual issuing CA and root — which is also where rogue or forgotten intermediates surface.
3. Ownership binding. Every certificate bound to a service record and an accountable owner, ideally in the CMDB so ownership transitions automatically. Unowned certificates are the ones that expire in production; this is the discovery problem that manifests as a renewal problem.
4. Normalisation. One schema across sources: subject, SANs, key algorithm and size, validity window, issuance path, deployment locations. Without it the estate isn't queryable, and an inventory you can't query is a report, not an asset.

The analytics layer: what a queryable estate actually answers

This is the layer AxelSpire calls certificate estate intelligence, and it is where the inventory pays for itself. Concrete queries, each mapped to a decision:

Expiry distribution and renewal-storm detection. Plot expiries per week for the next 12 months. Clusters of certificates expiring within days of each other — usually the artefact of a bulk migration — are renewal storms waiting to fire. Staggering them is a scheduling exercise once you can see them, an outage sequence if you can't. Mechanics in the renewal operating model.

Algorithm distribution. RSA-2048 vs ECDSA vs anything PQC/hybrid, per issuance source. This table is the starting position for PQC migration — an organisation that cannot produce it cannot credibly claim a quantum-readiness plan, whatever the slide deck says.

Issuance-path anomalies. Certificates for your domains issued by CAs you don't have a relationship with (CT log reconciliation), or internal certificates issued outside policy. This is the estate-level control that no single CA's console can provide, because each console only sees itself.

SAN-overlap clustering. Grouping certificates by shared SANs reconstructs which certificates actually serve the same logical service — a service map inferred from the certificates themselves. AxelSpire uses SAN-overlap graph clustering in assessment work to find shadow duplicates (three teams independently certifying the same endpoint) and to attribute orphaned certificates to a probable owner.

Validity-period compliance. Share of the public-TLS estate already compliant with the current 200-day SC-081v3 cap, and the volume that must re-issue before the 100-day step in March 2027. Scoping note that most coverage gets wrong: SC-081v3 binds publicly trusted TLS only — private CA and device certificates are out of scope, and conflating the two misprices the migration.

Build vs buy: the honest decision table

The self-critical row is deliberate: aggregation assumes you connect the sources, so the first discovery pass on a genuinely unknown estate is still scan-driven. That is precisely why the assessment methodology starts with discovery before any tooling conversation — and why "which tool" is the wrong first question.

Where to start

Day one, no procurement: pull CT logs for your domains (crt.sh), export every CA console you know about, dedupe by fingerprint, and count. Compare that number to the CMDB. The gap between the two figures is your first estate-intelligence metric — and in AxelSpire's experience it is the number that gets the assessment funded. The full sequence is Sprint 1 of the PKI assessment methodology; to see how your gap compares to peers, see the maturity benchmarks. The same reconciled inventory is also the single most-reused artefact in a PKI audit.

FAQ

What is a cross-CA certificate inventory?
A single reconciled record of all certificates across every issuance source — public CAs, internal CAs, cloud CAs, service mesh, device fleets — deduplicated by fingerprint, bound to owners, and queryable under one schema. It differs from discovery (which finds certificates) and from CLM (which renews them).

Is a certificate inventory the same as certificate lifecycle management?
No. CLM platforms automate issuance and renewal, and bundle an inventory of the certificates they manage. An inventory is the estate-wide record including everything the CLM doesn't reach. Inventory is the visibility layer; CLM is one possible automation layer on top of it.

How many certificates does a typical enterprise actually have?
Reliably more than it tracks. AxelSpire's discovery scans consistently find the tracked count understated, with the overflow from DevOps-issued public certificates, service-mesh auto-issuance, acquisitions, and OEM device certificates.

Do ephemeral certificates (service mesh, short-TTL Vault) belong in the inventory?
As aggregate telemetry, yes; as individual records, usually no. Track issuance rate, issuer health, and policy conformance for ephemeral populations rather than per-certificate rows — the operational risks live at the issuer level.

What does AxelSpire 3AM do here?
3AM aggregates issuance data across connected CAs into one estate view with policy enforcement and analytics on top — the control-plane layer. It is not a CLM: it doesn't replace your renewal tooling, it makes the whole estate visible and governable regardless of which tooling issues the certificates.

Dan Cvrcek, AxelSpire. Field observations from enterprise assessment and platform work. Updated July 2026.