TL;DR: A 2025 supply chain breach that affected over a billion records showed how stolen OAuth tokens from third-party SaaS integrations can impersonate trusted applications and widen access across customer systems, according to SafePaaS. The real failure is governance drift, because long-lived non-human credentials are still treated as someone else’s problem rather than continuously owned, reviewed, and revoked.
At a glance
What this is: This is an analysis of how third-party SaaS tokens become hidden identity risk when ownership, review, and revocation break down across integrations.
Why it matters: It matters because identity teams must govern third-party tokens as live credentials, not procurement artefacts, or they inherit unmanaged access paths into core systems.
Context
Third-party SaaS integrations create a credential layer that often escapes normal identity governance. In practice, OAuth tokens, app connectors, and service credentials can outlive the business relationship that justified them, which turns convenience into persistent access risk for NHI and SaaS programmes.
This article argues that the failure is not simply technical exposure but governance ownership. When customers assume vendors own the token lifecycle and vendors assume customers do, long-lived non-human credentials end up in a no-one-owns-this gap that security teams only discover after an incident.
Key questions
Q: What breaks when third-party SaaS tokens are not continuously governed?
A: The break is ownership, not just visibility. Tokens can remain active after the original use case changes, which means a trusted integration can keep carrying delegated access with no current business justification. That creates an unmanaged identity path into core systems and makes compromise harder to notice until access is already widespread.
Q: Why do over-privileged API tokens increase supply chain breach impact in SaaS environments?
A: Over-privileged API tokens create more blast radius because a compromise does not stay confined to one app or one workflow. If an attacker obtains a token with broad access, they can move into business-critical SaaS data, automate exfiltration, or alter records at scale. The risk is amplified when business users can create integrations without security review or least-privilege controls.
Q: How can security teams tell when a third-party integration is becoming a shadow identity?
A: Look for credentials that are active, trusted, and still connected to business processes but no longer appear in ownership or review workflows. Common indicators are missing owners, stale scopes, weak renewal discipline, and app behaviour that survives the original project or vendor relationship.
A: They should assign explicit lifecycle ownership on both sides and make revocation, scope review, and attestation part of the operating model. If no one can clearly answer who approves, who reviews, and who revokes, the credential is already outside effective governance.
Technical breakdown
Why third-party SaaS tokens create hidden identity risk
OAuth tokens, API keys, and app connectors are not just integration plumbing. They are non-human identities that carry delegated authority across systems, often with broad scopes and long lifetimes. If those credentials are reused across environments or never re-attested, they become stable impersonation mechanisms rather than temporary access artefacts. The key failure is that token trust is often established once and then left to drift while the connected SaaS estate changes around it.
Practical implication: inventory every third-party token as an identity object, not a technical setting, and bind it to an owner and expiry state.
How over-privileged OAuth access expands blast radius
When an OAuth token is over-scoped, compromise of a single integration can look like legitimate application behaviour. That is what makes these incidents dangerous: attackers do not need to break the primary system if they can abuse a trusted delegate with access to customer data or downstream APIs. In a SaaS chain, one token can inherit trust from the original application while still reaching multiple connected tenants or business systems, which turns one credential into many access paths.
Practical implication: narrow token scopes to the minimum required paths and review whether each integration can still justify its delegated access.
Why continuous governance matters more than one-time onboarding
A questionnaire at onboarding proves very little about runtime identity risk. The real control plane is the lifecycle: who owns the token, how often it is reviewed, what triggers rotation, and who can revoke it when business need changes. Without continuous governance, third-party credentials become shadow identities because they sit outside the normal joiner-mover-leaver model even though they behave like privileged accounts. That is why checklist-based third-party risk management routinely misses the highest-risk integrations.
Practical implication: move token attestation, rotation, and offboarding into recurring governance workflows with named business and security owners.
Threat narrative
Attacker objective: The attacker wants to abuse trusted application access to reach customer data and systems at scale without traditional account takeover.
- Entry occurs through a stolen OAuth token from a third-party SaaS integration that was already trusted by customer systems.
- Escalation follows when the attacker uses that token to impersonate the application and inherit its delegated access without raising obvious authentication alarms.
- Impact is the quiet expansion of access across customer systems, creating a broad blast radius from a single compromised integration.
Breaches seen in the wild
- Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
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 SaaS tokens are a governance problem before they are a security problem. The article’s central failure mode is not just token compromise but the absence of durable ownership across the token lifecycle. Once credentials move into the SaaS supply chain, they behave like non-human identities that need assignment, attestation, and revocation. The implication is that third-party access cannot remain a procurement checkbox; it has to be governed as live identity.
Long-lived delegated credentials create identity blast radius. A single token with broad scopes can impersonate a trusted application and move through interconnected customer systems as if it were legitimate traffic. That changes how practitioners should think about blast radius, because the exposure is not limited to one vendor account or one tenant. The practitioner conclusion is that delegated access must be designed as a constrained trust path, not a permanent convenience layer.
No-one-owns-this credentials are the core control failure. The article shows a cultural and operational split where customers expect vendors to manage tokens and vendors expect customers to own them. That assumption collapses in multi-party SaaS chains because the credential persists even when accountability does not. The implication is that lifecycle ownership must be explicit, documented, and continuously tested across both sides of the integration.
Continuous attestation matters more than initial approval. The article makes clear that questionnaires, certificates, and static onboarding forms do not govern runtime exposure. What matters is whether the token is still needed, still scoped correctly, still rotated, and still revocable. Practitioners should treat third-party SaaS access as an ongoing certification problem, not a one-time trust event.
Identity governance must extend beyond human accounts to connected applications and automation. Third-party SaaS risk rises when app connectors, APIs, bots, and service credentials sit outside the same governance fabric used for users and privileged access. That creates blind spots in ownership, recertification, and offboarding. The practical conclusion is that identity programmes that stop at human IAM are already incomplete.
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: Third-Party, B2B and Contractor Access Guide
What this signals
Identity blast radius is now a third-party problem. Once a SaaS connector can impersonate a trusted application, the relevant control is no longer just authentication at the edge but the lifecycle of delegated access across the integration chain. Teams should expect their highest-risk exposure to sit in credentials that were created for convenience and then forgotten.
Federated governance is the missing operating model. Third-party tokens cannot be left in a procurement or vendor-management silo because their risk is expressed at runtime in IAM, PAM, and NHI controls. Security leaders should align ownership, attestation, and revocation into one continuous workflow rather than treating each system separately.
For practitioners
- Inventory third-party tokens as governed identities Build a unified inventory of OAuth tokens, app connectors, API keys, and service accounts, and record the business owner, technical owner, scope, and expiry for each credential.
- Shorten delegated credential lifetimes Replace open-ended tokens with short-lived credentials wherever the integration allows it, and require explicit renewal or re-authentication for high-risk connections.
- Bind every integration to a named offboarding path Define who can revoke each third-party credential, what event triggers revocation, and how the integration is disabled when the vendor relationship ends or the use case changes.
- Attest high-risk SaaS connections on a recurring cadence Run scheduled reviews for privileged integrations that reach customer data, finance systems, HR platforms, or CRM environments, and remove anything that no longer has a documented business need.
- Monitor for abnormal application impersonation Baseline normal token use, then alert on unusual access volume, new geographies, new data paths, or application behaviour that does not match the expected integration pattern.
Key takeaways
- Third-party SaaS tokens are dangerous when they outlive the business relationship and keep delegated access active without clear ownership.
- The breach pattern described here shows how one compromised integration can expand into a wide blast radius across customer systems.
- The control gap is lifecycle governance, especially explicit ownership, recurring attestation, and fast revocation of high-risk tokens.
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 CSF 2.0 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 SaaS integrations are the article's core risk surface. |
| NHI-05 — Overprivileged NHI | The breach pattern depends on over-scoped OAuth tokens and delegated access. | |
| NHI-07 — Long-Lived Secrets | The article centers on long-lived tokens that were never rotated or revoked. | |
| Recommendation — Map every external integration to NHI-03 and review vendor-owned access paths for lifecycle control. Reduce delegated scopes to the minimum needed and remove broad application privileges. Enforce short-lived credentials and rotation triggers for third-party tokens and app secrets. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | Stolen tokens enabled access abuse and expansion across customer systems. |
| Recommendation — Map token abuse to TA0006 and TA0008 to prioritise detections around delegated access paths. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about managing permissions and entitlements for connected identities. |
| Recommendation — Apply PR.AA-05 to keep third-party entitlements current, scoped, and revocable. | ||
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.
- Delegated Access: Delegated access is permission granted to one identity to act on behalf of another user, service, or system. In NHI environments, this usually appears in OAuth-connected apps and automation tooling. It is powerful, but it must be tightly scoped and reviewed because it can persist long after the original business need ends.
- 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.
- Continuous Attestation: Continuous attestation is the repeated verification that a workload is still running in a trusted state after access has been granted. For AI agents, it means trust is not assumed after startup. The environment, posture, and runtime context must remain acceptable for access to continue.
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 June 24, 2026.
Updated on October 6, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org