SaaS supply chain risk is driven by OAuth and non-human identities

At a glance

What this is: This article argues that modern SaaS supply chain exposure is driven by OAuth tokens, service accounts, and shadow integrations that bypass traditional perimeter and procurement controls.

Why it matters: It matters because IAM, IGA, and PAM teams now have to govern SaaS-to-SaaS access as a non-human identity problem, not just a vendor management problem.

Context

SaaS supply chain risk emerges when users connect apps directly to core systems and those apps then talk to other apps without passing through the network perimeter. In that model, the security problem is not just third-party vendors, but the non-human identities and authorisations that keep those connections alive.

Traditional third-party risk programmes were designed for infrastructure suppliers and managed service providers, not OAuth tokens, service accounts, and app-level permissions. Once access is granted inside SaaS ecosystems, the operational question becomes whether teams can see, govern, and revoke it before it drifts beyond the original business intent.

Key questions

Q: What breaks when SaaS apps are allowed to connect through OAuth without lifecycle review?

A: The approval model breaks because delegated access outlives the human login that created it. OAuth tokens can keep acting quietly, often with scopes no one rechecked, so security teams lose the chance to apply revocation, ownership, or periodic recertification at the point where risk actually exists.

Q: Why do OAuth tokens and service accounts increase SaaS supply chain risk?

A: They create persistent, non-human access paths that do not depend on repeated MFA or user interaction. Once granted, they can cross systems, retain broad privileges, and remain active long after the original business need changes, which expands the attack surface without a visible procurement event.

Q: What are the signs that SaaS access settings are being misused or drifting out of policy?

A: Warning signs include unexpected permission changes, too many teams with administrative access, unapproved sharing links, new external users appearing in sensitive workspaces, and configuration changes that are not tied to a documented change request. Organisations should also watch for unusual access to collaboration tools outside normal hours, because attackers often exploit settings changes before data is removed.

Q: How should teams govern shadow IT discovered through OAuth-connected apps?

A: Treat it as an access governance issue, not only a software inventory issue. Identify which users connected the app, what data or permissions it can reach, who owns the business need, and whether the app is already covered by approved lifecycle and review processes. Then decide whether to sanction, restrict, or remove it.

Technical breakdown

OAuth tokens bypass MFA and outlive the user session

OAuth access tokens are delegated credentials, not interactive logins. They inherit access from the consented application and can continue to operate without repeating MFA, which means the control boundary shifts from authentication to authorisation and token lifecycle. In SaaS environments, that creates a long tail of access that may never re-enter the IdP flow. Tokens with broad scopes become especially risky when the original approval is never revisited and activity is not visible in central monitoring. This is a classic non-human identity problem because the credential acts independently of the human login event that created it.

Practical implication: inventory delegated OAuth grants and treat token scope and expiry as governance controls, not admin housekeeping.

Service accounts create persistent cross-app access paths

Service accounts are machine identities used for integration, automation, and system-to-system access. They are often created automatically by SaaS platforms and assigned elevated roles so connected applications can sync data or call APIs. Because they do not authenticate like a human user, they often bypass user-centric alerting and review processes. Their real risk is persistence: once a service account becomes embedded in multiple workflows, it can provide lateral movement across connected SaaS systems and remain active long after the original business use case changes.

Practical implication: apply the same entitlement review discipline to service accounts that you apply to privileged human accounts, including ownership and offboarding.

SaaS configuration drift turns approved access into unknown exposure

Configuration drift happens when the access and data-sharing settings of a SaaS app change over time, often through vendor updates, permission creep, or new integrations. A configuration that was acceptable on day one may expose additional scopes, new data paths, or broader sync behaviour by day thirty. The governance issue is not only whether an app was approved, but whether its effective access remains aligned to the original risk decision. In SaaS supply chains, drift is dangerous because it is quiet, cumulative, and usually outside the visibility of perimeter controls.

Practical implication: continuously reassess SaaS app permissions and data-sharing settings after approval, not just during intake.

Threat narrative

Attacker objective: The objective is to turn delegated SaaS access into quiet, persistent reach across connected applications and sensitive data.

