Third-party supply chain breaches expose identity governance gaps

At a glance

What this is: This roundup links recent third-party and supply chain incidents to identity governance gaps, especially where external access, credentials, and delegated trust were not tightly controlled.

Why it matters: IAM and NHI teams need to treat partner exposure as an identity problem because external access can widen blast radius long before a breach is contained.

Context

Third-party supply chain breaches are an identity governance problem when external access, delegated trust, and shared credentials extend an organisation’s reach beyond its own controls. In this article, Saviynt groups recent incidents to show how partner ecosystems can become the easiest path into core systems when governance does not follow the access relationship.

For IAM, PAM, and NHI programmes, the key issue is not whether a vendor was compromised somewhere else. The issue is whether external identities, tokens, and integrated workflows remain visible, scoped, and revocable once they cross organisational boundaries.

Key questions

Q: What breaks when non-human identities are not offboarded properly?

A: Orphaned NHIs remain valid long after the workload or integration they served is gone, which gives attackers a durable access path. The failure is not just administrative drift. It is living authentication that no longer has a legitimate owner, so compromise can happen through forgotten keys, tokens, or service accounts.

Q: Why do third-party credentials create more breach risk than perimeter controls alone can stop?

A: Third-party credentials can bypass perimeter defenses because they may be accepted as legitimate even when the initial compromise happened elsewhere. That means an attacker does not need to break the outer wall if they can authenticate through a trusted vendor path. Strong vendor access controls, credential oversight, and monitoring of partner activity are critical when trust extends beyond your own network.

Q: How can IAM teams tell whether vendor access is too broad?

A: Vendor access is too broad when the identity can reach systems or data outside the task it was hired to perform, especially if the permissions are permanent or reused across multiple services. A useful test is whether the access can be described in one contract-specific sentence without mentioning convenience or future reuse.

Q: What should security teams do after a supplier breach exposes customer data?

A: They should verify exposure, map which records or business units may be affected, notify impacted parties through a controlled process, and offer practical support such as monitoring or fraud protection where appropriate. Teams should also preserve evidence, coordinate legal and privacy review, and publish a timeline that explains what happened and what is being done next.

Technical breakdown

Why third-party identity reach expands the attack surface

Third-party integrations create identity dependencies that are easy to underestimate. When vendors, service providers, or SaaS connectors are granted access, the organisation inherits not just their authentication boundary but also their credential hygiene, token handling, and revocation discipline. In practice, this means the attack surface is defined by the combined control plane of both parties. If a partner credential, OAuth grant, or API token is exposed elsewhere, the internal environment can still be affected because trust was extended across the boundary without equally strong lifecycle governance.

Practical implication: inventory every external identity and map who can still act inside your environment after the relationship changes.

Delegated trust and exposed credentials in supply chain incidents

Supply chain incidents often succeed because delegated trust outlives the reason it was granted. A stolen token, over-scoped integration, or shared secret can turn one partner compromise into downstream access across multiple customers. The technical failure is rarely just initial compromise. It is the combination of standing connectivity, insufficient scoping, and weak offboarding of non-human identities. Once those elements align, an attacker can move from the partner environment into customer data, operational systems, or administrative workflows without needing to break primary authentication directly.

Practical implication: narrow external scopes to the smallest viable permissions and make revocation a tested operational path, not an exception process.

Why identity governance must cover the partner lifecycle

Identity governance for third parties cannot stop at onboarding approval. It has to cover the full lifecycle of access, including creation, periodic review, rotation, suspension, and offboarding. That is especially true for service accounts, API keys, and federated access that may not have a human owner watching them daily. If the lifecycle is not explicit, then external identities can remain active long after the business need has changed. That creates hidden reach, delayed detection, and a larger blast radius when one partner is compromised.

Practical implication: apply lifecycle controls to partner-linked NHIs with the same discipline used for internal privileged access.

Threat narrative

Attacker objective: The attacker wants to turn trusted external access into broader internal reach without having to defeat primary authentication directly.

