Supply chain NHI security is a governance problem, not a trust problem

At a glance

What this is: This is an analysis of why supply chain NHI exposure is primarily a governance problem, with third-party credentials, tokens, and service accounts persisting beyond the business relationship.

Why it matters: It matters because IAM, PAM, and NHI programmes have to govern external machine identities, not just internal users, if they want to limit lateral movement and revoke access fast enough.

Context

Supply chain NHI security covers the credentials, tokens, service accounts, certificates, and keys that third parties use to reach your systems. The control problem is not whether external access exists, but whether that access is discoverable, governed, and revocable across the full relationship lifecycle.

In this article, Clutch Security argues that modern supply chain security breaks down when organisations treat third-party access as a trust question instead of an identity governance question. The core issue is that external machine identities often outlive contracts, integrations, and operational need, creating an access estate that security teams do not fully own.

CircleCI’s 2022 breach is used as the clearest example of the pattern. It is a typical illustration of a supply chain NHI failure, not an edge case, because the same lifecycle and revocation weaknesses appear wherever vendors manage authenticated access on behalf of customers.

Key questions

Q: What breaks when NHI access lifecycle ownership is unclear?

A: Access tends to persist beyond its intended use because no one is accountable for revocation, rotation, or certification. In practice, that creates orphaned secrets, duplicated approvals, and blind spots across cloud and on-prem systems. The control failure is not just technical. It is the absence of a named owner for each lifecycle step.

Q: Why do vendor credentials create such a large supply chain risk?

A: Because they often grant authenticated access that bypasses normal perimeter checks and can persist across many connected services. A single credential may reach multiple systems, which means compromise can spread through legitimate trust rather than noisy exploitation. The larger the integration graph, the larger the blast radius.

Q: How should security teams detect when third-party access is drifting out of scope?

A: Look for access that no longer matches the approved business function, such as a vendor calling systems they were not assigned to, operating outside expected hours, or using credentials after an integration should have been retired. Drift is often visible before compromise if access patterns are baseline-driven.

Q: What should organisations do when a vendor relationship ends but credentials still exist?

A: Treat it as an offboarding event, not a low-priority housekeeping task. Revoke the credentials, confirm they are removed from connected systems, and verify that downstream integrations no longer trust them. If the organisation cannot do that quickly, the relationship is still technically alive.

Technical breakdown

Why third-party NHIs become invisible access paths

Third-party NHIs are external machine identities such as OAuth tokens, API keys, partner service accounts, and vendor-managed certificates. They are invisible in the sense that the customer often cannot see where they are stored, how they are rotated, or who can still use them after a relationship changes. That makes them different from internally governed workloads: the identity may be authorised into your environment, but operational control sits outside your perimeter. In practice, this creates a delegated trust model that often persists well beyond the original business purpose.

Practical implication: Map every externally issued credential to an owner, purpose, and expiry condition so hidden access does not become permanent access.

How integration sprawl turns one compromise into many

Integration sprawl creates chained dependency between vendors, SaaS platforms, and customer systems. Once a third party has authenticated access, a compromise in that provider can become a routed path into multiple connected environments, especially when tokens are reused across APIs or connected services. The technical risk is not just exposure of one secret, but the ability to pivot through legitimate sessions and credentials that still look normal to downstream systems. That is why supply chain NHI incidents often produce broad blast radius rather than isolated compromise.

Practical implication: Trace transitive trust paths across vendors and integrations so one compromised identity cannot silently reach multiple connected systems.

Why revocation is the decisive control in third-party identity security

Revocation is the control that determines whether third-party access ends when the relationship ends. When vendors manage their own credentials, customer teams frequently lose the ability to invalidate tokens quickly across all systems, which leaves dormant but still active access in place. That is a lifecycle failure, not just an operations issue. Security programmes that rely on periodic review without immediate revocation capability are assuming the threat window is long enough to observe. For supply chain NHIs, that assumption often fails because the access can remain valid after the business need has disappeared.

Practical implication: Build rapid, cross-system revocation paths for third-party credentials before a vendor incident forces you to use them.

Threat narrative

Attacker objective: The attacker aims to turn trusted third-party access into authenticated reach across multiple customer systems without triggering normal access controls.

1. Entry begins when a third-party credential, token, or vendor-managed session remains valid inside the supply chain trust boundary.
2. Escalation occurs when the attacker abuses that authenticated access to reach connected systems and legitimate integration paths.
3. Impact follows as the compromised identity is used to exfiltrate secrets, pivot across linked services, or persist through dormant access.

Breaches seen in the wild

