Private key leaks expose certificate governance gaps at internet scale

At a glance

What this is: This is an analysis of leaked private keys and their real-world TLS certificate impact, showing that many exposed keys still map to valid certificates and remain operationally dangerous.

Why it matters: For IAM and NHI practitioners, it shows that secret discovery alone is insufficient when certificate ownership, revocation, and key reuse are slow or incomplete.

By the numbers:

• Since 2021, GitGuardian has detected about one million unique private keys leaked across GitHub and DockerHub.
• As of September 2025, 2,600 of the mapped certificates were valid.
• GitGuardian sent 4,300 disclosure emails to 600 organisations, but only 54 responded.

👉 Read GitGuardian's analysis of leaked private keys and TLS certificate risk

Context

Private key leaks are an identity and trust problem, not just a secret exposure problem. A leaked private key can authenticate a website, sign assertions, or decrypt traffic depending on where it is used, which makes certificate lifecycle control central to NHI governance.

This research matters because it shows how weak ownership tracking and slow revocation turn a single secret leak into a long-lived exposure. For IAM teams, the challenge is not only finding secrets, but proving which certificates still matter, who can revoke them, and whether reused keys have created hidden blast radius.

The starting position described here is typical of the broader industry, not an outlier. Many organisations can detect leaked material faster than they can attribute it, verify impact, and complete revocation across owners and authorities.

Key questions

Q: How should security teams respond when a private key leaks publicly?

A: Treat the leak as an active trust incident, not just a secret exposure. Identify every certificate, service, or signing flow that depends on the key, then rotate the key and revoke the affected certificate as one workflow. The fastest control is a short cryptoperiod combined with clear ownership and automated revocation.

Q: Why do leaked private keys remain dangerous after discovery?

A: Because the key may still map to valid certificates or signing systems, and those trust relationships can survive the original leak for months. If renewal happens without key rotation, the compromised material may remain usable even after the organisation thinks the issue is closed. Discovery does not end exposure; lifecycle control does.

Q: What is the difference between scanning for secrets and managing certificate risk?

A: Secret scanning tells you a key exists in a repository or image, while certificate risk management tells you whether that key still authenticates something important. The first is detection, the second is impact analysis and revocation. For TLS environments, both are needed because a leaked key can remain valid long after it is exposed.

Q: Should organisations reuse private keys across certificate renewals?

A: No. Reusing private keys extends the life of a compromise and increases the blast radius if the key is ever exposed. A safer model is to generate new keys with each renewal or use a single-use rotation pattern where the private key never outlives the certificate it supports.

Technical breakdown

Why leaked private keys are harder to attribute than API keys

A private key is a mathematical object that can be used in several identity systems, including SSH, JWT signing, and X.509 TLS certificates. That makes first-pass secret scanners useful for detection but weak for impact assessment. Once a key leaves a repository or container image, the security question becomes contextual: what public material matches that key, where is it trusted, and what traffic or assertions can it sign? In certificate ecosystems, the same private key may be reused across renewals, which extends exposure far beyond the original leak event.

Practical implication: Build attribution workflows that map leaked keys to their dependent certificates and services before deciding on remediation priority.

How certificate transparency helps, and where it still breaks down

Certificate Transparency creates a public record of issued certificates, which allows researchers to match a leaked private key to the corresponding certificate using public key hashes. That makes CT powerful for scale analysis, but it is not a perfect historical source. Logs can be retired, storage is massive, and some certificates disappear from easy access once they expire. For security teams, that means attribution may require both online validation and simulated TLS checks, especially when trying to prove whether a leaked key was still valid at the time of exposure.

Practical implication: Treat CT as an investigation tool, then supplement it with direct validation and revocation checks before concluding that risk is gone.

Why revocation fails in practice even when compromise is confirmed

Revocation should be the final control after key exposure, but it often depends on proving ownership with the leaked key itself. That creates an awkward operational loop, because the same artefact that exposes the system is also the proof needed to correct it. The result is that many certificates remain valid after disclosure, and reissuing a certificate without revoking the old one leaves the compromised material alive. This is a lifecycle failure: discovery, attribution, and revocation are not connected tightly enough to shorten the attack window.

Practical implication: Automate certificate revocation, renewal, and key replacement as one workflow rather than three separate manual tasks.

Threat narrative

Attacker objective: The attacker aims to impersonate trusted infrastructure or intercept protected communications using a leaked certificate key.

1. Entry occurs when a private key is exposed in a public repository or container image and later matched to a live certificate.
2. Escalation happens when the same key can be used to impersonate a trusted site, sign assertions, or decrypt traffic on the right network path.
3. Impact is sustained trust abuse, because the compromised certificate can remain valid long after the original leak and may not be revoked promptly.

Breaches seen in the wild

• Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
• Sisense breach — unauthorized GitLab access led to exfiltration of access tokens, API keys and certificates.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Private key leakage is a certificate governance problem disguised as secrets hygiene. Detection alone does not answer the operational question that matters: which keys still map to active trust relationships, and who can revoke them. In practice, organisations often have better visibility into code repositories than into certificate usage, renewal timing, and key reuse. Practitioners should treat leaked keys as live identity artefacts until the associated certificates are confirmed dead.

Identity blast radius is the right concept for leaked keys in TLS environments. One exposed private key can affect multiple services if certificates are renewed without rotating the underlying key, and that expands the real blast radius beyond the original leak source. The industry still underestimates how often revocation lags behind exposure. Security teams should measure blast radius by trust dependency, not by repository location.

Certificate Transparency improves attribution, but it does not replace lifecycle control. The value of CT is investigative scale, not remediation by itself. If certificates remain valid after the key leak, then logging and monitoring have only documented the problem. Practitioners should use CT to accelerate discovery, then bind it to revocation automation, ownership data, and renewal policy.

Single-use and short-lived keys should become the default assumption for high-trust systems. Long cryptoperiods create standing exposure, especially when the same key survives multiple certificate renewals. The research supports a stricter lifecycle model where keys do not outlive certificates and are rotated as part of standard issuance. Practitioners should move toward key use patterns that minimise reuse and shorten trust duration.

Ownership ambiguity is now a security control gap, not an administrative inconvenience. The fact that many certificates could not be traced cleanly to an owner shows that attribution metadata is part of trust governance. Without clear ownership, response time stretches and revocation stalls. Practitioners should treat owner identity, certificate inventory, and revocation authority as a single control surface.

From our research:

• 4.6% of all public GitHub repositories contain at least one hardcoded secret, according to The Secret Sprawl Challenge.
• 15% of commit authors have leaked at least one secret in their contribution history, which shows how routine exposure can become a repeat identity risk.
• For the remediation side of the problem, see The 52 NHI breaches Report for how exposed credentials turn into real-world compromise paths.

What this signals

Certificate lifecycle has become part of identity governance, not a narrow PKI task. Teams that separate secret detection from revocation will continue to carry hidden exposure, because leaked keys can remain trusted after they are found. The practical shift is to treat certificates, owners, and renewal events as one governed lifecycle rather than three disconnected processes.

The programme-level signal is clear. Organisations that cannot answer who owns a certificate, where it is used, and how fast it can be revoked will not be able to shrink exposure windows reliably. That is especially true when key reuse stretches the useful life of a leak beyond the initial incident.

With 4.6% of public GitHub repositories containing at least one hardcoded secret, per The Secret Sprawl Challenge, the issue is not rarity but operational volume. The control response needs to be inventory, ownership, and lifecycle automation, not manual cleanup campaigns.

For practitioners

• Map leaked keys to certificate inventories Correlate repository and image secret scanning with certificate transparency data so you can identify which leaked private keys still map to active TLS certificates.
• Shorten cryptoperiods for high-trust certificates Reduce key lifetime and require rotation at renewal so private keys do not survive multiple certificate cycles.
• Automate revocation as part of renewal workflows Link issuance, replacement, and revocation so a discovered leak triggers one coordinated response instead of a manual chain of tickets.
• Enforce ownership metadata for every certificate Require an accountable owner, an approver, and a revocation path for each certificate so attribution does not depend on ad hoc investigation.

Key takeaways

• Leaked private keys become identity incidents when they map to active certificates or signing systems.
• Attribution and revocation lag are the main reasons exposed keys remain dangerous after discovery.
• Short cryptoperiods, new keys on renewal, and automated revocation are the controls that actually reduce blast radius.

Key terms

• Private Key: A private key is the secret half of an asymmetric cryptographic pair used to prove identity or sign data. In operational environments it can authenticate services, sign tokens, or decrypt traffic, which makes exposure a trust failure, not just a confidentiality issue.
• 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: Certificate revocation is the process of invalidating a certificate before its scheduled expiry. In practice it is often slowed by ownership checks, manual workflows, and authority-specific processes, so it must be paired with lifecycle automation if exposure is to be reduced quickly.

What's in the full report

GitGuardian's full research covers the operational detail this post intentionally leaves for the source:

• The certificate transparency mapping method used to link leaked private keys to real TLS certificates.
• The disclosure and revocation workflow, including how GitGuardian contacted organisations and certificate authorities.
• The simulated TLS validation approach used for certificates that could not be confirmed online.
• The remediation outcomes across different ownership types, including organisations, CAs, and government entities.

👉 GitGuardian's full post covers the mapping method, disclosure workflow, and revocation outcomes in detail.

Deepen your knowledge

Private key lifecycle governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are trying to turn secret discovery into dependable revocation, the course is worth exploring.