Sisense breach shows why supply chain identity risk keeps growing

At a glance

What this is: This is Saviynt's coverage of the Sisense breach and the broader rise in supply chain attacks, with the key finding that trusted third-party access can become the entry point for identity-driven compromise.

Why it matters: It matters because IAM teams must govern vendor, service, and workload identities with the same lifecycle discipline they apply to human access, or third-party trust will keep expanding attack surface.

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.
• 72% of organisations have experienced or suspect they have experienced a breach of non-human identities, 46% confirmed and 26% suspected.
• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.

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

Context

Supply chain identity risk starts when a trusted external relationship carries credentials, tokens, or other non-human identities that can be abused if the partner, integration, or connected service is compromised. In practice, that means the attack surface is no longer limited to direct enterprise accounts. The primary issue in this article is the way third-party trust can translate into identity exposure across service and workload access.

Sisense is presented here as part of a larger pattern: attacks increasingly exploit the identity layer that sits between organisations and their suppliers. That is why the question for IAM programmes is not only whether a vendor is secure, but whether its access is bounded, monitored, and offboarded with the same rigour as internal privileged access.

Key questions

Q: What breaks when third-party access is not tightly governed in supply chain environments?

A: The trust relationship itself becomes the attack path. If vendor credentials, service accounts, or API tokens can reach too many systems, a compromise in one supplier can cascade into production access, data exposure, and lateral movement across connected environments. The control failure is usually not a firewall issue. It is weak entitlement scope, missing ownership, and poor offboarding.

Q: Why do supply chain breaches so often become identity problems?

A: Because modern suppliers connect through identities, not just network links. APIs, tokens, certificates, and delegated service accounts carry the permissions that matter most. Once attackers obtain or abuse those credentials, they inherit legitimate access paths that bypass many perimeter controls and look normal to monitoring tools unless identity context is being tracked.

Q: What do security teams get wrong about vendor access reviews?

A: They often review the existence of a relationship instead of the actual identity footprint. A vendor may still be on the approved list while the credentials it used last quarter should already have been revoked, narrowed, or reissued. Reviews need to inspect scope, expiry, and the real systems each external identity can reach.

Q: How should organisations respond when a supplier has already been compromised?

A: Contain the identity path before focusing only on the breach narrative. Revoke exposed credentials, rotate shared secrets, disable dormant integrations, and inspect downstream systems that accepted the supplier's access. The immediate goal is to cut off reused trust, because the attacker usually wins by staying inside the delegated relationship.

Technical breakdown

How supply chain compromise turns into identity exposure

Supply chain compromise often becomes an identity problem once a vendor or integration path contains credentials that can be reused, replayed, or escalated. Non-human identities such as service accounts, API keys, tokens, and certificates are especially attractive because they are designed for machine-to-machine trust and often bypass human-centric controls. If those identities are over-privileged, long-lived, or shared across environments, an attacker can pivot from one compromised partner into multiple downstream systems without needing a fresh login event.

Practical implication: map third-party access to the exact accounts, tokens, and certificates it depends on, then bound each one by least privilege and explicit ownership.

Why delegated access expands blast radius

Delegated access expands blast radius because one compromised relationship can inherit the permissions, data reach, and automation hooks of another. In identity terms, the issue is not just initial compromise. It is the chain of trust that lets a third-party identity act inside an enterprise context with the privileges of a legitimate participant. That is why supply chain attacks increasingly look like access governance failures, not just malware events.

Practical implication: segment vendor entitlements by business function and environment so one third-party compromise cannot cascade across unrelated workloads.

Lifecycle gaps in vendor and machine identity governance

Lifecycle gaps are where many supply chain exposures persist after the original business need has changed. If a vendor integration is not formally offboarded, stale credentials may survive contract changes, platform migrations, or organizational restructuring. The same lifecycle problem applies to machine identities created for short-term integrations but left active indefinitely. Without ownership, expiry, and periodic recertification, the trust relationship outlives the purpose it was meant to serve.

Practical implication: tie every external identity to a named owner, an expiry condition, and a review cadence that forces removal when the relationship ends.

Threat narrative

Attacker objective: The attacker seeks to turn a trusted supply chain relationship into broad enterprise access without triggering normal perimeter or user-focused defenses.

1. Entry occurs through a trusted supplier or connected service whose identity credentials and access paths are already accepted by the target environment.
2. Credential access or abuse follows when those third-party credentials, tokens, or integrations are reused to reach downstream systems without fresh human verification.
3. Impact emerges as the attacker moves through the trusted relationship to expose data, disrupt operations, or extend access into additional connected environments.

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 identity is now part of the attack surface, not a separate trust domain. The Sisense breach sits inside a wider pattern where supplier access, integration credentials, and machine identities are treated as operational conveniences rather than governed identities. That boundary no longer holds when attackers target the trust relationship itself. Practitioners should treat every external connection as a governed identity path, not a procurement footnote.

