# When the Root Gets Pulled, Nobody Knows What They Have
The revocation notice goes out at 2 AM. A root CA is distrusted by the major browser vendors — maybe it was compromised, maybe it violated baseline requirements, maybe it got caught issuing certs for domains it had no business signing. The security team wakes up to a Slack storm. Prod services are throwing TLS errors. Monitoring is broken. An internal dev tool nobody touched in three years is paging on-call engineers who don't even know what it does.
The question "what certificates do we have, and where do they live?" should have been answerable in seconds. Instead, it takes four people two days to produce a partial list that everyone immediately doubts.
This scenario isn't hypothetical. It's the organizational reality behind every major CA distrust event — and the industry is overdue for an honest reckoning with why certificate visibility remains such a persistent, catastrophic blind spot.
## The Sprawl Nobody Planned For
A decade ago, a mid-size enterprise might have had a few dozen TLS certificates — mostly external-facing, managed by one team, renewals on a spreadsheet. The attack surface was legible.
Then came the explosion. Cloud infrastructure that spins up services with auto-generated certs. Container orchestration platforms where every service mesh component negotiates mutual TLS. CI/CD pipelines with code-signing certificates. IoT devices shipped with factory-embedded certificates that no one can rotate. Internal CAs stood up by three different teams, none of whom told each other. SaaS platforms that use their own intermediate CAs under a corporate root.
The average enterprise now operates with thousands of certificates across systems, vendors, and environments. A significant portion of those certs are unknown to the security team. Not "undocumented" — literally unknown. No one in the organization could tell you they exist.
This is the condition called certificate sprawl, and it means that when a root gets distrusted, the blast radius is genuinely unknown until the errors start flowing.
## DigiNotar Is Still Happening, Just Slower
The DigiNotar collapse in 2011 was the industry's sharpest lesson in what root-of-trust failure looks like at full velocity. The Dutch CA was compromised, issued fraudulent certs for Google domains, and was subsequently distrusted by every major browser and OS vendor within weeks. Organizations that relied on DigiNotar certificates discovered their dependencies the hard way — when things broke.
More than a decade later, the lesson hasn't fully landed. The Symantec distrust process, which Google and Mozilla began in 2017 and completed through 2018, was slower — months of notice, phased deadlines — and still caught enterprises off guard. Internal tooling, legacy applications, and embedded systems that shipped with Symantec-anchored certificate chains simply stopped working when the deadline passed.
The common thread isn't the CA's failure. It's the fact that enterprises couldn't answer the basic question: *which of our systems trust this root?*
## What "Owning" a Certificate Actually Means
The title of this piece gets at something real about organizational dysfunction. In most companies, certificates exist in a weird ownership vacuum.
The platform team issues them. The application team deploys them. The security team audits them in theory. Nobody has clear accountability for monitoring expiry, tracking what's in rotation, or maintaining a living map of what trusts what.
This becomes especially acute with intermediate CAs and private PKI. A team spins up a Vault PKI backend to issue short-lived certificates for a microservices environment. Smart choice, operationally. But who owns the root that intermediate sits under? Who rotates it? Who gets paged when it's six months from expiry? What happens to the services that trust it when the rotation breaks the chain?
These aren't edge-case problems. They're the mundane operational reality of modern infrastructure, and they don't have clean answers without active inventory management.
## The Post-Quantum Problem Is About to Make This Worse
Here's the part that doesn't get enough coverage: the migration to post-quantum cryptography — specifically the NIST-standardized algorithms like ML-KEM and ML-DSA — requires not just algorithm updates but, in many cases, new roots of trust. The certificate ecosystem is going to experience coordinated root transitions at a scale the industry hasn't seen since the SHA-1 deprecation.
NIST's finalized PQC standards landed in 2024. Browser vendors and CA/Browser Forum members are already in early planning stages for hybrid certificate support. The timelines are longer than SHA-1 — we're probably looking at a multi-year migration window — but the underlying challenge is identical: organizations that can't enumerate their certificate dependencies today will not be able to manage a coordinated root rotation in five years.
The difference is that PQC migration isn't optional. Harvest-now-decrypt-later attacks mean that adversaries are already capturing encrypted traffic to decrypt once quantum capability matures. The window to migrate isn't infinite.
Organizations that don't build the inventory now will be doing it under emergency conditions.
## HackWire Analysis
The certificate inventory problem is one of those security recommendations that everyone agrees with and almost nobody implements seriously. It ends up on audit findings, in penetration test reports, in security architecture reviews — and then gets deprioritized because there's no immediate incident forcing action.
The timing argument for building this now is stronger than it's ever been, for three reasons that rarely get connected in the same piece.
First, Let's Encrypt's ISRG Root X1 is approaching its own deprecation horizon for older Android devices — the trust store fragmentation problem isn't solved, it's ongoing. Second, the post-quantum transition is going to require root changes across every organization's PKI, public and private. Third, the expansion of machine identity — the sheer number of non-human identities that now authenticate via certificates in modern cloud-native environments — means the surface area for a trust failure is orders of magnitude larger than it was during the DigiNotar era.
What other coverage is missing: the IoT angle. Embedded devices shipped with hardcoded root trust stores cannot be updated over the air in most deployments. If a root they trust gets distrusted, those devices break permanently or fall back to insecure states. For industrial OT environments, medical devices, and consumer IoT at scale, this isn't a future risk — it's a live exposure right now. The certificate inventory problem for IoT is arguably harder than the enterprise IT version, and it gets almost no attention until something breaks.
For defenders: start with the most connected systems first. External TLS, code-signing infrastructure, and any service mesh using mTLS. The goal isn't perfection on day one — it's having a living inventory you can actually query when the 2 AM page comes in.
The teams that know what they have are the ones who can actually respond. Everyone else is just waiting to find out.
— HackWire Editorial
---
## Related Coverage