Third-party supply chain breaches expose identity governance gaps

At a glance

What this is: Saviynt’s roundup argues that recent breach coverage points to third-party and supply chain exposure as a persistent identity risk, not a one-off event.

Why it matters: For IAM and NHI teams, the practical problem is delegated access and external dependencies expanding blast radius faster than governance processes can track.

By the numbers:

• On 2025-04-15, Cisco said a hacker breached its multifactor authentication message provider on April 1, showing how a supplier can become an identity-related entry point.
• On 2025-04-09, Home Depot said a third-party SaaS misconfiguration contributed to a data breach, reinforcing how partner-side controls can create exposure.

👉 Read Saviynt's roundup of supply chain breaches and identity risk

Context

Third-party risk becomes an identity problem when external systems can issue, relay, store, or validate credentials on behalf of the enterprise. In that model, a breach is not only about stolen data; it can also reveal how trust was delegated, where controls were missing, and which non-human identities had too much reach. The keyword for IAM and NHI practitioners is blast radius.

Saviynt’s link roundup centers on recent supply chain and third-party incidents because they show a common pattern: compromise often travels through trusted integrations rather than through the primary target alone. That pattern is typical, not exceptional, in modern cloud and SaaS environments, where service accounts, API connections, and vendor-linked workflows expand the identity surface well beyond employee accounts.

Key questions

Q: How should security teams govern third-party identity access?

A: Security teams should inventory every external identity path, assign an internal owner, and apply scope, expiry, and revocation rules to each connection. Third-party access should be treated like privileged access, not like a static vendor checkbox. Continuous review matters because partner systems can become live identity dependencies long after onboarding.

Q: What is the difference between vendor risk management and identity governance?

A: Vendor risk management asks whether a supplier is acceptable overall. Identity governance asks what that supplier can access, for how long, and under what conditions. In a breach, the second question determines blast radius. That is why supplier controls must be measured as access controls, not only as contractual or compliance obligations.

Q: When does a third-party integration become a security liability?

A: A third-party integration becomes a liability when it can store, forward, or validate secrets without tight scoping and regular review. The risk rises when the connection is durable, overprivileged, or poorly monitored. At that point, the integration is not just a dependency. It is part of the enterprise access model.

Q: Why do supply chain breaches matter to NHI programs?

A: Supply chain breaches matter because many partner connections rely on non-human identities such as API keys, tokens, certificates, and service accounts. If those identities are broad or persistent, a supplier compromise can expose more than one system. NHI programs are responsible for shrinking that trust surface before attackers exploit it.

Technical breakdown

How third-party compromise turns into identity exposure

Third-party compromise often becomes identity exposure because the attacker does not need to break the target directly if the supplier already holds trusted access or transmits authentication material. In practice, that may involve MFA providers, SaaS integrations, support portals, or token-based workflows that sit inside the trust boundary but outside direct enterprise control. Once those links are abused, the attacker can pivot from supplier systems into identity-adjacent assets such as message flows, session data, API credentials, or administrative workflows. The failure mode is usually not one control failure but a chain of trust assumptions that were never revisited after the integration went live.

Practical implication: inventory every externally trusted identity path and treat supplier integrations as part of the access-control surface.

Why SaaS misconfiguration matters for non-human identities

SaaS misconfiguration matters because non-human identities often inherit access from the service they are tied to rather than from an explicit governance decision. When permissions are broad, opaque, or delegated across environments, a configuration error can expose data even if no password is stolen. This is especially relevant for API keys, tokens, certificates, and service accounts, which are frequently created to make workflows easier but then left with standing access. The result is an identity layer that is functionally invisible to many governance workflows, even though it is producing real access paths.

Practical implication: apply the same review discipline to service accounts and tokens that you apply to human privileged access.

Why supply chain incidents are really privilege problems

Supply chain incidents become privilege problems when external software, support systems, or partner workflows can access internal data without tight scoping, expiry, or monitoring. The issue is not simply that a vendor was breached. The issue is that the enterprise accepted a durable trust relationship without clear boundaries on what the external party could read, write, or relay. That is why identity governance, privileged access management, and secrets hygiene need to be evaluated together rather than as separate disciplines. If a supplier can validate or transmit credentials, it is effectively part of the enterprise privilege model.

Practical implication: scope, expire, and continuously verify supplier privileges instead of assuming contractual trust is enough.

Threat narrative

Attacker objective: The attacker’s objective is to turn a supplier foothold into broader access to identity-linked systems, credentials, or sensitive data.

1. Entry via a compromised supplier system, SaaS integration, or support channel that already has trusted access into enterprise workflows.
2. Escalation through token reuse, overbroad delegated permissions, or exposure of authentication data that lets the attacker pivot beyond the supplier boundary.
3. Impact through access to customer data, internal credentials, or identity-related telemetry that expands the breach beyond the original partner compromise.

Breaches seen in the wild

• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.
• Reviewdog GitHub Action supply chain attack — reviewdog/action-setup GitHub Action supply chain attack exposed secrets.

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

NHI Mgmt Group analysis