Supply chain attacks increasingly reveal a lifecycle failure, not just a security control failure. The question is not whether a partner once needed access, but whether that access was ever formally narrowed, reviewed, and retired when the business purpose changed. When vendor credentials remain live after the relationship shifts, accountability outlives the original use case. The implication is that offboarding discipline is now a core supply chain defence.

Vendor trust without privilege segmentation creates identity blast radius. A third-party identity that can reach too many systems turns a local compromise into a cross-environment incident. This is especially true where service accounts, tokens, and API keys are reused across pipelines and production environments. Security teams need to think in terms of containment boundaries, because one trusted integration should never be able to fan out into many.

Service account governance is the hidden control plane in supply chain risk. Many organisations still focus on user access while leaving machine identities outside the same review, attestation, and rotation standards. That creates a governance asymmetry that attackers can exploit through the weakest identity class in the chain. The practical conclusion is that machine identity governance now belongs in the same board-level conversation as third-party risk.

52 NHI Breaches Analysis remains the clearest lens for this category of failure. Supply chain compromises repeatedly show that identity exposure becomes durable when credentials, ownership, and decommissioning are not tied together. The field has enough evidence to stop treating these as isolated incidents. Practitioners should read the breach pattern as a governance design problem, not a one-off event.

From our research:

• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases, according to LLMjacking: How Attackers Hijack AI Using Compromised NHIs.
• Our research also found that enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
• That pattern reinforces the need to pair supply chain oversight with 52 NHI Breaches Analysis when building a containment and offboarding model.

What this signals

Third-party identity debt: supply chain programmes now need to treat external credentials as lifecycle assets with expiry, ownership, and removal rules. When a partner integration survives beyond its business purpose, the risk is not theoretical. It becomes a reusable access path that can outlast the original relationship and widen the blast radius of one compromise.

The operational signal is simple. If a supplier can still authenticate after a contract shift, platform migration, or service retirement, then the organisation has not actually closed the identity path. That is why the most mature programmes are moving third-party access into the same governance model used for privileged machine identities and production service accounts.

For practitioners, the next step is to connect third-party access reviews to identity architecture, not just procurement. Use the NIST Cybersecurity Framework 2.0 to align identify, protect, detect, and recover controls, then use OWASP Non-Human Identity Top 10 to pressure-test the machine identity side of the chain.

For practitioners

• Inventory every third-party identity path Catalogue vendor accounts, API keys, tokens, certificates, and service accounts that connect external parties to internal systems. Record the business purpose, data scope, owner, and expiration condition for each one.
• Segment supplier access by function and environment Separate development, testing, and production permissions so a single partner identity cannot move laterally across unrelated workloads. Keep production access narrow and review it independently of lower-risk environments.
• Enforce lifecycle offboarding for external access Require formal removal of third-party credentials when a contract ends, an integration changes, or a service is retired. Offboarding should include revocation, certificate replacement, and confirmation that dormant access no longer exists.
• Review machine identities with the same rigor as user access Put service accounts and automation credentials into the same attestation and ownership process used for privileged users. Re-certify access on a fixed cadence and treat missing ownership as a removal condition.

Key takeaways

• Supply chain breaches increasingly exploit trusted identities, which means third-party access is now a governed attack surface.
• The scale of the problem is already visible in NHI research, where compromised identities routinely lead to repeated incidents and rapid attacker follow-up.
• The practical control that matters most is lifecycle discipline for external credentials, including explicit ownership, expiry, segmentation, and offboarding.

Key terms

• Third-party identity: An external identity used by a supplier, partner, or contractor to access enterprise systems. It may be a user account, service account, API key, token, or certificate. The governance challenge is that these identities often outlive the business relationship unless they are explicitly owned and retired.
• Identity blast radius: The amount of access, data, and downstream systems that can be reached if one identity is compromised. For third-party and machine identities, blast radius is driven by entitlement scope, reuse, and segmentation. Smaller blast radius means the compromise stops sooner and affects fewer connected systems.
• Lifecycle offboarding: The controlled removal of access when an identity is no longer needed. For non-human identities, that includes revoking credentials, replacing certificates, disabling integrations, and confirming that no dormant access remains. Offboarding fails when the account is deleted on paper but still works in practice.
• Delegated trust: A permission model in which one identity or service is allowed to act on behalf of another. In supply chain environments, delegated trust is necessary for integration but dangerous when scope is broad or duration is indefinite. Governance must tie it to explicit purpose, review, and revocation.

What's in the full analysis

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

• The article's wider news context around Sisense and related supply chain coverage.
• Additional items from Saviynt's news stream that frame how the vendor is positioning identity security.
• The original article page and surrounding updates that situate the breach within current identity-risk coverage.

👉 Saviynt's full page provides the surrounding news context and related identity-security coverage.

Deepen your knowledge

Supply chain identity risk and third-party access governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are building controls around vendor credentials and machine identities, it is worth exploring.