Sisense breach shows how supply chain access turns into identity risk

At a glance

What this is: This is a vendor news article about the Sisense breach and the broader rise in supply chain attacks, with identity exposure and third-party access at the centre of the risk.

Why it matters: It matters because IAM, NHI, and PAM teams need to govern third-party and machine access as a live attack surface, not a procurement afterthought.

By the numbers:

• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes, and as quickly as 9 minutes in some cases.

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

Context

Supply chain breaches become identity breaches when external systems, credentials, or delegated access are trusted longer than they should be. In practice, the weak point is often not the primary application but the account, token, or integration path that connects vendors into production workflows.

The Sisense incident fits that pattern because third-party exposure can turn into downstream access amplification very quickly. For identity teams, the question is not whether a supplier was compromised in isolation, but whether the organisation can detect, constrain, and revoke the access that supplier was granted.

Key questions

Q: What breaks when supplier access is not tightly governed in supply chain attacks?

A: Supplier access breaks containment when external identities are given more reach than the business relationship justifies. A compromised vendor account can then act like an internal privileged identity, allowing attackers to move into connected systems, read sensitive data, or reuse credentials across environments. The failure is not only compromise, but excessive trust in delegated access.

Q: Why do third-party credentials create disproportionate identity risk?

A: Third-party credentials often sit outside the normal review cadence, yet they can carry broad access into production systems and SaaS platforms. If they are not scoped tightly and revoked promptly, they become durable entry points for attackers. This is why vendor entitlements should be treated as privileged identities, not low-risk integrations.

Q: How do security teams know whether vendor access is actually under control?

A: Control is real when every external account has a named owner, a documented business purpose, a defined expiry, and a monitored revocation path. If those elements are missing, the access may still function but it is not governed. Evidence of control should come from inventory and review, not from assumptions about the supplier relationship.

Q: Who is accountable when a supplier compromise exposes enterprise data?

A: Accountability sits with the organisation that granted and retained the access, not only with the supplier that was compromised. Governance teams, IAM owners, and system stewards must be able to show why the access existed, who approved it, and how it would have been removed if the business need changed.

Technical breakdown

Third-party identity exposure in supply chain attacks

Supply chain attacks often begin with a trusted vendor relationship rather than a direct attack on the target. In identity terms, that means a supplier’s credentials, API tokens, or integration privileges become the attacker’s first foothold. Once those identities are accepted by downstream systems, the blast radius depends on how much standing access they carry and whether their use is monitored separately from internal accounts.

Practical implication: map every third-party identity to an owner, scope, and revocation path before it reaches production.

Why delegated access becomes an escalation path

Delegated access is useful because it lets suppliers operate without human intervention, but it also creates hidden trust chains. If a vendor account can reach sensitive data, administrative functions, or connected SaaS environments, an attacker who inherits that access can move laterally without needing to break primary authentication. That is why third-party governance must include entitlement boundaries, not just onboarding approval.

Practical implication: review vendor entitlements as if they were privileged internal accounts, because operational convenience often masks elevated reach.

Credential lifetime and offboarding failures

The core technical failure in many supply chain incidents is not initial compromise alone, but the persistence of access after the business need changes. Tokens, keys, and integration accounts can remain valid far beyond the relationship they were meant to support, especially when lifecycle processes are manual or fragmented. That turns a one-time vendor connection into a long-lived attack surface.

Practical implication: tie every external credential to an expiry, owner, and offboarding trigger so stale access cannot survive contract or role changes.

Threat narrative

Attacker objective: The attacker’s objective is to turn a trusted supply chain relationship into a reusable access path into the target environment, enabling broader compromise without directly attacking the primary organisation.

1. Entry occurred through the compromise of a trusted third-party path, allowing attacker access via supplier-linked identity or integration exposure.
2. Escalation followed when delegated access or exposed credentials provided broader reach than the original business function required.
3. Impact emerged as the attack moved from vendor compromise into enterprise-facing risk, expanding the potential blast radius across connected systems.

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

Supply chain breaches are identity failures before they are platform failures. When a supplier is trusted inside production workflows, its credentials and integrations inherit the same privileges as internal identities, even if governance never treated them that way. The lesson for the field is that third-party access must be governed as a first-class identity domain, not an operational exception.

Vendor access without lifecycle offboarding is the named failure mode this pattern exposes. The access path persists because the business relationship and the technical entitlement are not coupled closely enough. That assumption fails whenever third-party credentials remain valid after scope, ownership, or contract changes. Practitioners should recognise that the breach window is often created long before the attacker arrives.

