Certificate Sprawl: How to Regain Visibility Across Your Machine Identities

Part of the Machine Identity Management guide.

Ask your security team how many certificates are active in your environment right now. Then ask your platform engineering team the same question. Then your DevOps team. Then whoever manages your IoT fleet.

You will get four different numbers. None of them will be correct. All of them will be too low.

This is certificate sprawl — the uncontrolled accumulation of machine identities across teams, environments, and certificate authorities with no centralized inventory, no ownership mapping, and no lifecycle tracking. It is the most common and most dangerous precondition for a certificate-related outage, and it exists in virtually every enterprise that has not explicitly invested in solving it.

Certificate sprawl is not a technical failure. It is an organizational one. It is the predictable outcome of decentralized teams independently managing certificates with no shared visibility layer. Solving it is the prerequisite for every other aspect of machine identity management — you cannot govern, automate, or secure what you cannot see.

How Certificate Sprawl Happens

No organization sets out to lose track of its certificates. Sprawl accumulates incrementally through five mechanisms that are individually reasonable and collectively catastrophic:

Multi-team issuance with no central registry. The network team requests certificates from DigiCert. Platform engineering uses Let's Encrypt via ACME. The DevOps team runs an internal CA on HashiCorp Vault. The cloud team uses AWS Certificate Manager and Azure Key Vault. The IoT team provisions device certificates through a manufacturing PKI. Each team has a process that works for their scope. None of them feed into a common inventory.

Shadow CAs and self-signed certificates. When a developer needs a certificate for a test environment and the corporate PKI process takes three days, they generate a self-signed certificate. That test environment becomes staging. Staging becomes production. The self-signed certificate is now a production machine identity that exists outside every governance framework. Multiply this by every team with the ability to run openssl req and you have a shadow CA problem that grows faster than your security team can discover it.

Infrastructure sprawl extends certificate sprawl. Every new cloud account, Kubernetes cluster, SaaS integration, and edge deployment creates new certificate requirements. Cloud providers auto-provision certificates for managed services, creating machine identities that your team did not explicitly request and may not know exist. Multi-cloud architectures compound this: the same application may have certificates issued by three different mechanisms across AWS, Azure, and GCP.

Mergers and acquisitions. Acquiring a company means acquiring its certificates — including its internal CAs, its trust hierarchies, its expired certificates still in production, and its shadow CAs. M&A is the fastest way to double your certificate sprawl overnight with zero visibility into what you just inherited.

Long-lived certificates outlast institutional memory. A certificate issued with a 10-year lifespan will outlast the tenure of the person who requested it, the team that managed the service it protected, and potentially the CA that issued it. When it expires, nobody knows it exists until something breaks.

The Real Risk: What You Cannot See, You Cannot Protect

Certificate sprawl is often framed as an operational risk — expired certificates cause outages. This is true but incomplete. The security risk is equally severe:

Unmanaged certificates cannot be rotated when vulnerabilities are discovered. When a new cryptographic weakness is identified, the remediation question is: "Which certificates in our environment use the affected algorithm?" If you do not have a complete inventory, you cannot answer this question. You cannot scope the remediation. You cannot prioritize. You are operating blind during a time-sensitive security response.

Unknown CAs represent uncontrolled trust. Every certificate authority in your environment — including the ones you did not intentionally deploy — is a trust anchor. A compromised shadow CA can issue certificates that your infrastructure will trust. If you do not know the CA exists, you cannot monitor it, restrict it, or decommission it.

Expired certificates are not just an availability problem. An expired certificate on a monitoring endpoint means your security tooling has a blind spot. An expired certificate on an internal API means a service may fall back to unencrypted communication. An expired certificate on an IoT device may mean the device cannot receive firmware updates, leaving it permanently vulnerable.

Certificate sprawl blocks zero trust adoption. You cannot enforce machine identity authentication at every boundary if you do not know which boundaries have certificates and which do not. Zero trust requires completeness. Certificate sprawl is the antithesis of completeness.

Building a Cryptographic Inventory

The corrective action is straightforward in concept and difficult in execution: build a complete inventory of every certificate, key, and credential in your environment. This is a cryptographic inventory — the machine identity equivalent of an asset register.

A credible cryptographic inventory requires four data collection mechanisms, because no single mechanism finds everything:

Network scanning. Probe every IP range and port for TLS endpoints. This finds certificates that are actively serving traffic, including the ones nobody remembers deploying. Limitation: it only finds certificates that are currently in use and reachable from the scanning point. It misses certificates stored in keystores, certificates on devices behind NAT, and certificates that are deployed but not yet active.

CA log harvesting. Pull issuance records from every certificate authority — public CAs via Certificate Transparency logs, internal CAs via their audit logs, cloud-managed CAs via provider APIs. This gives you the issuance side: what was issued, when, to whom, with what parameters. Limitation: it does not tell you where the certificate was deployed, whether it is still in use, or whether it has been replaced.

