Sisense breach highlights the rise of supply chain identity risk

At a glance

What this is: This is a Saviynt commentary on the Sisense breach and the wider rise of supply chain attacks, with an identity-security lens on third-party access exposure.

Why it matters: It matters because IAM, IGA, and PAM teams need to treat external access, service credentials, and delegated trust as shared governance surfaces, not isolated vendor problems.

By the numbers:

• 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 analysis of the Sisense breach and supply chain identity risk

Context

Supply chain breaches are identity problems as much as they are vendor risk problems. When an external service, integration, or partner account is compromised, the attacker is usually exploiting trust that was created earlier through credentials, tokens, or delegated access rather than breaking into the target directly.

The Sisense case fits that pattern. For practitioners, the question is not whether third-party access exists, but whether it is lifecycle-governed, least-privileged, and continuously reviewable across NHI, human, and delegated access paths.

Key questions

Q: What breaks when third-party access is not lifecycle-governed?

A: When third-party access is not lifecycle-governed, credentials outlive the business need that created them. That leaves dormant accounts, tokens, or keys available for abuse long after a supplier relationship changes. The failure is not only exposure, but persistence without a revocation trigger, which expands the window for supply chain compromise and downstream movement.

Q: Why do supplier identities increase breach impact so quickly?

A: Supplier identities often connect to multiple systems, so one compromised account can unlock a much larger trust chain than a normal internal user account. If the same credential reaches production, data pipelines, and administration paths, the attacker inherits broad access from a single foothold. That is why third-party identity scope is a blast-radius issue, not a paperwork issue.

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

A: Teams know partner access is under control when every external identity has an owner, a defined purpose, a current business justification, and a tested offboarding path. If any of those are missing, the access is effectively standing privilege. Evidence of control is not the presence of a contract, but the ability to revoke access cleanly and prove it.

Q: Who is accountable when a supplier compromise exposes customer systems?

A: Accountability sits with both the supplier and the customer, but the customer still owns the governance of the trust relationship inside its environment. Security, IAM, and vendor-risk teams need a shared model for approving, scoping, reviewing, and revoking external access. If no one owns the lifecycle, no one owns the exposure.

Technical breakdown

How third-party access becomes an attack path

Supply chain intrusions often begin where a supplier’s environment intersects with a customer’s identity controls. That intersection may involve API keys, tokens, partner service accounts, or authenticated integrations that were intended to narrow access but instead expand trust. Once those credentials are usable, the attacker does not need to defeat the customer’s perimeter. They inherit the trust relationship already established between organisations, which is why third-party compromise so often turns into downstream customer impact.

Practical implication: inventory every externally originated credential and map it to an owner, purpose, and offboarding trigger.

Why standing trust creates long-tail exposure

Standing access is the core problem in many supply chain incidents. A partner credential or integration token can remain valid long after the business need has changed, especially when governance is split across procurement, security, and application teams. That creates a long-tail exposure window where the trusted path remains live even though the operational relationship has moved on. In NHI terms, the compromise is not just the theft of a secret, but the persistence of a secret whose authority outlives its business context.

Practical implication: tie every external secret to a lifecycle event, not just a technical rotation schedule.

How shared trust multiplies blast radius

Supply chain attacks scale because one compromised identity can affect many downstream systems at once. A single integration, account, or secret may connect to multiple environments, making the blast radius larger than teams expect from a standard host compromise. That is why identity segmentation matters as much as network segmentation. If shared credentials are reused across environments, the attacker can pivot from a supplier foothold into customer-facing systems, data pipelines, or administration workflows with minimal friction.

Practical implication: segment partner access by environment, workload, and function so one compromise cannot traverse the whole chain.

Threat narrative

Attacker objective: The attacker wants to turn one compromised supply chain identity into broad downstream access and data exposure.

1. Entry occurs when attackers compromise a supplier or third-party access path that already has legitimate connectivity into downstream environments.
2. Credential abuse follows when exposed secrets, tokens, or partner accounts are used to operate inside trusted systems without triggering obvious perimeter alarms.
3. Impact emerges when the compromised identity grants access to multiple connected services, expanding the breach from one supplier foothold into customer data or operational 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 breach response is now an identity governance problem, not a vendor management sidebar. The Sisense case reinforces a pattern NHIMG has tracked repeatedly: attackers target the trust fabric between organisations, not just the product itself. Once external access is in place, the practical question becomes whether identity governance can still see, scope, and revoke that access quickly enough. Practitioners should treat third-party access as part of the core identity model, not as an exception process.

