Third-party supply chain breaches are reshaping identity governance

At a glance

What this is: This is a Saviynt news roundup centred on the Sisense breach and a broader pattern of third-party supply chain risk affecting identity and access ecosystems.

Why it matters: It matters because third-party exposure often bypasses direct perimeter controls, forcing IAM, NHI, and PAM teams to govern external access, delegated trust, and offboarding with much tighter discipline.

👉 Read Saviynt's coverage of the Sisense breach and supply chain risk

Context

Third-party supply chain risk is an identity governance problem when external access, shared services, or delegated credentials become the route into production systems. In practice, the issue is not only whether a vendor was breached, but whether the organisation has visibility into who or what can act on its behalf once trust extends outside its own boundary.

The Sisense case sits in that wider pattern. For IAM and NHI practitioners, it reinforces that access governance cannot stop at employee identity, because business-critical systems increasingly depend on service accounts, vendor integrations, and other non-human identities whose lifecycle is often weaker than the human accounts people focus on first.

Key questions

Q: How should security teams govern third-party identities that can reach production systems?

A: Treat every third-party identity as production access with an owner, scope, and revocation path. Put supplier accounts, tokens, and service credentials into the same certification and offboarding process you use for internal access so the business can prove who can act, why they can act, and when that access ends.

Q: Why do supplier breaches often become IAM problems inside the customer environment?

A: Because the customer usually inherits the access relationship even when it does not control the supplier’s security posture. Once a trusted connection is in place, the attacker can operate through legitimate identity paths, so the internal failure is often poor entitlement scope, weak review evidence, or missing offboarding.

Q: What breaks when third-party credentials are not tied to lifecycle offboarding?

A: Access can outlive the business relationship and remain active long after the need for it has ended. That creates standing privilege, weak accountability, and a larger blast radius if the vendor or its connected service is later compromised.

Q: Who should be accountable when a vendor-linked identity is abused in a breach?

A: Accountability should sit with the business owner of the access, the technical owner of the integration, and the identity team enforcing revocation. If any of those three cannot explain the purpose, scope, and shutdown path, the governance model is incomplete.

Technical breakdown

How third-party access becomes an identity boundary failure

Supply chain breaches often succeed because a trusted external dependency sits inside the access model even when it is outside the security team’s operational control. Once a vendor credential, integration token, or managed connection is accepted, the attacker does not need to defeat core authentication again. The real weakness is that the organisation usually trusts the relationship more than it governs the identity behind it. That creates a blind spot in lifecycle control, access scope, and offboarding. In identity terms, the external party becomes an extension of the enterprise attack surface, but without the same review cadence or entitlement scrutiny.

Practical implication: Map every third-party identity to an owner, scope, and revocation path before it is allowed into production.

Why delegated credentials amplify blast radius

Delegated access often looks narrow at provisioning time, but its practical scope can expand through linked systems, API trust chains, and reusable credentials. A compromised token or service account can be enough to move from a single integration to broader operational access if privilege boundaries are not explicit. This is why least privilege matters more for non-human identities than for most human workflows: machines can repeat actions quickly, call other services, and remain active long after the original business purpose has changed. The governance gap is not just exposure, but persistence without meaningful review.

Practical implication: Classify third-party and machine credentials by blast radius, then reduce standing privilege and shorten revocation delays.

Why external compromise still becomes an internal IAM problem

A supplier incident becomes an enterprise identity issue when the internal programme cannot prove which access was granted, for what purpose, and whether it was withdrawn when the relationship changed. That is especially true when logs, entitlements, and ownership records are fragmented across SaaS, cloud, and IGA tooling. The practical failure is governance continuity: the business believes a partner is managed because procurement or legal approved the relationship, while identity teams have no operational enforcement over the access itself. In that gap, attackers inherit trusted pathways rather than needing to create them.

Practical implication: Unify vendor onboarding, access certification, and offboarding so third-party identities are reviewed as active access, not contract metadata.

Threat narrative

Attacker objective: The attacker aims to turn external trust into internal reach, using legitimate supplier-linked access to obtain data or expand control.

1. Entry occurs through a trusted third-party relationship or connected service that already has access to the victim environment.
2. Escalation follows when the attacker uses that delegated access to reach more systems than the original integration should have touched.
3. Impact comes from the attacker leveraging trusted identity pathways to expose data, move laterally, or persist inside business services.

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 access is now an identity governance control plane, not a procurement side issue. The Sisense coverage sits inside a broader pattern where supplier trust, delegated access, and machine identities converge. Once access is granted outside the enterprise boundary, the relevant question is no longer only contractual exposure but operational enforceability. Practitioners should treat external identities as governed production access, not as exceptions parked outside IAM.