Third-party compromise is now an identity governance issue, not a vendor management issue. Modern enterprises rely on external systems to store, validate, or forward authentication data, which means breach containment depends on identity controls that extend beyond the perimeter. Procurement checks do not address standing trust, and contracts do not reduce token exposure. Practitioners should treat every external trust relationship as an identity control with an owner, scope, and expiry.

Supplier-linked identity paths create a distinct form of blast radius debt. The more external services can issue, relay, or store secrets, the more difficult it becomes to reconstruct exposure after an incident. That is especially true for service accounts, API connections, and machine-to-machine integrations, where ownership is often fragmented. Identity blast radius: the amount of access an external compromise can inherit before detection. Security teams should reduce it continuously, not only after a breach.

Converged governance matters because the failure modes overlap. IAM tells you who or what should access the resource, PAM constrains elevated privilege, and secrets management controls how authentication material is stored and rotated. In third-party incidents, all three can fail at once if trust is broad and monitoring is weak. Practitioners should stop managing those controls as separate programs and start reviewing them as one access system.

The market is signalling a shift from visibility to enforceability. Point-in-time third-party inventories are no longer enough when suppliers can become live identity dependencies overnight. The next expectation is not simply knowing which partner connects to which system, but being able to constrain that access in real time. Teams that cannot enforce expiry, scope, and revocation across supplier identities will remain exposed even if they have good disclosure processes.

OWASP NHI-style governance is becoming the right mental model for partner risk. External identities now behave like enterprise NHIs because they authenticate, act, and sometimes persist without direct human intervention. That changes the question from whether a vendor is trusted to whether its access is measurable, minimal, and revocable. Practitioners should align third-party controls with NHI governance, not with traditional one-time vendor review rituals.

From our research:

• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, according to The 2024 ESG Report: Managing Non-Human Identities.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months, according to The 2024 ESG Report: Managing Non-Human Identities.
• For a deeper control baseline, compare third-party exposure against OWASP NHI Top 10 and then map supplier identities to revocation requirements.

What this signals

Identity teams should assume third-party compromise will continue to arrive through trusted integrations rather than direct intrusion. The programme response is to make supplier access measurable, scoped, and revocable before an incident forces that discipline. When a partner can touch secrets, session data, or authentication workflows, the relationship needs the same lifecycle controls as an internal NHI.

Identity blast radius is now a board-relevant metric for external access. If a supplier compromise can cascade into multiple systems, the question is not whether the vendor passed onboarding. The question is how much access would remain after a single revocation action. Teams should build reporting around revocation speed, token lifetime, and orphaned external privileges.

With 2.7 separate incidents on average after a compromised NHI, according to our 2024 ESG Report, repeated exposure is the norm once identity governance breaks down. That makes partner dependency reviews and secrets hygiene recurring controls, not one-time remediation tasks.

For practitioners

• Map external identity dependencies end to end Document every supplier, SaaS app, and support workflow that can issue, relay, or validate credentials, then assign an internal owner for each path.
• Review delegated access on a fixed cadence Re-certify partner privileges, service accounts, and tokens on a schedule that reflects business risk, not contract renewal cycles.
• Shorten the lifetime of shared secrets Replace standing credentials with scoped, expiring access wherever possible, and track rotation exceptions as governance defects.
• Tie incident playbooks to supplier revocation Build revocation steps for API keys, integrations, and support access into response plans so partner compromise can be contained quickly.
• Use breach case patterns to test controls Validate your control design against the 52 NHI Breaches Analysis and OWASP Non-Human Identity Top 10 so supplier exposure is not treated as a special case.

Key takeaways

• Third-party breaches increasingly behave like identity incidents because supplier access can carry the compromise deeper into the enterprise.
• The evidence points to repeated identity exposure, not isolated failures, which makes standing trust a structural risk.
• Security teams should govern external access with the same discipline used for privileged and non-human identities.

Key terms

• Third-party identity path: A third-party identity path is any external connection that can authenticate, relay, or store access on behalf of the enterprise. It includes supplier integrations, support channels, and SaaS links. These paths matter because they extend the trust boundary and can become the fastest route from partner compromise to internal exposure.
• Identity blast radius: Identity blast radius is the amount of access that can be inherited, reused, or abused after one identity compromise. It is a practical measure of how far a breach can spread through service accounts, API tokens, certificates, and delegated access. Smaller blast radius means faster containment and less downstream damage.
• 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.

What's in the full analysis

Saviynt's full article covers the operational detail this post intentionally leaves for the source:

• A running list of the linked breach stories and the specific third-party failure mode associated with each one.
• The vendor’s own framing of why these incidents matter for identity and access governance.
• Additional context around the news items surfaced in the roundup, including related coverage on supply chain compromise.
• The source article’s broader identity-security commentary that sits behind the headline list.

👉 Saviynt's full post links the source stories and surrounding identity-security context.

Deepen your knowledge

Third-party identity governance and non-human identity controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is wrestling with supplier access, token sprawl, or revocation gaps, it is worth exploring.