Major supply chain attacks show why identity governance must expand

At a glance

What this is: This is an editorial analysis of the Sisense breach and the broader rise of supply chain attacks through identity-linked third-party access.

Why it matters: It matters because IAM and NHI teams must treat third-party integrations, tokens, and service accounts as part of the attack surface, not just the application stack.

By the numbers:

• Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.

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

Context

Supply chain attacks now routinely exploit trust relationships between services, vendors, and integrations rather than only exploiting human user accounts. For IAM and NHI practitioners, that shifts the security question from who logged in to what non-human identity was able to act on behalf of a trusted dependency.

The Sisense breach is a useful trigger for this discussion because it reflects the broader pattern of third-party compromise creating downstream identity risk. That starting point is increasingly typical, not exceptional, and it aligns with the way NHI exposure expands when service credentials, tokens, and delegated access are left outside normal governance.

The risk surface is widening because modern delivery chains depend on APIs, automation, and machine-to-machine trust. When those identities are not inventoried, rotated, and constrained, a compromise in one node can become access across many systems.

Key questions

Q: How should security teams manage third-party non-human identities in supply chain environments?

A: Security teams should inventory every external service account, token, and certificate, assign an owner, and scope each credential to a specific workflow or environment. They should also automate rotation, monitor for unusual use, and remove standing access wherever possible. The goal is to make delegated trust narrow enough that a supplier compromise cannot spread broadly.

Q: What is the difference between third-party risk management and NHI governance?

A: Third-party risk management evaluates the supplier relationship, while NHI governance controls the credentials and machine identities that supplier can use inside your environment. Both matter, but NHI governance is the operational layer that limits what a compromised vendor account can actually do. Without it, the contract may look sound while the access remains overbroad.

Q: When does a supply chain incident become an identity security problem?

A: A supply chain incident becomes an identity security problem whenever the attacker can use a trusted integration, token, or service account to move beyond the original compromise. At that point, the real issue is delegated authority, not just vendor exposure. If the credential is persistent or overprivileged, the blast radius can expand quickly.

Q: Why do non-human identities increase the blast radius of supply chain attacks?

A: Non-human identities often have wider system access than human users because they are built for automation, not interactive use. If those credentials are long-lived or poorly scoped, an attacker can use them to reach data pipelines, cloud control planes, or CI/CD systems. That makes lifecycle governance and least privilege essential containment controls.

Technical breakdown

How third-party access becomes an NHI problem

Supply chain attacks often begin with trusted software, vendors, or integration points that already possess credentials or delegated permissions. Once an attacker lands in that trust zone, the issue is rarely a classic user login. It is usually the misuse of a service account, API token, OAuth grant, certificate, or automation credential that was intended to operate silently in the background. In practice, the exploit path is less about breaking authentication and more about inheriting authority that was never tightly scoped. That is why third-party risk and NHI governance overlap so heavily.

Practical implication: Map every external dependency to the NHIs it can use, then reduce standing privilege and scope.

Why identity blast radius matters more than initial access

In supply chain incidents, the most damaging factor is often the blast radius of the compromised identity rather than the original foothold. A single token or machine account can unlock CI/CD systems, customer data pipelines, monitoring tools, or cloud control planes if entitlements are broad. Identity blast radius is the practical measure of how far one compromised NHI can move before detection or revocation. The smaller that radius, the less a third-party incident can spread laterally across environments. This is where least privilege and task-scoped access become operational controls, not policy language.

Practical implication: Review every privileged integration for excessive scope, and segment access by workflow, system, and environment.

What continuous credential governance changes

Continuous credential governance means the lifecycle of secrets, tokens, and certificates is managed as an ongoing control plane, not a quarterly cleanup task. Rotation, expiry, ownership, and offboarding all matter because supply chain attackers frequently succeed by using credentials that remain valid long after their intended use. In AI and automation-heavy environments, this also includes credentials embedded in pipelines or agent workflows. If the credential can outlive the business process that created it, it becomes a standing liability. Governance has to follow the identity wherever it executes.

Practical implication: Automate rotation, expiration, and revocation workflows for all machine credentials tied to vendors and pipelines.

Threat narrative

Attacker objective: The attacker aims to convert a single trusted dependency into broad, repeatable access across the supply chain.

1. Entry via compromised third-party trust, where the attacker uses a vendor-linked integration or credential path to reach internal systems.
2. Escalation through overprivileged machine access, allowing the attacker to move beyond the initial application into broader identity-controlled assets.
3. Impact through downstream access to connected systems, data flows, or automation paths that inherit the compromised trust relationship.

Breaches seen in the wild

• LiteLLM PyPI package breach — LiteLLM PyPI supply chain attack, credentials stolen from users.
• Shai Hulud npm malware campaign — Shai Hulud campaign: npm malware exposed secrets on GitHub.

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 security is now identity security by another name. The old framing treated third-party risk as a procurement or vendor-management issue. That is no longer sufficient when the practical attack path runs through API keys, service accounts, OAuth grants, and automation credentials. Practitioners need to govern external trust as a live identity problem, not a static contractual one.