Vendor trust without lifecycle offboarding is a standing governance failure. External access was designed for relationships that change slowly and are reviewed by humans on a predictable schedule. That assumption fails when a supplier credential, token, or integration remains active after the business need has shifted. The implication is that offboarding discipline must be built for identities, not just commercial relationships.

Identity blast radius is the right concept for third-party breach assessment. A breach affecting a vendor matters most when it reveals how far a trusted identity can move once compromised. That is where NHI governance, PAM, and Zero Trust intersect: the security team needs to know not just whether access exists, but how much damage a single delegated identity can cause before detection. Practitioner implication: measure supplier access by reachable systems, not by contract tier.

External compromise becomes internal exposure when review evidence is fragmented. Organisations often split ownership between procurement, security, and application teams, which leaves no single place where access, purpose, and revocation are validated together. That is a governance model failure, not simply a monitoring gap. Practitioners should expect attackers to exploit the seams between those processes rather than the control they were designed to pass.

For NHI programmes, the lesson is that third-party access is part of the secret economy. Tokens, API keys, and service credentials tied to suppliers behave like any other non-human identity when they are reused, poorly scoped, or left active too long. The control objective is therefore consistent across machine and vendor access: reduce persistence, tighten scope, and make revocation operationally immediate.

From our research:

• Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, 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.
• For the broader breach pattern, see 52 NHI Breaches Analysis for recurring root causes and governance failures.

What this signals

Third-party access is becoming part of the same control problem as machine identity sprawl. If vendor-linked credentials are not inventoried, certified, and revoked with the same discipline as internal service accounts, the organisation is treating trust as a business relationship instead of a security boundary. That is where programme owners should expect exposure to widen first.

With two-thirds of enterprises already reporting successful attacks tied to compromised non-human identities, the governance gap is no longer theoretical. IAM, PAM, and vendor-risk teams need a shared operating model that tracks external access from grant to retirement, or the attacker will keep finding identities that outlive their purpose.

For practitioners

• Inventory every external identity in production Build a register of vendor accounts, API keys, tokens, certificates, and service connections that can reach live systems. Record business owner, technical owner, purpose, scope, and the revocation mechanism for each one.
• Tie supplier onboarding to access certification Require explicit review of third-party entitlements during onboarding and at each renewal or major service change. Make the access review prove that the identity still needs the permissions it holds.
• Shorten the life of delegated credentials Replace long-lived shared secrets with narrowly scoped credentials that can be revoked quickly. Where possible, enforce separate credentials per integration so compromise does not cascade across environments.
• Validate offboarding against real access paths When a vendor relationship ends or changes, verify revocation across SaaS, cloud, and application layers instead of closing only the contract record. Confirm that credentials are disabled, rotated, or deleted where they were used.

Key takeaways

• Third-party breaches become identity breaches when external access is not governed as production access.
• The scale of compromised non-human identity attacks shows that delegated trust and weak offboarding are recurring exposure points.
• Security teams should reduce supplier blast radius by inventorying access, certifying scope, and verifying revocation across all systems.

Key terms

• Third-party identity: An identity owned outside the organisation but allowed to access its systems or data. This can include supplier accounts, integration tokens, service credentials, or managed connections. The key governance question is not who issued it, but who owns its scope, review, and revocation once trust crosses organisational boundaries.
• Identity blast radius: The amount of damage a single identity can cause if it is misused or compromised. For external and non-human identities, blast radius is shaped by privilege scope, system reach, credential lifetime, and how quickly access can be removed once risk appears.
• Lifecycle offboarding: The process of removing access when a business relationship, role, or purpose ends. For third-party and machine identities, offboarding must include credential revocation, entitlement cleanup, and proof that the identity can no longer reach live systems.

What's in the full analysis

Saviynt's full coverage leaves the operational detail for the source:

• The article collection provides the original coverage of the Sisense breach and related supply chain incidents.
• It also surfaces adjacent news items on partner delivery, platform expansion, and identity security updates that sit around the same risk pattern.
• Practitioners who need the vendor's framing of the breach context and associated coverage will find it in the source page.

👉 Saviynt's source page includes the surrounding news items and breach context in one place.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.