1. Entry occurs when a user consents to an OAuth app, creates a service account, or connects a shadow integration directly to a core SaaS system.
2. Credential access is established through delegated tokens or overprivileged non-human identities that persist after initial approval and do not require repeated MFA.
3. Escalation follows when those credentials are reused across multiple apps, retain broad scopes, or inherit access that was never reviewed.
4. Impact is achieved when the attacker or rogue integration moves laterally across SaaS services and accesses sensitive files, settings, or business data.

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 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

SaaS supply chain governance fails when organisations treat connected applications as vendor records instead of identity relationships. The control problem is not whether the supplier is approved once, but whether every OAuth grant, service account, and shadow integration is continuously owned, scoped, and revocable. That shifts third-party risk from procurement status to identity lifecycle discipline, which is where SaaS exposure actually accumulates.

OAuth tokens create a delegated-access problem that traditional MFA programmes do not solve. MFA protects the initial human authentication event, but it does not govern what the app can continue doing after consent. The implication is that identity security teams must stop treating token grants as a one-time exception and start treating them as standing non-human authority that needs lifecycle control.

Service accounts are now a lateral-movement substrate inside SaaS ecosystems. They often inherit broad application permissions, survive long after the original integration owner has changed, and remain outside normal user-centric review cadences. This is why SaaS governance, PAM, and IGA need a shared model for machine identities, not separate blind spots.

SaaS configuration drift is the named concept that explains why day-one approval does not equal day-thirty safety. Approved access can expand through silent vendor changes, new scopes, and informal app connections until the live state no longer matches the risk decision. Practitioners need to measure the current access state, not the original approval artefact.

Shadow SaaS is becoming a governance problem, not just a discovery problem. Discovery matters, but the deeper issue is that employee-connected tools can inherit business data access without passing through procurement, legal, or security review. The field needs continuous control over non-human access paths, because hidden integrations are now a normal condition of SaaS operations.

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: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

OAuth consent has become a governance boundary. In SaaS ecosystems, the decisive control is no longer only how a human signs in, but how much authority the app retains after that sign-in. Teams that still anchor monitoring around the perimeter will miss the delegated-access layer where most exposure now accumulates.

Shadow SaaS changes the ownership model for identity risk. When employees connect bots, extensions, and AI tools directly to business systems, the real question is whether those non-human identities are continuously discoverable, attributable, and removable. That is an IGA and PAM issue as much as it is a SaaS security issue.

For practitioners

• Inventory delegated OAuth grants Map every consented app to its token scopes, data access, and business owner so you can distinguish legitimate integrations from dormant risk.
• Assign owners to service accounts Require a named accountable owner for each service account, including a review date and a clear offboarding trigger when the integration is no longer needed.
• Review SaaS permissions after vendor updates Reassess scopes, sync settings, and new data paths whenever a SaaS provider changes behaviour, even if the application itself was previously approved.
• Track shadow integrations outside procurement Monitor Slack bots, browser extensions, and free AI tools that obtain OAuth or API access without formal review, then route them into the same governance process as approved apps.

Key takeaways

• SaaS supply chain exposure now concentrates in delegated access paths, not in classic perimeter failure alone.
• OAuth tokens, service accounts, and shadow integrations can persist beyond the business need that created them, which increases attack surface over time.
• Continuous visibility into non-human access, ownership, and revocation is the control that changes the risk profile.

Key terms

• OAuth Token: A short-lived access credential issued by an OAuth 2.0 authorisation server granting an NHI scoped access to specific resources for a defined period. Preferred over static API keys because their short lifetime limits the exploitation window if intercepted.
• Service Account: A special-purpose account used by applications, automated tools, or services rather than a human user to interact with systems, APIs, and infrastructure. Service accounts are a primary category of NHI and one of the most frequently exploited attack vectors.
• SaaS Integration Drift: SaaS integration drift is the gradual accumulation of connected apps, permissions, and ownership gaps across a software ecosystem. It happens when installation is easy but lifecycle control is weak. The result is an expanding identity surface that becomes harder to inventory, review, and offboard reliably.
• Shadow SaaS: Shadow SaaS is the set of unauthorised or unreviewed software-as-a-service tools used outside central security governance. These applications often bypass normal identity controls, making them difficult to inventory, monitor, and harden against credential-based abuse.

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.