Third-party breach cascades now outpace disclosure and naming

At a glance

What this is: Black Kite’s analysis says third-party breach impact in 2025 spread far beyond named victims, with 136 verified events and a much larger unnamed downstream footprint.

Why it matters: This matters because IAM, NHI, and third-party access governance all fail when organisations cannot see which identities, tokens, and integrations are propagating risk across shared services.

By the numbers:

• 136 verified third-party breach events were publicly disclosed in 2025, breaking the previous pattern of more stable yearly volumes.
• 719 publicly impacted companies were named across those incidents, which captures only the disclosed portion of the downstream blast radius.
• 27 separate incidents disclosed downstream impact only in aggregate, hiding approximately 26,000 additional affected companies.
• 2025 reached an average of 5.28 downstream victims per third-party breach, the highest level observed to date.

Context

Third-party risk becomes a governance failure when organisations can no longer trace where trust is concentrated, where it is delegated, and where it expands after compromise. In supply chain incidents, exposure often begins in a vendor, but the operational damage appears later in customer environments, SaaS integrations, and identity-linked access paths.

This analysis is less about counting incidents than about understanding how dependency networks turn a single compromise into many affected organisations. That pattern is especially relevant to NHI governance because tokens, API keys, OAuth grants, service accounts, and other delegated credentials often carry the trust that makes downstream propagation possible.

Key questions

Q: What breaks when third-party access is not reviewed continuously?

A: The break is that access stays active long after the business relationship, vendor task, or application purpose has changed. Without continuous review, teams rely on outdated certifications that do not reflect live permissions. The result is uncontrolled delegated access, especially across SaaS and OAuth-connected systems.

Q: Why does disclosure delay make supply chain breaches worse?

A: Disclosure delay extends the period in which stolen or misused credentials remain active. Customers cannot revoke access, rotate secrets, or contain integrations they do not yet know are affected. In practice, the delay turns vendor silence into continued exposure, which is why incident response must assume notification may arrive after the attacker has already moved on.

Q: How should security teams reduce the blast radius of edge compromise?

A: Treat internet-facing gateways as entry points into identity risk, not isolated infrastructure assets. Segment administration, shorten the reach of privileged accounts, and test whether a compromised VPN or firewall can reach directory services, cloud consoles, or OT management paths. If it can, the blast radius is still too large.

Q: What is the difference between third-party risk management and SaaS app governance?

A: Third-party risk management looks at the full supplier relationship, including contract, due diligence, and ongoing monitoring. SaaS app governance focuses on the actual permissions, tokens, and connected applications that move data or actions between systems. Organisations need both because a supplier can be low risk on paper while its connected app still exposes highly privileged access.

Technical breakdown

Why third-party compromise becomes a cascading access problem

A third-party breach becomes a cascade when one trusted dependency is reused across many customer environments, applications, or integrations. The technical risk is not only the initial intrusion, but the access paths that follow through shared SaaS platforms, OAuth grants, and downstream automation. Once those pathways exist, the compromise can move laterally across organisations without needing a separate exploit in each target. This is why supply chain incidents often look small at entry and large at impact. The architecture of trust determines the blast radius as much as the attacker’s tooling does. See the SaaS-to-SaaS and OAuth App Governance Guide.

Practical implication: Map shared access paths and remove unnecessary trust between vendors, integrations, and internal systems before a compromise turns into broad propagation.

Why disclosure lag amplifies identity and access risk

Delayed disclosure gives defenders less time to revoke tokens, rotate credentials, and invalidate active integrations. In a third-party event, the security question is not only whether compromise occurred, but whether the customer still has live trust relationships that the vendor has not yet surfaced. A long disclosure window keeps delegated credentials usable after the incident, which means the attacker’s window and the customer’s exposure window overlap. For identity teams, the problem is lifecycle control: the access existed before the breach, and it may still exist after the vendor has detected it. Read Top 10 NHI Issues.

Practical implication: Treat vendor notification lag as an access control risk and plan for emergency revocation of delegated credentials as soon as compromise is suspected.

How centralised SaaS and API integrations create shared failure domains

Centralised platforms become shared failure domains when many organisations depend on the same identity and integration layer for routine business workflows. OAuth tokens, API keys, connected apps, and service credentials can all become leverage points if the central platform or a connected vendor is abused. The result is not just one compromised account, but a chain of authorised actions that spans multiple tenants and business processes. This is why the article’s emphasis on unnamed victims matters: the attack surface is often distributed through identity relationships, even when the breach is reported as a single event.

Practical implication: Inventory high-trust integrations and classify them as shared failure domains, not isolated vendor connections.

Threat narrative

Attacker objective: To convert one compromised dependency into repeated access across many downstream environments and maximise the scale of stolen data or operational disruption.

1. Entry occurs through a trusted third-party platform, integration, or credential path rather than a direct attack on each downstream victim.
2. Credential or token abuse then allows the attacker to operate inside shared services and authorised workflows without needing a fresh foothold in every environment.
3. Escalation happens as the same access path reaches multiple customers or business units, expanding the blast radius across the supply chain.
4. Impact is broad downstream exposure, delayed revocation, and in many cases undisclosed or unnamed victim organisations.