• 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.
• LiteLLM PyPI package breach: LiteLLM PyPI supply chain attack, credentials stolen from users.

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 NHI risk is an identity governance problem because the customer rarely controls the full credential lifecycle. The vendor may own storage, rotation, and usage of tokens or service accounts, but the customer still bears the business risk when those credentials connect into enterprise systems. That split responsibility means discovery, ownership, and revocation have to be treated as governance primitives, not optional hygiene. The practitioner implication is that third-party access must be managed as a governed identity estate, not an informal integration layer.

Vendor access without lifecycle offboarding is the failure mode this article exposes. The access relationship may be valid at onboarding, but it often remains active after the contract, project, or operational need has ended. That creates a dormant access pool that normal review cycles do not reliably remove. The implication is that offboarding for vendors has to be as explicit as joiner-mover-leaver governance for internal identities, because the access path itself can outlive accountability.

Trust relationship persistence is the named concept that best captures the supply chain problem. The article shows that authenticated access often survives business purpose, contract changes, and even security incidents. That persistence matters more than the initial grant because the risk is created by access that no longer has a living owner. The practitioner implication is that identity governance must measure not only who has access now, but whether that access still has a defensible reason to exist.

Zero Trust does not solve third-party NHI governance by itself. Treating external access as untrusted helps, but it does not answer who owns the credential, how it is revoked, or what happens when a vendor controls the lifecycle. Zero Trust controls become stronger only when paired with vendor NHI governance and rapid revocation. The practitioner implication is that policy boundaries without credential governance still leave an exploitable supply chain trust layer.

Shared responsibility models are now an identity control requirement, not just a contract concept. Supply chain NHI security depends on who can rotate, monitor, and revoke third-party credentials under pressure. Without explicit responsibility for those tasks, organisations inherit the blast radius without inheriting the controls. The implication for practitioners is to write governance terms that bind technical identity operations to business relationships, not just to legal language.

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.
• Breaches involving third parties rose to 48% of all breaches, a 60% increase on the previous year, according to Verizon's 2026 Data Breach Investigations Report.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Trust relationship persistence: Supply chain NHI programmes fail when access remains valid after the business reason disappears. That is the signal to shift from periodic review to relationship-based offboarding, because the control gap is temporal as much as technical.

Organisations that manage external identities well will increasingly separate vendor onboarding from vendor access governance. The deciding factor is no longer whether a partner needs access, but whether the organisation can prove who can revoke it, under what conditions, and across which systems.

The supply chain domain also exposes how little value a pure visibility programme has if revocation is slow. Discovery matters, but only because it supports ownership and termination decisions that actually close the trust path.

For practitioners

• Inventory third-party credentials Identify every OAuth token, API key, partner service account, certificate, and vendor-managed secret that can reach enterprise systems. Record the business purpose, system scope, owner, and expiration condition for each one.
• Define vendor offboarding triggers Require explicit deprovisioning criteria for every external identity so access ends when a contract, integration, or service need ends. Tie those triggers to operational ownership, not only procurement status.
• Create rapid revocation paths Ensure security teams can invalidate third-party credentials across all connected systems without waiting on the vendor’s internal process. Test revocation as an incident response capability, not a documentation exercise.
• Monitor for abnormal vendor behaviour Baseline third-party access patterns and alert on unusual geography, timing, API call volume, or secret use. Vendor access is often predictable enough that deviations should stand out quickly.
• Map transitive trust relationships Trace how one vendor’s authenticated access can reach downstream SaaS, cloud, and partner systems. Prioritise the relationships that create the broadest blast radius if a single credential is compromised.

Key takeaways

• Supply chain NHI risk is driven by authenticated third-party access that often survives beyond the business relationship.
• The CircleCI breach illustrates how stolen session tokens can expose customer secrets and widen the blast radius through legitimate access paths.
• The decisive control is lifecycle governance, especially discovery, offboarding, and rapid revocation across connected systems.

Key terms

• 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.
• Trust Relationship Persistence: Trust relationship persistence is the condition where third-party access continues to work after the business need has changed or ended. In practice, it creates dormant but still valid credentials that can be abused later. The risk is highest when offboarding is manual, ownership is unclear, or revocation depends on another organisation’s process.
• Transitive trust: The hidden risk created when one trusted app inherits confidence from another trusted relationship. In SaaS environments, approving a third-party tool means trusting its hosting, storage, developers, and connected services, which widens the attack surface beyond the original login event.
• Immediate revocation: Immediate revocation means a credential stops working as soon as the system marks it invalid. For machine identities, this matters because any delay creates a residual exposure window, which can be enough for continued abuse after access should have ended.

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.