NHI supply chain risk is outpacing traditional IAM controls

At a glance

What this is: This is an analysis of how NHI supply chain exposure emerges through third-party apps, tokens and service accounts, with the key finding that current IAM and TPRM controls often miss or cannot track that access fast enough.

Why it matters: IAM, IGA and PAM teams need to treat third-party NHI access as a governed lifecycle problem, because unmanaged marketplace apps and tokens can create production reach without normal review and offboarding paths.

By the numbers:

• Astrix Security reports that 1 in every 10 OAuth apps connected to Google Workspace are connected with a highly-privileged, administrative account.
• Astrix Security notes that current detection and containment timelines can leave attackers moving inside an environment for 204 days before identification and 73 days more before containment.

Context

NHI supply chain risk describes the governance gap that appears when third-party apps, tokens, service accounts and other programmable credentials gain access to production environments faster than security teams can inventory, approve or revoke them. In this article, the primary issue is not ordinary user access but non-human access that enters through vendors, marketplaces and integrations without the control depth applied to human IAM.

That matters because traditional IAM programmes were designed around known users, known owners and reviewable entitlements. When the access path is an OAuth consent, a marketplace app or a service account embedded in a supplier workflow, the control model becomes fragmented across IT, security, business teams and vendors, which is exactly where attack paths widen.

Key questions

Q: What fails when third-party non-human access is approved like normal vendor software?

A: The failure is that the approval is treated as a one-time procurement decision instead of a governed access lifecycle. OAuth apps, tokens and service accounts can keep operating long after the original review, so the environment ends up with standing third-party reach that nobody is actively certifying.

Q: Why does third-party NHI access create more risk than a standard vendor questionnaire suggests?

A: Because questionnaires describe the vendor, not the live permissions inside your environment. A supplier can look acceptable on paper while still holding administrative OAuth scopes, production tokens or service accounts that materially widen the attack surface.

Q: What are the signs that NHI governance is failing in an enterprise?

A: Common warning signs include unclear ownership for service accounts, secrets stored in code or configuration instead of managed vaults, infrequent rotation, and weak offboarding of API keys. Other red flags are excessive permissions, third-party exposure without controls, and low visibility into where non-human identities exist or how they are used across the stack.

Q: Who should own non-human identity risk in an enterprise?

A: Non-human identity risk should be owned jointly by IAM, PAM, cloud, and platform teams, with clear accountability for inventory, entitlement scope, rotation, and retirement. If ownership sits only with operations or only with security, NHIs tend to stay embedded in workflows without lifecycle control or auditable decision-making.

Technical breakdown

Why third-party non-human access evades traditional IAM controls

Non-human identities often enter an environment through app consent, integration setup or service-account provisioning, not through a human login flow. That means the access grant is tied to a machine credential or delegated token that can operate continuously until revoked, regardless of whether the original approver still remembers it exists. Traditional IAM tools are better at authenticating users than at continuously governing app-to-app permissions, consent scope and downstream reuse. The result is an access layer that can be both highly privileged and weakly visible, especially when the identity is created outside the core identity lifecycle process.

Practical implication: Practitioners need separate control paths for third-party NHI consent, inventory and revocation instead of relying on user IAM workflows.

How OAuth tokens and service accounts create supply chain blast radius

OAuth tokens, service accounts and similar credentials are dangerous in supply chain scenarios because they often inherit trust from the parent vendor or connected application. Once a third-party actor is approved, that trust can extend into production systems, issue trackers, source-code repositories or collaboration platforms without another approval decision. This turns a single compromise into a many-to-one attack path: one supplier or one integration can expose many customer environments. The technical problem is not only credential theft, but also credential scope that is broader than the business owner understands and more persistent than incident-response teams expect.

Practical implication: Map every third-party credential to its actual downstream scope so privileged integrations can be isolated before they become a shared blast radius.

Why TPRM snapshots fail in dynamic integration ecosystems

TPRM questionnaires capture a point-in-time answer about a vendor, but NHI supply chain risk changes as permissions, users, scopes and installed apps change inside the environment. In a dynamic SaaS or cloud ecosystem, the relevant question is not whether the supplier passed a review last quarter, but whether the active integration still matches the approved scope today. Because many platforms expose consent and app inventories differently, teams end up stitching together logs, dashboards and admin screens after the fact. That creates a governance lag that attackers can exploit between assessments.

Practical implication: Shift from periodic vendor assessment to continuous permission monitoring for live third-party integrations and app consents.

Threat narrative

Attacker objective: The attacker wants to turn trusted third-party access into durable reach inside production systems and adjacent collaboration or source-code environments.

