TL;DR: Third-party credentials, SaaS tokens, and vendor accounts are often provisioned once and rarely re-evaluated, which lets attackers inherit broad reach and move quickly across environments, according to Zero Networks. Point-in-time onboarding controls are not enough when third-party access outlives the relationship that created it; continuous reachability governance is the real containment problem.
At a glance
What this is: NHI Mgmt Group's analysis, drawing on Zero Networks's blog post: Third-party access governance is failing as a supply chain control because access is usually provisioned once and rarely re-evaluated.
Why it matters: IAM, PAM, and NHI teams need to treat vendor reachability as a living control surface, because stale third-party access turns external trust into internal exposure.
By the numbers:
- 78% say third-party and supply chain vulnerabilities are their #1 barrier to becoming cyber resilient.
- It takes almost eight months to resolve just 50% of weak passwords and permission misconfigurations for third parties.
Context
Third-party access governance is the discipline of controlling what vendors, contractors, integrations, and external identities can actually reach inside an enterprise. The problem is not onboarding alone, but the fact that access often persists after the business need changes.
In this article, Zero Networks argues that third-party trust becomes dangerous when it is broad by default and rarely revisited. That framing maps directly to NHI governance, because many third parties authenticate with accounts, tokens, and service access that behave like long-lived non-human identities.
The operational question for practitioners is not whether third parties should exist in the environment. It is whether their access is continuously scoped, visible, and revocable enough to prevent downstream compromise from turning into enterprise-wide exposure.
Key questions
Q: What breaks when third-party access is not reviewed continuously?
A: The break is that access stays active long after the business relationship, vendor task, or application purpose has changed. Without continuous review, teams rely on outdated certifications that do not reflect live permissions. The result is uncontrolled delegated access, especially across SaaS and OAuth-connected systems.
Q: Why do third-party credentials increase supply chain risk?
A: Third-party credentials increase supply chain risk because they often combine standing privilege with broad operational reach. A vendor token or support account may touch production systems, sensitive data, or automation workflows. If that identity is stolen or misused, the attacker does not need to defeat your primary perimeter first. They can operate through an allowed path.
Q: How should organisations govern third-party access in regulated environments?
A: They should review third-party access as a separate governance stream with its own owners, expiry rules, and evidence trail. Third-party entitlements often outlive the business need that created them, which makes them harder to defend in audit and harder to contain when the relationship changes.
Q: When should organisations replace standing privilege with just-in-time access?
A: Organisations should replace standing privilege with just-in-time access whenever elevated access is not required continuously. JIT reduces the time window in which credentials can be abused, especially for admin tasks, break-glass use, and sensitive automation. It works best when paired with approval, expiry, and logging so temporary access does not become another form of standing privilege.
Technical breakdown
Why third-party credentials become a lateral movement path
Third-party access is often created with the broadest plausible scope, because teams optimise for onboarding speed and business continuity. Once a vendor login, contractor VPN account, OAuth token, or integration credential exists, an attacker who compromises it inherits the permissions already attached to it. The technical issue is not just authentication, but reachability: what systems the identity can touch after login, and whether that path is constrained by segmentation or policy. Without that second layer, one stolen credential becomes a route across the environment rather than a single account compromise.
Practical implication: map the post-login reach of every third-party identity, not just the fact that it can authenticate.
How Zero Trust changes third-party access control
Zero Trust Architecture shifts the control point from trust in the identity to trust in each connection. For third parties, that means access should be scoped to a predefined slice of resources, with microsegmentation and identity-based policy preventing movement beyond the approved boundary. This is especially important for vendors and integrations because the initial relationship may be legitimate even when the later activity is not. The architectural aim is to make compromise locally contained, so that an external identity cannot traverse into unrelated systems simply because it authenticated successfully.
Practical implication: pair identity policy with segmentation so a third-party credential cannot become a broad network route.
Why point-in-time onboarding fails for SaaS integrations and service accounts
Many organisations treat third-party governance as a one-time approval event, but integrations evolve faster than annual reviews or contract cycles. OAuth tokens, API keys, and vendor accounts can accumulate quietly across environments, while ownership drifts away from the team that originally approved them. That creates a governance gap between initial authorisation and current business reality. Real-time visibility is therefore not a nice-to-have; it is the only way to know what an external identity can still reach, especially when the relationship that justified access has already changed or ended.
Practical implication: inventory third-party reach continuously and tie revocation to current ownership, not historical approval.
Threat narrative
Attacker objective: The attacker aims to turn trusted third-party access into downstream compromise across internal systems and data.
- Entry occurs through a trusted third-party credential, SaaS token, or vendor account that was granted legitimate access earlier in the relationship.
- Escalation happens when the compromised identity inherits broad internal reach and the attacker uses that reach to move laterally beyond the original third-party scope.
- Impact follows when the attacker uses the inherited access to expose downstream systems, widen compromise, or turn a vendor foothold into supply chain intrusion.
Breaches seen in the wild
- Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
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
Third-party access has become an identity governance problem, not just a vendor management problem. The article correctly shows that once a vendor, contractor, or integration is inside the environment, the real risk is what that identity can still reach after business need changes. That shifts the control objective from onboarding assurance to ongoing reachability governance. Practitioners should treat third-party access as a lifecycle asset, not a one-time approval.
Point-in-time third-party approval is a structurally incomplete control. The article exposes a recurring failure mode: security teams validate access at entry, then lose sight of accumulated OAuth tokens, vendor accounts, and integration sprawl. That is the governance gap attackers exploit. The implication is that access decisions for external identities must be continuously re-authorised against current reach, current owner, and current business purpose.
Third-party access is where NHI, PAM, and Zero Trust converge. Many external identities are functionally non-human identities even when a person is behind them, because the risk lives in the credential, token, or account lifecycle. Microsegmentation, JIT privileged access, and identity-based policy only matter if the external identity itself is governed as a living access object. Practitioners should align vendor access with the same lifecycle discipline used for other NHIs.
Continuous reachability governance is the right named concept for this problem. The article makes clear that what needs governing is not just who was approved, but what remains reachable right now. That is a different control model from periodic review, because it assumes the environment and the relationship both change faster than manual recertification. Security teams should design for revocation, containment, and ownership drift as first-class governance states.
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
Continuous reachability governance: Third-party access should be treated as a live control surface, because the security question is not who was approved once, but what remains reachable today. That matters most where OAuth tokens, vendor accounts, and integrations survive longer than the relationship that justified them.
Traditional recertification alone will not keep up with third-party identity sprawl. The practical shift is toward lifecycle-aware revocation, ownership drift detection, and identity-based containment that limits how far a compromised external account can move.
Security teams that already manage NHIs should recognise the pattern immediately: third-party credentials behave like long-lived machine identities unless they are scoped, monitored, and revoked as continuously as any other privileged non-human access.
For practitioners
- Map third-party reachability continuously Build an always-current inventory of vendor accounts, OAuth tokens, API keys, and integrations, then record what each can actually reach inside the environment.
- Segment external identities by business need Restrict third-party identities to the smallest reachable resource set that supports the approved use case, with no implicit access to adjacent systems.
- Tie revocation to ownership drift Remove access when the business owner, vendor relationship, or integration purpose changes, rather than waiting for periodic review cycles.
- Apply just-in-time privilege to sensitive paths Require ephemeral elevation for privileged third-party workflows so standing access does not remain available after the task is complete.
- Replace perimeter trust with identity-based containment Use policy and segmentation together so a compromised vendor credential cannot traverse laterally into unrelated parts of the environment.
Key takeaways
- Third-party access becomes dangerous when external identities keep their reach long after the business need has changed.
- The article cites evidence that most organisations see third-party and supply chain vulnerabilities as their top cyber-resilience barrier, while remediation of weak third-party passwords and permissions remains slow.
- The control gap is continuous governance, not one-time onboarding, which means ownership, reachability, and revocation must be kept current.
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 Zero Trust (SP 800-207) 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 | Third-party vendors, integrations, and tokens are the core exposure discussed in the article. |
| NHI-05 — Overprivileged NHI | The article focuses on broad third-party access that exceeds operational need. | |
| NHI-07 — Long-Lived Secrets | OAuth tokens, API keys, and vendor credentials persist beyond the business need that created them. | |
| Recommendation — Inventory and constrain third-party identities before they become an external foothold. Reduce third-party privilege to the smallest reachable resource set and remove excess scope. Shorten credential lifetime and revoke stale third-party secrets as ownership changes. | ||
| NIST Zero Trust (SP 800-207) | Zero Trust principle of least privilege access — Least Privilege Access | The article explicitly argues for Zero Trust containment and identity-based reach control. |
| Recommendation — Apply Zero Trust reachability controls so third-party access is continuously verified and bounded. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack pattern described is credential abuse followed by movement across internal systems. |
| Recommendation — Hunt for compromised third-party credentials that enable lateral movement beyond the approved scope. | ||
Key terms
- Third-Party Access Governance: Third-party access governance is the control set that tracks, approves, reviews, and revokes access granted to external vendors and partners. It becomes an identity problem when suppliers operate through shared credentials, delegated workflows, or persistent machine access that outlives the business need.
- Continuous Reachability Governance: A control model that focuses on what an identity can reach right now rather than what it was allowed to access at onboarding. It is especially important for third-party and non-human identities because business relationships, integrations, and permissions change faster than periodic review cycles.
- Third-Party Identity: An identity issued to a partner, vendor, contractor, or external service that can access internal systems. These identities often sit outside normal employee governance and can become persistent trust paths if they are not reviewed, expired, and revoked on schedule.
- Identity-Led Containment: Identity-led containment is a response pattern where suspicious account activity directly triggers actions such as reauthentication, session termination or user watching. It shifts the first containment decision into the identity layer, so response can begin before an analyst manually reconciles alerts across tools.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 28, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org