Identity blast radius is the right unit of measurement for modern supply chain risk. A compromise is not defined only by how an attacker got in, but by how far the compromised credential can reach before it is revoked. The smaller the blast radius, the less any upstream breach can cascade across applications, data stores, and automation. That makes scoping and segmentation core controls, not optional hardening.

Continuous lifecycle control matters more than one-time inventory. Many organisations can list their machine identities, but far fewer can prove that every secret, token, and certificate has a current owner, expiry, and revocation path. That gap creates persistence for attackers and ambiguity for defenders. The discipline now is to connect discovery, rotation, and offboarding so a trusted dependency cannot become permanent access.

Third-party integrations should be treated as delegated privilege boundaries. When a vendor or partner service can act inside your environment, it effectively becomes part of your identity perimeter. That means security teams should evaluate not only who the vendor is, but what the credential can do, where it can be used, and how quickly it can be disabled. The policy goal is to make delegated trust narrow, visible, and reversible.

Identity governance must adapt to supply chain reality, not ideal architecture diagrams. Most enterprise environments mix legacy accounts, cloud APIs, CI/CD secrets, and emerging AI-driven automation. The result is uneven control coverage across the same trust chain. Practitioners should assume that attackers will look for the least governed identity in the path and design controls accordingly. The programme implication is straightforward: unify governance where the attack paths already converge.

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 quickly one failure can become a pattern.
• For a broader control model, see Ultimate Guide to NHIs for lifecycle, visibility, rotation, and offboarding guidance.

What this signals

Identity governance teams should assume that supply chain risk now lands in their backlog, not just in procurement reviews. The operating model has to expand from application trust to credential trust, because delegated access is what turns a third-party event into an internal incident. With the 2024 ESG Report showing that two-thirds of enterprises have already suffered a successful attack tied to compromised non-human identities, the programme gap is structural, not accidental.

Identity blast radius will become a core design metric for vendor access. If a partner credential can reach multiple environments, the organisation is effectively accepting a larger failure domain than it may realise. Practitioners should begin measuring how far each vendor-linked identity can move, then use that measurement to prioritise segmentation, JIT controls, and stronger revocation workflows.

Delegated trust needs a lifecycle owner. The challenge is not only to discover supplier credentials, but to keep them governed through change, renewal, and offboarding. That pushes NHI management toward more mature ownership models, where the business process, not the tool inventory, defines when access should exist and when it should disappear.

For practitioners

• Implement vendor-linked NHI inventory Build a complete inventory of service accounts, API keys, tokens, and certificates tied to external vendors, partners, and SaaS integrations. Assign ownership, purpose, expiry, and revocation path to each record so third-party trust is measurable rather than implicit.
• Reduce delegated access scope Review every partner and supply chain integration for broad permissions, then narrow each credential to a single workflow, environment, or dataset. Remove cross-environment entitlements where possible so one compromised identity cannot traverse the full production estate.
• Automate credential rotation and revocation Tie rotation and revocation to change events, vendor offboarding, and inactivity thresholds. Prioritise long-lived secrets embedded in CI/CD pipelines, build systems, and service orchestration because those credentials are most likely to survive past their intended use.
• Segment high-risk third-party pathways Place vendor-connected identities behind conditional approval, separate network zones, and tighter monitoring. Use least privilege and JIT access for administrative actions so delegated access can be removed quickly when risk changes.

Key takeaways

• Supply chain attacks increasingly succeed by abusing machine identities, not just by exploiting software flaws.
• The practical measure of exposure is identity blast radius, because one overprivileged credential can cascade across many systems.
• Teams should treat every vendor-linked credential as a lifecycle object that needs ownership, scoping, rotation, and revocation.

Key terms

• Identity Blast Radius: The amount of damage a single identity can cause if it is compromised. In NHI governance, this refers to the systems, data, and workflows reachable by one service account, token, or certificate. Smaller blast radius means less lateral movement and faster containment when trust is broken.
• Delegated Trust: Access granted to one system or organisation so it can act inside another environment on a limited basis. For NHIs, delegated trust is common in integrations, pipelines, and partner services. It becomes dangerous when the permission scope is broad, persistent, or difficult to revoke.
• Non-Human Identity: A digital identity used by software, infrastructure, or autonomous systems rather than a person. It includes service accounts, API keys, tokens, certificates, workloads, bots, and AI agents. These identities often have high privilege and require lifecycle governance, not just authentication controls.

What's in the full analysis

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

• The specific supply chain incidents and third-party exposure patterns the article uses to frame the risk.
• The vendor's identity security context around human and non-human access convergence.
• The article's own operational framing for how teams should think about implementation gaps.
• Any product or platform context that accompanies the security commentary.

👉 The full Saviynt article covers the breach context and the broader supply chain security angle.

Deepen your knowledge

Supply chain identity risk and lifecycle governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for vendor-linked credentials, it is worth exploring.