TL;DR: GitGuardian reports that about one million unique private keys leaked across GitHub and DockerHub since 2021, with more than 40,000 mapped to 140,000 TLS certificates and 2,600 still valid as of September 2025. Certificate governance fails when leaked keys outlive ownership, revocation and attribution, leaving exposed trust material usable long after discovery.
At a glance
What this is: This research maps leaked private keys to real TLS certificates at internet scale and finds that exposed keys often remain valid long after public discovery.
Why it matters: It matters because certificate security is not just detection of leakage, but ownership, revocation, and cryptoperiod governance across machine identities and trust infrastructure.
By the numbers:
- Since 2021, GitGuardian detected about one million unique private keys leaked across GitHub and DockerHub.
- As of September 2025, 2,600 of the mapped certificates were still valid.
- GitGuardian sent 4,300 disclosure emails to 600 organizations, but only 54 responded.
👉 Read GitGuardian's analysis of private key leaks and certificate governance gaps
Context
Private key leakage becomes a governance problem when the exposed key can still authenticate a website, decrypt traffic, or be reused across certificate lifecycles. In this case, the security issue is not simply finding the leak. The harder problem is proving impact, identifying ownership, and getting the compromised trust material revoked.
For certificate-backed identities, the lifecycle spans issuance, ownership attribution, renewal, revocation, and reuse controls. When any of those steps is weak, a leaked private key can remain operational even after discovery, which is why this topic sits at the intersection of NHI governance and cryptographic trust management.
Key questions
Q: What breaks when a leaked private key is still tied to a valid certificate?
A: The trust model breaks because the exposed key can continue to authenticate a website or service even after the leak is known. Renewal alone does not remove the compromised trust path. Practitioners need to assume that the old key remains operational until revocation is confirmed and downstream dependencies no longer accept it.
Q: Why do leaked certificate keys remain risky after disclosure?
A: They remain risky because ownership is often unclear, revocation is slow, and replacement certificates do not automatically invalidate the original key. If the key is still accepted anywhere in the trust ecosystem, an attacker can keep using it to impersonate the service or decrypt traffic.
Q: How should teams measure whether certificate revocation is actually working?
A: Teams should measure the time from exposure detection to confirmed revocation, the percentage of leaked keys mapped to owners, and the share of certificates that remain valid after disclosure. If exposed material stays valid for weeks, the revocation process is failing in practice.
Q: Should organisations rotate private keys before or after certificate renewal?
A: They should rotate keys before renewal whenever possible, and they should not rely on renewal to clean up exposure. If the old key remains valid, renewal only adds another certificate to the estate while leaving the compromised trust material in place.
Technical breakdown
Why leaked private keys are harder to govern than API keys
A private key is not inherently tied to one service in the way many API keys are. The same key material can support SSH authentication, JWT signing, TLS server identity, or other cryptographic functions, so attribution is a separate governance task. That creates a key management problem: the organisation must first determine what the key controls before it can assess blast radius. In X.509 usage, the private key is the trust anchor behind the certificate, which means exposure can translate directly into impersonation risk, traffic interception, or retroactive decryption when perfect forward secrecy is not in place.
Practical implication: Treat leaked private keys as attribution and trust incidents, not just secret scanning findings.
How certificate transparency helps, and where it still falls short
Certificate Transparency is a public log system for issued certificates, designed to make certificate issuance observable. In theory, that makes it possible to map a leaked private key to the certificates that reference its public key. In practice, CT is only one part of the puzzle because certificates expire, logs can be retired, and historical reconstruction becomes difficult once data ages out. The article shows that large-scale correlation requires combining secret detection, CT querying, and additional attribution methods such as domain extraction and OSINT when certificate metadata is sparse.
Practical implication: Use CT as an investigation layer, but build separate owner and revocation workflows because CT alone does not restore accountability.
Why revocation often fails after private key exposure
Revocation is supposed to remove trust from a compromised certificate, but the article shows that operational revocation frequently lags discovery. Some certificates remain valid after disclosure because owners do not respond, do not understand the impact, or rely on renewal instead of revocation. That creates a dangerous false recovery pattern: issuing a replacement certificate does not neutralise the old private key. If the original key remains accepted somewhere in the ecosystem, the compromise window stays open even after the organisation believes it has moved on.
Practical implication: Link revocation to the original key leak, not to certificate renewal, so the compromised trust path is actually removed.
Threat narrative
Attacker objective: Use exposed private key material to impersonate trusted services or preserve access to encrypted communications through valid certificates.
- Entry occurs when a private key is exposed in public repositories or container images and later discovered by researchers or attackers.
- Credential access follows when the leaked key is mapped to a live TLS certificate or other certificate-backed trust relationship.
- Escalation occurs when the same key can be used to impersonate a website, intercept traffic, or decrypt communications that still rely on that trust path.
- Impact is persistence of usable trust after disclosure, because unrevoked certificates can remain valid for months or longer.
Breaches seen in the wild
- PyPI secrets exposure 2023: Researchers found 3,938 unique secrets in published PyPI packages, 768 still valid; a new release or yank does not remove them.
- Twitch breach 2021: A server misconfiguration leaked Twitch source code and payouts; the repositories held nearly 6,600 secrets, including 194 AWS keys.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Private key leakage is a certificate governance failure, not a detection problem. The article shows that finding exposed keys is often easier than proving what they still control. That shifts the real control point to ownership attribution, certificate linkage, and revocation execution. For identity programmes, the lesson is that discovery without lifecycle closure leaves trust material live.
Certificate-backed identities need lifecycle discipline comparable to NHI governance. A leaked private key is not useful only because it exists. It is dangerous because it can remain valid across renewals, owners, and infrastructure changes. That makes cryptoperiod management, reuse prevention, and revocation coordination core governance duties, not optional hygiene.
Private key reuse creates identity blast radius that spans multiple certificates and organisations. The same key material can underlie many live certificates, which means one leak can propagate into many trust relationships. The implication is that governance cannot be certificate-by-certificate alone; it must also track key reuse and ownership continuity across the estate.
Certificate Transparency improves visibility but does not solve accountability. Public logs make correlation possible, yet the article still required extensive attribution work, simulated validation, and direct contact with certificate authorities. That is a strong signal that technical observability is not the same as operational responsibility, and practitioners must design for both.
Cryptoperiod discipline is the named control gap this research exposes. Private keys outliving certificates, or being reused across renewals, is the assumption that fails here. That assumption was designed for environments where keys remain under stable ownership and revocation is reliably executed. The implication is that certificate governance must stop treating renewal as remediation.
From our research library:
- 48% of organisations cite cloud-based services as a driver for PKI deployment, according to the 2023 State of Machine Identity Management report.
What this signals
Identity blast radius now includes cryptographic trust paths. Leaked private keys show that identity governance cannot stop at secrets inventory. It has to cover what the key still authenticates, which certificates it supports, and whether the old trust path is still accepted anywhere in production.
Renewal is not remediation. When certificate governance equates a new certificate with a resolved incident, the old private key may still be live in browsers, services, or network paths. Programmes should treat revocation confirmation as the control outcome, not certificate replacement.
Certificate lifecycle controls need ownership data as much as cryptography. If the organisation cannot tie a key to a system owner, it cannot revoke with confidence or report exposure accurately. That makes inventory quality a security control, not a recordkeeping exercise.
For practitioners
- Tighten private key cryptoperiods Set private keys to expire with or before the certificates they support, and prohibit long-lived reuse across renewal cycles. Where feasible, move to single-use keys for high-trust certificates so compromise windows do not persist across multiple issuance events.
- Build key-to-certificate inventory Maintain an inventory that links private keys, certificate serials, domains, and owners so exposure can be assessed quickly. Without that mapping, response teams spend more time attributing the asset than containing the exposure.
- Separate renewal from revocation Require explicit revocation when a private key is exposed, even if a replacement certificate has already been issued. Renewal does not invalidate the old trust path, so the original key must be removed from acceptance wherever it still exists.
- Test CA and owner response paths Run disclosure drills that measure how quickly owners, certificate authorities, and internal responders act once a leaked key is identified. The goal is to prove that your revocation path works before a real exposure forces it to.
Key takeaways
- Leaked private keys create a trust problem that extends well beyond secret detection, because the same key can continue to validate live certificates.
- The research shows that visibility alone does not close risk when owners do not respond quickly and revocation does not happen.
- The most effective control is shorter cryptoperiods with enforced revocation and no reuse of compromised key material.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5, NIST CSF 2.0 and NIST SP 800-57 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | The article centres on exposed private keys leaking into public repositories and images. |
| NHI-07 — Long-Lived Secrets | The core failure is private keys remaining valid long after public exposure. | |
| NHI-09 — NHI Reuse | The article shows how one key can map to many certificates across time and ownership. | |
| Recommendation — Scan for leaked private keys and revoke any exposed certificate-backed credentials immediately. Shorten key lifetimes so leaked private keys expire before attackers can reuse them. Eliminate key reuse across renewals and certificate replacements to reduce blast radius. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Private key lifecycle and rotation fall squarely within authenticator management. |
| Recommendation — Apply IA-5 to enforce rotation, revocation, and expiration of certificate private keys. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about which trust paths remain authorised after key exposure. |
| Recommendation — Review authorisation boundaries for certificate-backed identities and remove stale trust paths. | ||
| MITRE ATT&CK | TA0006;TA0040 — Credential Access; Impact | Leaked private keys provide credential access that can lead to impersonation and traffic interception. |
| Recommendation — Map exposed private keys to credential access and impact scenarios in your threat model. | ||
| NIST SP 800-57 | Part 1 — Key Management Lifecycle | The topic is fundamentally about cryptoperiods, reuse, and revocation across the key lifecycle. |
| Recommendation — Use key lifecycle governance to bound cryptoperiods and retire compromised keys quickly. | ||
Key terms
- Private Key Exfiltration: Private key exfiltration is the unauthorized removal of cryptographic keys from an application, wallet, or system. It is especially dangerous because a private key can be used to control assets, sign transactions, or impersonate a trusted identity, making theft immediate and often irreversible.
- Certificate Transparency: Certificate Transparency is a public logging system for certificates issued by major certificate authorities. It helps investigators link public keys to issued certificates, but it is a discovery layer, not a remediation control, and it does not revoke compromised material by itself.
- Cryptoperiod: A cryptoperiod is the period for which a cryptographic key is considered valid and in use. Shorter cryptoperiods reduce the time an exposed key can be abused, and they are central to limiting blast radius when certificate or signing keys leak.
- Certificate Revocation List: A Certificate Revocation List is a signed publication from a certificate authority that lists certificates that are no longer trusted before their natural expiry. It is used by relying systems to confirm current status, and it becomes operationally useful only when the list is reachable, current, and readable by the consuming toolchain.
What's in the full report
GitGuardian's full analysis covers the operational detail this post intentionally leaves for the source:
- The certificate mapping method that links leaked private keys to real TLS certificates at internet scale
- The attribution workflow used to identify certificate owners when certificate metadata was missing
- The revocation outcomes across certificate authorities, owners, and response channels
- The validation approach used to distinguish active exposure from historical leakage
Deepen your knowledge
NHI governance, machine identity security, and secrets management are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building or maturing an IAM or certificate governance programme, it is worth exploring.
Published by the NHIMG editorial team on May 30, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org