2025 DBIR: what credential abuse and third-party breaches mean for teams

Updated October 3, 2026. This article replaces an earlier announcement for a Cremit report that was not linked or available to readers. The figures below come from Verizon’s published 2025 Data Breach Investigations Report (DBIR), and the actions are our interpretation for teams managing credentials.

What the 2025 DBIR actually measured

Verizon analyzed more than 22,000 security incidents, including 12,195 confirmed breaches. In its 2025 report, credential abuse accounted for 22% of initial access in breaches and exploitation of vulnerabilities for 20%. Third-party involvement in breaches doubled to 30%. The dataset covers incidents from November 2023 through October 2024, despite the report’s 2025 title.

These percentages describe Verizon’s breach dataset. They are not a measurement of non-human identities, exposed API keys, or the effectiveness of any secret scanner. A stolen employee password and a leaked service token can both lead to credential abuse, but the report does not make every credential case an NHI case.

Where a credential program should start

List the integrations and service accounts that can reach production systems. For each one, record an owner, the issuing service, permissions, expiry, and where the credential is stored. Review third-party access separately; a vendor’s connection can remain active long after a project ends.

Prevent leaks at the source. Store secrets in an appropriate manager, use short-lived credentials where available, limit CI workflow permissions, and enable your Git provider’s secret scanning and push protection. GitHub documents both the repository types it scans and the limits of push protection, so check what your plan and settings actually cover.

Then look for what prevention missed: old commits, collaboration messages, documents, storage, and container images. Cremit Platform scans supported connected sources and can verify supported credential types with their issuing services. A scanner cannot inspect a source it has not been granted access to, and a finding is not proof that a key was used by an attacker.

Respond to a live key

When a credential still works, identify its owner and affected systems, rotate or revoke it at the issuing service, and review the provider’s access logs for suspicious use. Remove exposed copies, but do not treat deletion from a repository as revocation. Record the source of the leak and close that path before issuing the replacement key.

The 2025 DBIR is a useful reason to inspect credential and third-party access. It does not replace an inventory of your own environment or an incident response test.

Sources

Verizon, 2025 Data Breach Investigations Report announcement: https://www.verizon.com/about/news/2025-data-breach-investigations-report

Verizon, DBIR report description and data period: https://www.verizon.com/business/resources/reports/

GitHub Docs, secret scanning detection scope: https://docs.github.com/en/code-security/reference/secret-security/secret-scanning-scope

GitHub Docs, enable push protection: https://docs.github.com/en/code-security/how-tos/secure-your-secrets/prevent-future-leaks/enable-push-protection