Agent-based discovery. Deploy lightweight agents on servers, containers, and endpoints to scan local keystores, file systems, and configuration files for certificates and keys. This is the most thorough collection mechanism and the hardest to deploy at scale. It finds certificates that network scanning misses — keystores, configuration files, embedded certificates in application code, and hardware-stored keys on IoT devices.

Cloud API integration. Query AWS Certificate Manager, Azure Key Vault, GCP Certificate Authority Service, and similar cloud-native certificate services for their managed inventories. These certificates are the easiest to enumerate and the ones most likely to already have metadata attached. Limitation: cloud-managed certificates are typically the best-managed certificates in your environment. The value of a cryptographic inventory is finding everything else.

The output of this exercise is a unified register that maps every machine identity to its issuing CA, its owning team, its deployment location, its expiration date, its key algorithm and length, and its current status. This register is the foundation of machine identity governance — without it, policies are unenforceable and automation has no scope.

What a Cryptographic Inventory Reveals

Organizations that complete their first comprehensive cryptographic inventory consistently discover the same categories of findings:

30-50% more certificates than expected. The gap between perceived and actual certificate count is typically in this range. The surplus comes from shadow CAs, forgotten test environments, cloud-managed certificates, and legacy infrastructure.

Certificates with no identifiable owner. In most enterprises, 15-25% of discovered certificates cannot be attributed to a team or individual. These are the highest-risk credentials: nobody is monitoring them, nobody will notice when they expire, and nobody will respond if they are compromised.

Active use of deprecated algorithms. SHA-1, RSA-1024, and other deprecated cryptographic parameters persist in production far longer than organizations assume. A cryptographic inventory is the only way to scope the migration effort to compliant algorithms.

Certificates issued by unknown CAs. The discovery exercise almost always finds certificates issued by CAs that the security team did not authorize. These may be legitimate (a cloud provider's managed CA) or concerning (a developer-provisioned CA in a container cluster). Either way, they represent trust anchors that were not evaluated or approved.

Overlapping and redundant certificates. Multiple certificates covering the same SANs, issued by different CAs, deployed on the same endpoints. This is a direct symptom of multi-team issuance without coordination.

From Inventory to Continuous Visibility

A point-in-time cryptographic inventory is necessary but insufficient. Certificates are issued, rotated, and deprecated continuously. A static inventory decays within weeks.

The target state is continuous machine identity visibility — an always-current register that updates as certificates are issued, discovered, rotated, and expired. This requires integrating the inventory with your issuance infrastructure (so new certificates are registered at creation), your monitoring infrastructure (so expiring certificates generate alerts), and your governance framework (so policy violations are detected in real time rather than during quarterly audits).

For organizations early in their machine identity management journey, the pragmatic sequence is: complete a point-in-time inventory, remediate the critical findings (ownerless certificates, deprecated algorithms, unknown CAs), then invest in the automation and integration required for continuous visibility.

The inventory is not the end state. It is the starting line.

FAQ

How do I estimate the size of my certificate sprawl problem? Start by counting known certificates across all teams and CAs. Then run a network scan of your IP ranges on common TLS ports (443, 8443, 636, etc.). The difference between the known count and the scan results is the minimum scope of your sprawl. The actual number is higher, because network scanning misses certificates that are stored but not actively serving.

What is the difference between a certificate inventory and a cryptographic inventory? A certificate inventory covers X.509 certificates. A cryptographic inventory is broader — it includes certificates, SSH keys, code signing credentials, encryption keys, and any other cryptographic material. A complete machine identity management program requires the broader scope, but most organizations start with certificates because they are the most operationally impactful.

Which certificates should be prioritized in a discovery exercise? Externally-facing certificates (public TLS endpoints) and certificates protecting critical infrastructure (authentication services, databases, inter-service communication). Also prioritize certificates issued by unknown or unauthorized CAs, as these represent uncontrolled trust in your environment.

How does certificate sprawl affect IoT environments? IoT devices often hold certificates provisioned at manufacturing time with no integration into enterprise certificate management platforms. These certificates may use hardware-bound key storage that cannot be remotely enumerated through standard scanning. IoT certificate sprawl is particularly dangerous because the remediation path — rotating credentials on constrained devices — is operationally expensive. For the hardware-level implementation of device identity that feeds into certificate sprawl at fleet scale, see the Hardware-Backed Device Identity guide. For environments using SPIFFE alongside traditional device PKI, certificate inventory must span both identity models — see SPIFFE & Workload Identity for Device Fleets.

Machine Identity Management — Machine Identity Governance — Hardware-Backed Device Identity — SPIFFE & Workload Identity — IoT Certificate Lifecycle. Contact Axelspire or Ask Axel.