Verizon DBIR shows leaked secrets still drive NHI compromise

TL;DR: Verizon’s 2025 DBIR says public repositories still expose 441,000 secrets, with JWTs and GitLab tokens dominating the mix and a median 94-day remediation window giving attackers time to exploit them. The case for tighter NHI secret governance is no longer theoretical, because exposure and dwell time now move faster than manual control.

At a glance

What this is: Verizon’s 2025 DBIR shows that leaked secrets, especially JWTs and GitLab tokens, remain a primary path into cloud and development environments.

Why it matters: For IAM and NHI teams, the report reinforces that secret exposure is not a hygiene issue alone. It is an access-control failure that can bypass MFA and accelerate lateral movement.

By the numbers:

• 94 days was the median time to remediate leaked secrets in public repositories.
• 39% of exposed secrets were web-app infrastructure secrets, and 66% of those were JWTs.
• 32% of exposed secrets were CI/CD and development tokens, with GitLab credentials making up half.

👉 Read Verizon's 2025 DBIR takeaways on secrets exposure and NHI risk

Context

Publicly exposed secrets turn routine development activity into an access-control problem, because a token in a repo, ticket, or log can behave like a standing credential. That matters for NHI governance because service identities, automation tokens, and API keys often carry privileges that outlast the people and workflows that created them.

Verizon’s data shows the issue is not a niche misconfiguration. The mix of JWTs, GitLab credentials, and other development tokens suggests that modern software delivery still produces high-value identities faster than teams can inventory and rotate them. That starting point is typical across enterprise environments, not an exception.

Key questions

Q: How should security teams handle leaked NHI secrets in public code?

A: They should treat every leaked secret as an active identity incident. Revoke or rotate the credential immediately, confirm what workloads depended on it, and verify that no parallel copies remain in tickets, logs, or chat tools. The goal is to reduce attacker usability, not just close the original leak.

Q: Why do exposed JWTs and API tokens create such high risk?

A: Because they often authenticate directly without user prompts or extra challenge. If the token has broad scope or long lifetime, an attacker can replay it against cloud services, build pipelines, or internal APIs and move quickly before defenders notice.

Q: What is the difference between secret rotation and secret revocation?

A: Rotation replaces a credential while keeping the service running, which is useful when the secret is still needed. Revocation makes the old credential unusable immediately, which is the right response when exposure is confirmed or suspected. In practice, exposed secrets usually need revocation first and rotation second.

Q: Should organisations prioritise reducing secret reuse over faster scanning?

A: Yes, because faster scanning only shortens detection time, while lower reuse reduces the blast radius of any one leak. If the same token serves multiple systems, exposure in one place can become compromise everywhere. The strongest programmes do both, but reuse reduction delivers the bigger structural gain.

Technical breakdown

Why exposed tokens create direct access, not just visibility risk

A leaked token is not the same as a leaked password, because it often represents a pre-authorised session or scoped API entitlement. JWTs can carry claims that validate access without additional user interaction, while CI/CD and development tokens frequently bridge source control, build systems, and cloud services. If those credentials are copied into public repositories, they can be replayed before revocation, especially when they are not tightly bound to device, workload, or short-lived context. For NHI governance, the key issue is that a secret is also an identity object with privileges, lifetime, and blast radius.

Practical implication: Treat exposed secrets as active identity incidents and revoke them as quickly as possible.

Why remediation delay is the real control failure

The 94-day remediation window matters because detection without action leaves a credential usable for weeks or months. Attackers automate secret scraping across public code, tickets, and paste sites, then test credentials quickly against cloud, SaaS, and CI systems. In practice, the control gap is usually not discovery alone but ownership, approval routing, and dependency mapping. If a team cannot tell who owns a token or what workload depends on it, revocation becomes a business risk rather than a security action. That is a lifecycle failure, not a one-off leak.

Practical implication: Build ownership and revocation workflows before the next exposure, not after detection.

How token scope turns one leak into a wider identity problem

The danger from exposed JWTs and GitLab tokens is often proportional to how broadly they are used. A token that authenticates a single application is bad enough. A token reused across multiple services, pipelines, or environments becomes an identity multiplier that expands the blast radius of one leak. This is why secret sprawl and identity sprawl tend to move together. The deeper technical lesson is that NHI security depends on scoping, binding, and lifecycle control, not just vaulting the value of the secret itself.

Practical implication: Reduce reuse, shorten token lifetime, and segment credentials by workload and environment.

Threat narrative

Attacker objective: The attacker wants durable authenticated access that can be used to reach cloud resources, pipelines, or sensitive data without needing a password-based intrusion.

1. Entry begins when attackers harvest a leaked JWT or GitLab token from public code or adjacent developer systems.
2. Escalation occurs when the token grants direct access to cloud APIs, build pipelines, or internal repositories without MFA challenge.
3. Impact follows when the attacker uses that access to move laterally, modify software artefacts, or exfiltrate data before the secret is revoked.

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