Vendor access without lifecycle offboarding is the failure mode this class of breach exposes. Access created for a supplier relationship often persists beyond the relationship’s operational need, and that persistence becomes the breach surface. This is a lifecycle gap, not merely a hygiene issue, because the control failure is the absence of a clean offboarding trigger for external identities. Practitioners should assume every live supplier credential is a potential dormant entitlement unless proven otherwise.

Shared credentials create identity blast radius that no network control can fully contain. When one account, token, or integration unlocks multiple downstream services, the compromise propagates through the trust chain rather than stopping at the first system. OWASP-NHI and NIST CSF both point toward tighter ownership, segmentation, and continuous review of non-human access. Practitioners need to reduce the number of identities capable of crossing organisational boundaries.

Third-party identity risk is converging with human IAM and NHI governance under one control problem. Suppliers still rely on human approvals, but the execution layer is often machine identity, API access, or delegated service authentication. That means identity leaders can no longer split governance into separate human and non-human silos when the same business process depends on both. Practitioners should align review, ownership, and revocation across all three actor types.

Runtime trust, not static trust, is the right concept for supply chain identity exposure. The trust relationship is only safe while it is continuously validated against current business need, current scope, and current ownership. Once those conditions drift, the identity becomes a latent access path waiting to be abused. Practitioners should evaluate whether their governance model can detect that drift before an attacker does.

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.
• The average organisation believes more than 1 in 5 of their non-human identities are insufficiently secured, which shows the governance gap is still widely underestimated.
• Read 52 NHI Breaches Analysis for the recurring control failures behind real-world identity compromise patterns.

What this signals

Supply chain identity risk will keep rising until external access is treated as a first-class governance object. The practical move is to unify procurement, IAM, and security operations around the same inventory of external identities so review and revocation happen from a single source of truth. If your programme cannot explain who owns a partner secret, it cannot defend the trust relationship that secret creates.

Identity blast radius is the concept teams should now use to prioritise external access cleanup. A small number of high-reach supplier identities can expose far more than a long list of low-impact accounts, especially where shared credentials span multiple environments. Teams should focus on connected privilege paths, not raw account counts, and use segmentation to shrink cross-environment reach.

The pattern also points practitioners toward broader machine identity governance. With 72% of organisations reporting that they have experienced or suspect an NHI breach, the issue is no longer whether external identities matter, but whether the operating model can keep pace with them.

For practitioners

• Inventory every third-party identity path Build a complete register of partner accounts, service tokens, API keys, and delegated integrations that can reach production systems. Include business owner, technical owner, scope, and the offboarding trigger for each identity.
• Bind supplier access to lifecycle events Require every external credential to map to a contract, project, or support case so revocation is automatic when the business relationship changes. Avoid credentials that remain valid after the original purpose ends.
• Segment partner access by function and environment Separate credentials used for support, data exchange, and administration, and do not reuse the same secret across development, staging, and production. One compromise should not open multiple trust zones.
• Recertify external access on a shorter cadence Review supplier entitlements more frequently than internal user access, because external relationships change faster and often involve broader downstream trust. Confirm that access still matches the current contract and current workload.

Key takeaways

• Supply chain breaches increasingly exploit identity trust paths, not just software flaws or exposed infrastructure.
• The scale of compromised non-human identity risk is already broad, with external access and standing trust creating the most durable exposure.
• Teams should govern third-party identities through lifecycle ownership, segmentation, and rapid revocation before a supplier foothold becomes customer impact.

Key terms

• Third-party identity: A third-party identity is any account, token, key, or integration used by an external supplier or partner to access your environment. It becomes a governance object when its scope, ownership, and revocation path must be controlled as tightly as internal access.
• Identity blast radius: Identity blast radius is the amount of systems, data, or workflows exposed when one credential is compromised. In supply chain scenarios, the blast radius grows when a partner identity is reused across environments or can reach multiple downstream services from one trust path.
• Lifecycle offboarding: Lifecycle offboarding is the process of removing access when the business need ends. For non-human and third-party identities, it must be tied to contract change, project closure, or support termination so access does not persist as dormant privilege.
• Standing privilege: Standing privilege is access that remains continuously valid rather than being granted only when needed. In supplier relationships, standing privilege is especially risky because the account can remain usable long after the original operational purpose has changed.

What's in the full analysis

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

• The specific Sisense breach context and how Saviynt links it to supply chain attack patterns
• Additional examples of recent incidents that reinforce why third-party identity trust is expanding attack surface
• The article's broader news roundup and related security commentary that sits around the Sisense reference
• Saviynt's own framing of why this incident matters for cloud delivery and identity security programs

👉 Saviynt's full post adds the surrounding security news items and the broader context for this breach pattern.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.