TL;DR: Sisense’s breach underscored how third-party access and supply chain compromise can expose downstream identity and data environments, with Saviynt highlighting the incident alongside broader attack trends. The lesson is that dependency trust, not just internal control strength, now determines the blast radius of modern identity programmes.
At a glance
What this is: This is an analysis of how the Sisense breach reflects a broader supply chain attack pattern that exposes identity dependencies through third-party access and downstream trust relationships.
Why it matters: It matters because IAM, NHI, PAM, and third-party governance programmes have to account for delegated access paths that can expand blast radius far beyond the original compromise.
Context
Supply chain identity risk appears when a trusted third party gains access that is broader, longer-lived, or less visible than the owning organisation expects. In practice, that means a compromise can enter through a supplier relationship and then reach tokens, credentials, service accounts, or connected systems that were never meant to be exposed.
The Sisense breach sits in that pattern. For identity teams, the key issue is not only the original intrusion path but the governance model behind external access, because delegated trust can outlive the relationship that justified it and can expand the blast radius across multiple environments.
Key questions
Q: Where does third-party access fail in supply chain breaches?
A: It fails when external identities are granted broad downstream reach without tight lifecycle ownership. If a supplier account, token, or integration identity can continue to operate after the business relationship changes, the attack surface persists long after the original approval. The failure is governance drift between access grant, monitoring, and revocation.
Q: Why do supplier identities increase the blast radius of a cyberattack?
A: Supplier identities increase blast radius because they extend trust beyond the core enterprise and often carry access into systems that internal teams do not monitor as closely. If those accounts are over-permissioned or not offboarded promptly, attackers can use them to move laterally, blend in, and reach high-value operational systems. The risk is structural, not incidental.
Q: What are the signs that production NHI governance is too weak?
A: Common warning signs include shared service credentials, secrets that remain valid across deployments, metadata access that is broadly reachable from workloads, and service accounts with permissions unrelated to their runtime function. These indicators show that identity scope and identity lifetime are still being treated as operational conveniences rather than governed controls.
Q: How should teams reduce identity risk in cloud supply chain attacks?
A: Start by inventorying every developer and automation identity that can reach repositories, build systems, and cloud roles. Then remove unnecessary permissions, segment trust between environments, and monitor for unusual token use or role assumptions. The goal is to make stolen credentials less reusable across the delivery chain and to shrink the blast radius of any one compromise.
Technical breakdown
Third-party access becomes an identity path of attack
Third-party access is not just a procurement or vendor-risk issue when the external party holds credentials or connected access into production environments. In supply chain attacks, the attacker often targets the weakest upstream link, then uses that relationship to reach downstream systems that trust the supplier. For identity governance, that means the access path itself becomes part of the attack surface. The problem is not only whether the external account is authenticated, but whether its privileges, scope, and lifecycle are tightly bounded to the business purpose it was granted for.
Practical implication: Map every third-party identity to its business owner, privilege scope, and offboarding trigger.
Why machine identities amplify supply chain exposure
Machine identities such as service accounts, tokens, and API credentials frequently sit inside pipelines, integrations, and support workflows where humans do not see them day to day. That creates hidden trust between systems, and supply chain attacks exploit exactly that invisibility. When an external compromise reaches a CI/CD runner or shared integration account, the attacker may inherit access that looks legitimate to downstream controls. The control gap is not simply exposure; it is the lack of lifecycle discipline around non-human credentials that cross organisational boundaries.
Practical implication: Treat externally reachable machine credentials as shared blast-radius assets, not isolated technical utilities.
Dependency trust, not perimeter strength, defines blast radius
In modern identity environments, the effective perimeter is the trust graph connecting suppliers, automation, workloads, and human administrators. A supply chain compromise does not need to defeat every internal control if the trust relationship already grants access to sensitive data or administrative workflows. That is why blast radius becomes the central design variable: once a supplier identity is trusted too broadly, the downstream exposure is determined by inherited permissions rather than the original point of entry.
Practical implication: Review supplier trust paths as blast-radius controls, not just onboarding paperwork.
Threat narrative
Attacker objective: The attacker wants to convert upstream supplier access into downstream reach across identity-linked systems, data, and operational environments.
- Entry begins through a trusted supplier or integrated service relationship rather than a direct assault on the target environment.
- Credential access follows when the attacker reaches machine identities, tokens, or support-linked access that the supplier environment is allowed to use.
- Lateral movement occurs as the compromised trust path extends into connected systems that accept the supplier's identity as legitimate.
- Impact comes when the attacker uses that inherited access to expose data, credentials, or operational systems downstream from the original breach.
Breaches seen in the wild
- Sisense breach 2024: A credential in Sisense's GitLab reportedly opened S3 buckets of customer tokens, passwords and certificates; CISA urged a full reset.
- reviewdog Action compromise 2025: A stolen maintainer token poisoned reviewdog/action-setup, leaking CI secrets including the tj-actions bot token used in the next attack.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Supply chain identity risk is now a third-party governance problem, not just a vendor security problem. The breach pattern shows that organisations are inheriting access paths they do not fully control but are still accountable for. When third-party access exists, the real question is whether the access lifecycle, scope, and revocation model are governed with the same discipline as internal identities. Practitioners should treat external trust as an identity programme issue, not an exception.
Identity blast radius is the right concept for analysing supplier compromise. Traditional vendor-risk reviews focus on assurance, but supply chain attacks expose how far a supplier identity can travel once it is trusted. That travel distance is what determines whether a compromise stays local or becomes a multi-system event. The implication is that governance needs to measure exposed reach, not just approved access.
Third-party NHIs create hidden persistence when lifecycle controls are weak. Access granted for integration or support often remains active longer than the business relationship that justified it. That persistence makes recovery harder because revocation is not tied tightly enough to ownership changes, contract end dates, or service retirement. Practitioners should assume that unmanaged external machine identities will outlive the risk review that approved them.
Supply chain compromise collapses the assumption that internal controls can contain external trust. Internal least-privilege design does not help if a supplier account arrives pre-authorised with broad downstream reach. The article reinforces that control boundaries must be drawn before trust is granted, not after a compromise is discovered. Teams should redesign external access governance around bounded delegation and explicit revocation points.
OWASP-NHI and zero trust models converge on the same lesson here: access must be continuously bounded. The article's core signal is that suppliers, CI/CD runners, and integration accounts operate as first-class identities with security consequences. That means governance has to align ownership, inventory, and revocation across the full lifecycle of external credentials. Practitioners should close the gap between trust assignment and trust withdrawal.
From our research library:
- 92% of organisations expose NHIs to third parties, raising concerns about supply chain security, according to the Ultimate Guide to NHIs.
- Read next: NHI Lifecycle Management Guide
What this signals
Identity blast radius: supply chain risk is no longer measured only by whether a supplier is trusted, but by how far that trust can travel once an external identity is compromised. Teams should use third-party access reviews to answer a harder question: which downstream systems inherit the supplier's trust, and can that reach be revoked cleanly?
The operational test is whether external machine identities can be removed without leaving orphaned access in pipelines, integrations, or support channels. If revocation is slower than delegation, the programme has already lost control of the trust boundary. That is why third-party lifecycle governance has to be treated as a core identity control, not a vendor-management side task.
For practitioners
- Map third-party identities to business owners Create a complete inventory of external accounts, tokens, service identities, and integration credentials, then assign a named internal owner for each one.
- Bound supplier privileges to specific workflows Restrict external access to the minimum systems, APIs, and data paths needed for the approved use case, and separate support access from production access.
- Tie revocation to contract and role changes Remove supplier access when the business relationship changes, not only when a periodic review is due, and verify that offboarding closes machine as well as human access.
- Audit CI/CD runners and integration tokens Check whether build runners, automation accounts, and shared tokens can reach sensitive repositories, secrets, or customer environments beyond their stated purpose.
Key takeaways
- Supply chain breaches expose a governance problem when third-party identities retain access that exceeds the business purpose for which they were approved.
- The article's cited trends show that supplier exposure is common, and CI/CD runners can become part of the compromise path rather than just endpoints.
- The most effective control is not broader monitoring alone but tighter ownership, narrower delegated privilege, and lifecycle-linked revocation for external access.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 — Vulnerable Third-Party NHI | The article centres on supplier access as the breach path and blast-radius driver. |
| NHI-05 — Overprivileged NHI | The breach pattern depends on external identities carrying more privilege than their purpose requires. | |
| NHI-01 — Improper Offboarding | The article's governance problem includes access that can outlive the supplier relationship. | |
| Recommendation — Inventory third-party NHIs and constrain their access to the smallest possible downstream scope. Reduce third-party privilege to the minimum needed for each approved integration or workflow. Tie offboarding to contract changes and verify that all external machine access is revoked. | ||
| NIST SP 800-53 Rev 5 | AC-6 — Least Privilege | Least privilege is the main control principle for limiting supplier blast radius. |
| Recommendation — Apply AC-6 to third-party accounts so supplier access cannot exceed its authorised purpose. | ||
| MITRE ATT&CK | TA0006; TA0008 — Credential Access; Lateral Movement | The attack pattern involves credential theft and movement through trusted supplier paths. |
| Recommendation — Map supplier compromise paths to TA0006 and TA0008 to prioritise exposed trust relationships. | ||
Key terms
- Identity Blast Radius: The amount of damage a compromised identity can cause across systems, data, and infrastructure. In NHI environments, it is shaped by permissions, network reach, and administrative capability rather than by the credential alone. Reducing blast radius is a containment strategy that limits lateral movement and data exposure.
- Third-Party NHI: Third-Party NHI is a non-human identity owned or operated by an external organization, partner, contractor, or supplier. It includes service accounts, API keys, certificates, tokens, and automated agents that access systems outside the primary enterprise boundary. Governance must cover issuance, scope, monitoring, revocation, and contractual accountability.
- 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.
- LifeCycle Revocation: Lifecycle revocation is the process of removing identity access when a user, contractor, service, or certificate is no longer authorised. In mature programmes it is not a single event, but a verified chain across systems, making sure old privileges disappear everywhere they were previously accepted.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on June 24, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org