Ghost Certificates: The Risk of Certificates Nobody Knows Exist
There's a certificate in your infrastructure right now that you don't know exists. It was issued two years ago by someone who has since left the company, it points to a load balancer that was never documented, and it will expire on a date that's on no calendar anywhere. You'll only find out it existed the day it breaks something.
This is the problem of ghost certificates — and it's not a hypothetical scenario. It's the root cause of some of the largest security and availability incidents ever documented. What almost all of them have in common isn't technical sophistication: it's that nobody knew the certificate was there.
Why certificates fall off the radar
Certificates don't vanish through one person's negligence. They vanish through structural features of how infrastructure grows:
- Team turnover. Whoever issued the certificate left, and the knowledge about it left with them. There's no formal handover of "certificates I manage."
- Decentralized issuance. Any team with access to a CA — or to Let's Encrypt — can issue a certificate without going through a central process. Certificates issued outside approved processes go undetected, widening the attack surface and creating compliance gaps that auditors flag.
- Hybrid environments. Certificates scattered across on-premise, cloud, and hybrid environments remain untracked, creating dangerous blind spots that trigger unexpected outages.
- Sheer scale. Inventory grows faster than governance. The average enterprise now manages over 250,000 machine identities, up from roughly 150,000 just two years ago. A spreadsheet can't keep up with that volume.
The result is what the industry calls certificate sprawl: too many certificates, spread across too many places, owned by no one in particular.
The real cost: this isn't a niche problem
Certificate failure isn't a rare edge case. It's a recurring line item in enterprise incident logs. Keyfactor's 2026 State of Machine Identity research found that over 70% of organizations experienced at least one certificate-related outage in the past year, that it typically takes more than four hours to identify, remediate, and recover from one, and that a single incident commonly pulls in 11 to 20 people across security, infrastructure, and application teams before it's resolved.
The financial cost is significant. Outages caused by certificate expiry cost enterprises between $500,000 and $5 million on average per incident, and take over five hours to identify and remediate.
And it isn't just small or poorly resourced companies. The list of who's been hit is telling:
- Spotify: an expired certificate caused an outage on Megaphone, the company's podcast platform.
- LinkedIn: the expiry of a country subdomain certificate affected the accessibility and security of its services.
- Microsoft Teams: suffered a widely reported outage in February 2020, attributed to an expired certificate, that disrupted meetings for users.
- US Government: 80 certificates expired, rendering many government websites inaccessible.
The most revealing finding comes from analyzing those incident reviews: the certificate was almost never unknown — it just wasn't anyone's clearly assigned job to renew it.
When a ghost certificate becomes a security breach: the Equifax case
The definitive example of why discovery matters isn't an outage. It's one of the largest data breaches in history.
In 2017, attackers entered Equifax's network through a known Apache Struts vulnerability. That alone would have been contained — if traffic monitoring had been working. It wasn't. The device used to monitor the ACIS application's network traffic had been inactive for 19 months due to an expired security certificate.
The mechanism is precise and chilling: the monitoring tools were supposed to decrypt and inspect traffic leaving the network, but without a valid certificate they couldn't. The attackers' encrypted exfiltration looked like normal HTTPS traffic. The attackers operated inside the network for 76 days, unseen.
What happened when the certificate was finally renewed is the entire lesson in one sentence: on July 29, 2017, Equifax updated the expired certificate and immediately noticed suspicious web traffic. Monitoring could see again the exact moment the certificate was fixed — far too late.
And the expired certificate wasn't an isolated case. At the time of the breach, Equifax had allowed over 300 security certificates to expire, including 79 certificates monitoring business-critical domains. The breach affected roughly 147.9 million people and resulted in the largest data breach settlement in US history at the time, between $575 and $700 million.
A certificate nobody was monitoring blinded the very system built to detect the attack.
The aggravating factor on its way: SC-081
If managing unknown certificates is already hard today, the math is about to get worse. With the CA/Browser Forum's SC-081 ballot, the maximum validity of public TLS certificates drops to 47 days by 2029. With validity dropping to 47 days in March 2029, manual renewal processes will collapse under the volume, making automation non-negotiable.
Every ghost certificate that expires once a year today will start expiring roughly eight times a year. An incomplete inventory, already an annual risk, becomes a nearly monthly one.
Why discovery is the prerequisite for everything
Here's the principle that ties all these cases together: you can't renew, automate, monitor, or protect a certificate you don't know exists. Any certificate management strategy that starts with renewal or automation is building on a cracked foundation, because it covers only the certificates already known — which are never all of them.
Discovery is step zero. And effective discovery needs to cover the places where the ghosts hide:
Multiple sources, not just one. A certificate might live on an on-premise server, a load balancer, a cloud bucket, or be visible only in Certificate Transparency logs. Discovering only what's in one source means staying blind to the others.
Active network scanning. Scanning the infrastructure's TLS ports (443, 8443, and others) reveals certificates actually in use that aren't in any inventory — including the ones pointing to that undocumented load balancer.
CT logs. Certificate Transparency logs publicly record certificates issued for your domains. Querying them reveals issuance that happened outside your process — including unauthorized issuance.
Continuous discovery, not one-off. An inventory taken once is out of date the next day. New certificates are issued all the time. Discovery needs to be a recurring process, with delta detection — what's appeared since the last scan.
From discovery to action. Discovering a certificate is only valuable if it feeds the next step: expiry monitoring, automated renewal, and deployment. Discovery that produces a static list nobody acts on is just documentation of the problem, not a solution.
The value of good discovery is measured by how fast it turns "we didn't know that existed" into "that's under control." When that cycle takes 15 minutes instead of 19 months, the ghost certificate stops being a time bomb and becomes just another managed item.
This is a sensitive topic when it involves real security incidents. The cases cited are public knowledge and serve to illustrate the operational risks of certificate management.
Frequently asked questions
How can a certificate exist without anyone knowing?
Through how infrastructure grows: team turnover takes the knowledge away, decentralized issuance lets anyone create a certificate outside a central process, and hybrid environments scatter certificates across on-premise, cloud, and multiple servers. Without continuous discovery, the inventory reflects only what someone remembered to write down — which is never the total.
What's the difference between monitoring and discovering certificates?
Monitoring tracks the expiry of certificates you already know about. Discovery finds the certificates you don't know about. Monitoring without discovery creates a false sense of security: you carefully watch a list that's incomplete. The most serious incidents almost always involve certificates that weren't being monitored because nobody knew they existed.
Do Certificate Transparency logs help find internal certificates?
No. CT logs record publicly trusted certificates issued for your domains, which is excellent for detecting public issuance outside your process (including unauthorized issuance). But internal PKI certificates, issued by a private CA, don't appear in CT logs — for those, you depend on network scanning and discovery across cloud and servers.
Why does discovery become more urgent with SC-081?
Because validity dropping to 47 days multiplies renewal events by roughly eight per year. An unknown certificate that represents an annual risk today will represent a nearly monthly one. Without a complete and continuous inventory, the odds of an expiry slipping through unnoticed grow in the same proportion.
See the technical documentation
Integration guides, API and automation at docs.pkiless.com.
Automate your certificate lifecycle
Discovery, renewal and deployment automated — ready for 47-day validity.
Try PKILESS for free