1. Entry occurs when a third-party app, token or service account is introduced into the environment through marketplace consent, vendor integration or compromised supplier access.
2. Credential access follows when the attacker uses or steals the non-human credential to operate with the permissions already granted to the integration.
3. Escalation occurs when the credential’s scope reaches production tenants, source code, collaboration tools or other high-value systems, widening the blast radius.
4. Impact is the compromise of customer data, internal documentation, issue trackers or administrative environments through trusted third-party 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.
• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.

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 NHI exposure is now a supply chain control problem, not a niche integration issue. The article shows that OAuth apps, service accounts and marketplace tools can enter production with very little governance, then remain active outside the visibility of the teams expected to own them. That shifts the problem from user IAM into lifecycle governance for external machine access. The practitioner implication is that NHI inventory and ownership must extend beyond internal systems to every supplier-managed access path.

Standards-based IAM controls break down when the access subject is not a person. Human IAM assumes a user can be authenticated, reviewed and re-certified through a predictable lifecycle. Third-party NHI access does not behave that way because consent, token scope and service-account delegation can outlive the people who approved them. The implication is a stronger separation between human identity governance and non-human delegation governance, with consent scope treated as a first-class control surface.

Dynamic permissions create an identity blast radius that TPRM questionnaires cannot measure. The article correctly points out that questionnaires and annual reviews only capture a snapshot, while the real risk changes as scopes, users and connected apps shift. That means vendors and integrators can look acceptable on paper while operating with production-reaching access in practice. Practitioners should treat live permission state, not vendor attestations, as the governing fact.

1 in 10 highly privileged OAuth apps is enough to invalidate confidence in casual app approval models. Astrix Security’s reported concentration of administrative OAuth apps in Google Workspace illustrates how quickly privileged third-party access can accumulate in everyday collaboration tooling. This is not a visibility nuisance, it is a structural control failure in delegated access governance. The practitioner conclusion is that privileged app approvals need the same scrutiny as administrative human access.

Vendor trust must be reconstructed as a lifecycle issue, not a procurement issue. The article’s core message is that security teams cannot stop at who the vendor is or whether the vendor passed a review. They need to know which non-human credentials the vendor can exercise, how those credentials are owned, and when they are removed. That makes offboarding, permission drift and exposure mapping the real controls that matter for supplier-connected NHI risk.

From our research library:

• NHIs outnumber human identities by 25x to 50x in modern enterprises, according to the Ultimate Guide to NHIs.
• 59% of compromised machines in a major 2025 supply chain attack were CI/CD runners rather than personal workstations, according to the State of Secrets Sprawl 2026.
• Read next: Ultimate Guide to NHIs — Key Challenges and Risks

What this signals

Identity blast radius: The governance problem is no longer limited to who can log in, but to which non-human credentials can carry production reach through third-party integrations. That shift pushes NHI programmes toward live permission state, offboarding discipline and explicit ownership for supplier-connected access.

Traditional TPRM was built for periodic vendor assessment, but supply chain NHI risk is governed by consent drift, scope expansion and hidden app installations. Security teams should expect attackers to exploit whatever third-party access is easiest to approve and hardest to inventory, which makes continuous NHI visibility more important than annual questionnaires.

For practitioners

• Map third-party NHI consent paths Build an inventory of OAuth apps, marketplace integrations, service accounts and tokens that can reach production systems, then assign an internal owner for each one.
• Review administrative NHI privileges Identify non-human credentials with administrative scope and verify whether they actually need write access, tenant-wide permissions or access to source code and collaboration tools.
• Replace snapshot vendor reviews with live monitoring Track permission changes, new app installs and scope expansions continuously so risky third-party access is visible before an incident forces discovery.
• Separate supplier access from human IAM workflows Route consent, approval and revocation for non-human access through a dedicated governance process instead of human user onboarding or generic service-request queues.

Key takeaways

• NHI supply chain exposure is driven by third-party apps, tokens and service accounts that can reach production faster than IAM and TPRM controls can track.
• The article points to real operational scale, including privileged OAuth apps and breach response windows that stretch far beyond what incident teams can comfortably manage.
• The practical response is to govern third-party access as a live lifecycle problem, with inventory, ownership, consent scope and revocation all under continuous control.

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.
• Consent drift: The condition where an action remains technically permitted even though the user’s original consent no longer clearly covers what the agent is doing. It is a governance failure, not just a logging gap, because the workflow can expand beyond its approved boundary while still passing policy checks.
• 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.
• Delegated access lifecycle: Delegated access lifecycle is the governance of non-human components that act on behalf of others, including onboarding, permission scoping, recertification, and offboarding. For MCP servers, it means treating the server itself as a governed identity object with a defined blast radius.

Deepen your knowledge

NHI governance, machine identity security, and identity lifecycle management 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.