There is a moment that most security teams dread, and it does not arrive with fanfare. It arrives at 11:47 on a Tuesday night when a monitoring alert fires, a customer-facing application goes dark, and someone has to find out which certificate expired and where it lived. The scramble that follows is not a sign of incompetence. It is a symptom of a problem that has been quietly growing for years: nobody actually knows how many certificates they have.

This is certificate sprawl. And it has become one of the most underestimated risks in enterprise security today.

The Problem That Grew While Nobody Was Looking

Cast your mind back to the early years of corporate IT. Before cloud, before DevOps pipelines, before containerisation. Back then, shadow IT meant employees signing up for Dropbox because the internal file share was too slow. Security teams spent years building policies to bring unsanctioned tools back under control, deploying agent-based discovery tools, and trying to get ahead of the risk.

Certificate sprawl is the same phenomenon, just wearing a different disguise.

Over the past decade, the number of digital certificates an average enterprise manages has grown dramatically. TLS certificates for public-facing web applications. Certificates for internal services communicating over HTTPS. Code signing certificates. Client authentication certificates. Certificates embedded in IoT devices, in containers, in load balancers, in API gateways. Every team that spun up a new microservice or migrated a workload to a new cloud provider likely provisioned certificates along the way, often outside any formal request process.

The result is an environment where certificates exist that nobody documented, nobody inventoried, and in some cases nobody still at the company even knows about. They sit quietly in infrastructure, doing their job, until one day they do not.

Why Certificates Are Harder to Track Than Applications

With shadow IT applications, there is usually a paper trail. A purchase on a corporate card. A domain registered somewhere. An OAuth permission showing up in an audit log. Certificates are different. They can be generated in minutes, often at no cost, and deployed directly onto infrastructure without going through procurement, change management, or security review.

A developer spinning up a test environment and grabbing a Let’s Encrypt certificate for it has done nothing wrong. But if that environment later gets promoted to production and the developer moves on to another role, the certificate is now an orphan. It exists. It will expire. Nobody is watching it.

Multiply this across a large enterprise with hundreds of developers, dozens of cloud accounts, and years of accumulated infrastructure, and you start to understand the scale of the problem. Research from the industry consistently shows that the majority of organisations significantly undercount their certificate inventory. The numbers people think they have are almost always lower than the numbers that actually exist.

The Risk Is Not Theoretical

Let us be direct about what certificate sprawl actually costs when it goes unmanaged.

Expired certificates cause outages. This is not speculation. Some of the most disruptive service interruptions at major technology companies and financial institutions in recent years trace back to certificates that nobody knew were about to expire. The Microsoft Teams outage in 2020. The Azure DevOps disruption in 2023. These were not exotic attacks. They were the predictable consequence of operating at scale without adequate certificate visibility.

Beyond outages, there is a quieter risk: certificates that are still valid but should not be. Certificates provisioned for systems that were decommissioned but never formally cleaned up. Certificates with weak key lengths that were issued years ago and never rotated. Certificates granted to third-party vendors who no longer have a relationship with your organisation. Each one represents an exposure that is impossible to close if you do not know it exists.

And for organisations in regulated industries, the compliance dimension adds another layer of pressure. Frameworks like PCI-DSS, ISO 27001, and DORA require demonstrable control over cryptographic assets. If an auditor asks for your certificate inventory and your answer is a partial spreadsheet that someone updates when they remember to, you are not in a good place.

Discovery Has to Come First

This is where most conversations about Certificate Lifecycle Management begin in the wrong place.

Organisations often approach CLM as a renewal automation problem. They look for tools that can automatically trigger certificate renewals before expiry, which is genuinely valuable. But automation without visibility is dangerous. If you automate renewals for the certificates you know about, you have not solved the problem. You have simply built a faster system on top of an incomplete foundation.

Discovery has to come first.

That means actively scanning your environment — your cloud accounts, your on-premises infrastructure, your network ranges, your code repositories, your secrets managers — to build a comprehensive picture of every certificate that exists. Not the certificates you think you issued. Every certificate that is actually present in your environment right now.

This is not a one-time exercise. Certificates are provisioned constantly. New services come online. Environments are cloned. The inventory has to be maintained continuously, not audited annually.

What Mature Certificate Lifecycle Management Actually Looks Like

Organisations that have moved past the sprawl problem tend to describe a similar journey. It starts with a discovery phase that surfaces significantly more certificates than anyone expected. That initial count is often uncomfortable. But knowing is always better than not knowing.

From there, the work is about bringing certificates under a consistent management framework. Every certificate in the environment should have a known owner, a known expiry date, a known renewal process, and a known deployment target. That level of governance is not bureaucracy for its own sake. It is what allows a security team to sleep at night, confident that they will not be woken up by an expiry that blindsided them.

Automation then handles the operational load: triggering renewals at the right time, handling domain control validation, pushing certificates to the right endpoints, and confirming successful deployment. But none of that automation is trustworthy if it is working from an incomplete inventory.

The Question Worth Sitting With

Here is what we have seen again and again when organisations first go through a proper certificate discovery process: the number is always higher than expected. Always.

If your organisation has never run a comprehensive certificate discovery exercise, you almost certainly have certificates in your environment that you are not tracking. Some of them are fine. Some of them are approaching expiry right now. A handful of them may represent exposures you would want to know about.

The question is not whether certificate sprawl affects your organisation. For enterprises of any meaningful size, it does. The question is whether you find out on your own terms, or whether an outage, an audit finding, or a security incident makes the discovery for you. If shorter certificate lifespans are already a concern, our breakdown of why 47-day TLS certificates will break most enterprises explains why the pressure on certificate management is only going to increase.

Sixscape helps organisations begin with discovery and build outward from there, establishing the complete visibility that makes every other aspect of certificate lifecycle management actually work. If you are ready to find out what is really in your environment, we are ready to help you look.