1. Entry occurs through a compromised third-party integration, exposed credential, or poisoned supply chain component that already has trust into the target environment.
2. Credential abuse follows when the attacker uses delegated access, tokens, or partner-scoped secrets to reach systems that appear legitimate to the target.
3. Impact occurs when that external trust path exposes customer data, internal credentials, or administrative control across connected systems.

Breaches seen in the wild

• reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.

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 breach risk is an identity governance problem before it is a vendor risk problem. Most organisations still treat partner exposure as a procurement or security questionnaire issue, but the real control failure is identity reach without continuous lifecycle control. Once an external identity can act inside production, the organisation has accepted shared trust without shared governance. Practitioners should treat partner access as a governed identity class, not a one-time exception.

Delegated trust outlives its business justification far too often. The article’s examples point to a recurring pattern: access is granted for integration, support, or delivery, but offboarding is not enforced with the same rigour. That creates a standing trust corridor that attackers can exploit long after the original relationship has changed. The implication is straightforward for IAM and NHI teams. If access cannot be cleanly revoked, the trust model is already broken.

Third-party NHIs need lifecycle ownership, not just visibility. Discovery alone does not solve partner risk if service accounts, tokens, and keys remain active after a contract ends or a workflow changes. This is where NHI governance and vendor management converge. The control gap is not merely knowing that an external identity exists. It is proving that every external identity has an owner, expiry logic, and a tested revocation path.

Identity blast radius should become a standard metric for supply chain resilience. The article reinforces that a compromise outside the enterprise can still produce a large internal impact when scope is broad and dependencies are dense. That makes blast radius a better governance lens than simple access counts. Teams should ask how many systems a third party can touch, how quickly that reach can be removed, and how much downstream privilege exists behind one trust relationship.

Partner ecosystem security now spans human, NHI, and workflow identities together. A single supplier relationship can involve human admins, service accounts, API tokens, and automation hooks at once. That means governance cannot be split across separate teams that each see only part of the chain. The practitioner conclusion is to unify third-party identity review across access, secrets, and execution paths before another incident expands through a trusted integration.

From our research library:

• 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
• Read next: NHI Lifecycle Management Guide

What this signals

Identity blast radius: Third-party risk should be measured by how far a supplier identity can move, not by how many vendors are on a procurement list. Once a partner can reach production systems, the practical question becomes how quickly that reach can be withdrawn when the relationship changes.

External trust paths will keep showing up in breach narratives because lifecycle control is usually weaker at the boundary than inside the enterprise. IAM teams should expect partner access reviews, token revocation, and offboarding proof to become board-level evidence, not just operational hygiene.

For practitioners

• Map every third-party identity path Build an inventory of partner-linked service accounts, API keys, OAuth grants, and federated sessions that can reach production systems. Include the business owner, technical owner, expiry, and revocation method for each path.
• Shorten external trust windows Replace open-ended partner access with time-bound scopes, explicit reapproval triggers, and routine revalidation of business need. Where possible, isolate partner access behind narrow workflows rather than broad environment access.
• Test offboarding before the contract ends Simulate partner removal for one external identity set and confirm that tokens, keys, and session paths are actually revoked across all connected systems. Record every residual dependency that prevents clean shutdown.
• Tie third-party access to lifecycle ownership Require a named internal owner for each external identity and make that owner accountable for certification, rotation, and revocation. If nobody can be assigned, the access should not remain active.

Key takeaways

• Third-party breach exposure is fundamentally an identity governance issue because external access can outlive the business need that created it.
• The recurring failure pattern is not just compromise, but standing trust with weak revocation, weak scoping, and incomplete ownership across partner-linked identities.
• The most effective control is a lifecycle model for third-party access that makes every external identity named, scoped, reviewable, and revocable.

Key terms

• Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.
• Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
• Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.
• Vendor offboarding: Vendor offboarding is the controlled removal of a third party's access, data paths, and operational dependencies when the relationship ends or changes. It is a lifecycle control, not an administrative closeout, because any surviving credentials or integrations remain active security exposure.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity lifecycle 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 programme, it is worth exploring.