Breaches seen in the wild

• Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Third-party risk has become a trust orchestration problem, not a vendor list problem. The article shows that the material risk is no longer limited to direct supplier failure, but to the web of integrations, credentials, and delegated access that make one compromise reusable across many organisations. That shifts governance from static due diligence toward continuous trust mapping across identity-bearing relationships. Practitioners should treat every shared integration as a live control surface.

Disclosure delay is now an access-control defect. When vendors wait weeks or months to disclose compromise, customers lose the chance to revoke tokens, invalidate sessions, and contain propagation before the attacker’s access expires naturally. The article’s 73 day median disclosure lag shows that the gap between compromise and customer action can be longer than the attack itself. Practitioners should build revocation playbooks for delayed notification, not assume timely vendor transparency.

Identity workflows are the new supply chain attack surface. The article’s discussion of OAuth tokens, support workflows, and shared platforms shows that attackers often target identity relationships more than infrastructure flaws. That is directly relevant to NHI governance because service accounts, API keys, and connected apps frequently carry the permissions that turn a third-party event into a downstream breach. SaaS-to-SaaS governance is now part of supply chain resilience, not a niche control. Practitioners should govern delegated credentials as part of third-party risk, not as a separate technical concern.

Unnamed victims are a governance failure, not a reporting footnote. When disclosures list only aggregate impact, defenders cannot reliably map exposure, decide who must revoke access, or prove whether a specific integration was affected. The article correctly treats visibility loss as part of the risk itself. For security teams, the practical conclusion is that incomplete disclosure should trigger conservative containment assumptions, especially where customer identity data or machine credentials are involved.

From our research library:

• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Delegated access is now the dominant propagation path in supply chain breaches. When shared platforms and connected apps carry trusted access across tenants, the real control objective becomes containing reuse of that trust rather than simply hardening the original vendor. The most durable programmes will govern OAuth grants, API keys, and service accounts as shared-risk assets, not isolated admin details. according to the Ultimate Guide to NHIs

Third-party concentration creates a measurable shadow layer of exposure. Black Kite’s dataset shows that disclosed victim counts only describe part of the problem, because many incidents stop at aggregate disclosure and never name every affected organisation. That visibility gap makes continuous monitoring and revocation planning essential for teams that depend on external integrations.

Supply chain resilience now depends on identity governance depth. If a vendor compromise can travel through federated access, connected apps, and machine credentials, then the programme boundary has to move beyond vendor questionnaires. Security teams should model third-party access as an identity lifecycle problem, with issuance, scope, rotation, and offboarding all under active control.

For practitioners

• Map all delegated vendor access paths Inventory OAuth grants, API keys, service accounts, and connected apps that allow vendors or SaaS tools to act inside your environment, then rank them by blast radius and business criticality.
• Pre-stage emergency revocation for third-party credentials Define who can disable tokens, connected apps, and service accounts when a supplier is suspected of compromise, and make that authority available before vendor confirmation arrives.
• Treat disclosure lag as a control gap Assume a vendor may know about an incident long before customers are notified, and test whether your monitoring can detect misuse of shared integrations during that window.
• Segment shared platforms from sensitive workflows Reduce the number of business processes that depend on a single SaaS integration or centralised platform so one compromised dependency cannot reach every downstream system.
• Build supplier offboarding into identity governance Require timely removal of vendor accounts, app registrations, certificates, and credentials when contracts end or access purpose changes, and verify that removal is complete.

Key takeaways

• Third-party breaches are increasingly measured by how far they propagate, not just by how many vendors are named.
• The article shows that disclosure lag and unnamed downstream victims are part of the risk, not just reporting artefacts.
• Governance has to focus on delegated access paths, because OAuth grants, API keys, and connected apps can turn one breach into many.

Related NHI Mgmt Group resources: SaaS-to-SaaS and OAuth App Governance Guide · AI Supply Chain Security and AI-BOM Guide · Third-Party Risk Management Guide · Klue OAuth Supply Chain Breach

Key terms

• Third-Party Risk Propagation: The spread of compromise from one supplier or platform into many downstream organisations through shared trust relationships. It is driven by delegated access, integrations, and reused credentials, which means the impact of a single incident can extend far beyond the original breach boundary.
• Disclosure Lag: Disclosure lag is the delay between a vulnerability becoming public and that vulnerability appearing in the systems defenders use for prioritisation and reporting. In practice, the lag creates a blind spot where risk is real but not yet fully reflected in formal control processes.
• Delegated access path: A delegated access path is the chain of identities, tokens, connectors, and approvals that lets one system act through another. It becomes a governance concern when the path outlives the original approval or can be reused for actions beyond the intended business purpose.
• Shared Failure Domain: A concentration of trust in a central service or integration layer where one failure can affect many organisations at once. In cloud and SaaS ecosystems, shared failure domains turn business dependencies into security dependencies, which makes containment and offboarding essential.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It helps practitioners connect machine identity control to the wider security programme they run.