Leaked secrets are now a non-human identity governance problem, not a repository hygiene problem. The report’s numbers show that exposed credentials remain one of the most reliable entry points for attackers. That shifts the control conversation from code review alone to identity ownership, lifecycle enforcement, and blast-radius reduction. Practitioners should treat every leaked token as an unmanaged NHI until proven otherwise.

Ephemeral access does not eliminate trust debt when token reuse remains high. JWTs and development tokens may look temporary, but reused credentials still create durable authentication paths across systems. The operational risk is not only exposure, but also cross-environment reuse that makes one leak propagate farther than intended. NHI programmes should therefore measure reuse, not just rotation frequency, and they should cap token scope aggressively.

Identity blast radius is the right concept for understanding secret exposure. A single exposed secret becomes more dangerous when it authenticates multiple workloads, pipelines, or SaaS integrations. That is the point at which secret management merges with access architecture. The practical conclusion is to design every non-human credential so compromise is narrow, short-lived, and easy to revoke.

Median dwell time is a governance signal, not just a remediation metric. A 94-day window means the organisation has already conceded a long attacker runway once a secret is public. That suggests ownership gaps, weak escalation paths, or missing automation. Security teams should use dwell time to benchmark whether their NHI controls can actually interrupt attacker use before exploitation matures.

From our research:

• 44% of NHI tokens are exposed in the wild, being sent or stored over platforms like Teams, Jira tickets, Confluence pages, and code commits, according to The 2025 State of NHIs and Secrets in Cybersecurity.
• 91% of former employee tokens remain active after offboarding, leaving organisations vulnerable to potential security breaches.
• For deeper context, see Guide to the Secret Sprawl Challenge for the operational controls that reduce exposure across development and collaboration systems.

What this signals

Secret exposure will keep behaving like an identity problem until teams instrument ownership and lifecycle controls end to end. With 44% of NHI tokens exposed in the wild according to The 2025 State of NHIs and Secrets in Cybersecurity, the governance gap is already structural. Programmes that still rely on periodic scans without revocation automation will keep finding the same problem after attackers do.

The practical signal for most organisations is that remediation speed now matters as much as detection coverage. NHI teams should align secret handling with least privilege, short lifetime, and explicit ownership, then validate those controls against the NHI lifecycle rather than treating them as one-off hygiene checks.

For a broader control lens, map these failures to the OWASP Top 10 for Agentic Applications 2026 and the NIST AI Risk Management Framework where agent access and token misuse intersect.

For practitioners

• Inventory exposed and reusable secrets across code and collaboration tools Scan repositories, tickets, logs, and chat systems for JWTs, CI/CD tokens, and other credentials, then map each one to a human owner and workload dependency.
• Shorten token lifetime and eliminate cross-environment reuse Use separate credentials for each workload, pipeline, and environment so that one leaked token cannot unlock unrelated systems or production access.
• Automate revocation workflows for public secret exposure Trigger immediate rotation or revocation when scanners detect a secret in a public repository, and route exceptions through an approval process with deadlines.
• Measure secret dwell time as a control objective Track the hours between exposure, detection, and revocation so the organisation can prove that leaked credentials are becoming unusable before attackers can act.

Key takeaways

• Leaked secrets remain one of the most reliable ways into cloud and development environments because they function as usable identities, not just configuration artefacts.
• The scale of the problem is measured in both exposure and dwell time, with hundreds of thousands of secrets found and a 94-day median remediation window.
• The right response is to reduce reuse, shorten lifetime, and automate revocation so a leaked token cannot remain an attacker-ready credential.

Key terms

• Non-Human Identity: A non-human identity is any machine or software credential that authenticates and receives access in an environment. That includes service accounts, API tokens, certificates, workloads, and agents. In practice, these identities need ownership, lifecycle controls, and least-privilege scoping just like user identities.
• Secret Sprawl: Secret sprawl is the uncontrolled spread of credentials across code, collaboration tools, logs, and build systems. It increases exposure because teams lose track of where secrets exist, who owns them, and whether they are still valid. The result is wider blast radius and slower revocation when compromise occurs.
• Token Reuse: Token reuse occurs when the same credential is used across multiple applications, pipelines, or environments. This pattern increases the impact of any single leak because compromise in one place can open access elsewhere. It is a common sign that identity boundaries are too loose for modern automation.

What's in the full article

Verizon's full blog covers the operational detail this post intentionally leaves for the source:

• The exact breakdown of exposed secret categories and the figure behind each category
• The source article's commentary on remediation timing and why some secrets remained exposed for more than 160 days
• Entro's product-oriented workflow examples for discovery, classification, and rotation
• The article's closing guidance on how teams can respond to leaked secrets across code, CI/CD, and SaaS

👉 The source article includes the underlying DBIR figures and the vendor's commentary on remediation and GenAI data leakage.

Deepen your knowledge

Secrets exposure, token reuse, and lifecycle control are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to move from ad hoc secret handling to governed NHI operations, it is worth exploring.