Standing privilege in supplier integrations creates an identity blast radius that conventional reviews miss. Access reviews focused on named users do not reliably surface machine-to-machine and vendor-to-SaaS entitlements, especially when tokens are buried inside service workflows. That makes supply chain compromise hard to contain once it starts. Security teams need to treat external entitlements as privileged assets with explicit expiry and monitoring.

Converged identity governance is now a supply chain control, not just an IAM aspiration. The same governance model has to span human approvers, service accounts, and third-party integrations because attackers increasingly move through whichever identity layer is least visible. This narrows the gap between IAM, NHI, and PAM programmes. Practitioners should align ownership and review across all three or accept repeated blind spots.

52 NHI breach cases show that compromise rarely stays isolated to one credential. The wider pattern is repeated reuse, inadequate scoping, and delayed revocation, which lets a single identity failure cascade into multiple incidents. That is why supplier access should be measured by reach, not just by count. Teams should focus on how far a delegated identity can travel once compromised.

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, which shows how one identity failure often becomes a repeat exposure pattern.
• That is why the next practical step is to treat delegated and machine access as governed infrastructure, which is explored further in Ultimate Guide to NHIs.

What this signals

Vendor identity has become a standing supply chain risk, not a one-time onboarding problem. As supplier access spreads across SaaS and cloud workflows, the control question shifts from trust at approval time to containment at runtime. Teams should expect more breaches where the first compromise is outside the organisation but the blast radius lands inside it.

Supplier entitlements need the same governance discipline as privileged internal access. If an external account can alter data, trigger workflows, or reach sensitive systems, it belongs in the privileged access perimeter. That means ownership, expiry, and evidence-based review, not spreadsheet-level visibility.

The practical signal is simple: if your programme cannot revoke a vendor identity quickly and prove where it was used, it is already behind the threat model. Identity governance now has to cover the full path from supplier onboarding to offboarding, including service accounts and delegated credentials.

For practitioners

• Inventory every third-party identity path Build a complete register of supplier accounts, API tokens, certificates, and delegated integrations that can reach production systems. Assign an owner, business purpose, and revocation method to each one.
• Separate vendor access from internal user reviews Create review workflows that explicitly cover external accounts and machine identities, because standard user recertification usually misses delegated access embedded in service workflows.
• Enforce expiry on vendor credentials Set explicit expiry and renewal requirements for all supplier-issued secrets, and tie renewal to verified business need rather than administrative convenience.
• Monitor third-party entitlements as privileged access Apply alerting to unusual vendor activity, including new geographies, broader API calls, and access to sensitive data sets outside normal service patterns.

Key takeaways

• Supply chain compromise becomes far more dangerous when delegated identities are broad, persistent, and poorly monitored.
• The evidence across NHI research shows that one compromised identity often leads to repeated incidents, not a single isolated event.
• Practitioners should govern third-party access as privileged identity, with ownership, expiry, and revocation built into the lifecycle.

Key terms

• Third-party identity: A third-party identity is an account, token, certificate, or delegated integration owned outside the organisation but trusted inside its environment. It can act with real business privileges, which means governance must cover ownership, scoping, expiry, and revocation just as it would for internal privileged access.
• Delegated access: Delegated access is permission granted to an external party or system to act within a target environment on behalf of a business need. In practice, it often outlives the original purpose, so the security problem is not only who approved it, but how quickly it can be removed when conditions change.
• Identity blast radius: Identity blast radius is the amount of damage an attacker can cause after compromising one identity. The bigger the entitlement scope, the harder it is to contain. This is especially relevant for supplier accounts and machine identities, where a single credential can reach multiple systems or services.
• Lifecycle offboarding: Lifecycle offboarding is the process of removing identities, credentials, and access when the business need ends. For third parties and machine accounts, it must be tied to contract changes, service retirement, or role changes, because access that stays active after offboarding becomes a standing attack path.

What's in the full analysis

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

• The specific incident context behind the Sisense breach and how it relates to supply chain compromise.
• The broader news roundup around identity security, SaaS exposure, and adjacent breach coverage.
• The vendor's own framing of why supply chain attacks are intensifying across enterprise environments.
• The surrounding articles and links that place the breach in Saviynt's broader coverage stream.

👉 Saviynt’s full post places the Sisense breach in the wider context of identity-led supply chain compromise.

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 building or maturing an identity security programme, it is worth exploring.