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

At a glance

What this is: This analysis argues that the SaaS supply chain is an identity problem, with OAuth tokens, service accounts, and shadow integrations creating exposure outside the perimeter.

Why it matters: It matters because IAM and NHI teams need controls that govern app-to-app access, not just human logins and network-bound vendor risk.

👉 Read Wing Security's analysis of SaaS supply chain identity risks

Context

The primary issue here is not a missing firewall rule, it is the spread of non-human access across SaaS-to-SaaS links, OAuth grants, service accounts, and shadow tools. Once an application can act directly on another system, identity governance has to cover tokens, scopes, lifecycle, and review, not just users and endpoints.

For IAM and NHI practitioners, this is a familiar failure mode in a new place: access is granted once, then silently reused long after the original approval has faded. That makes SaaS supply chain risk a standing governance problem rather than a one-time vendor review problem. The article's starting point is typical for teams still anchored to perimeter-era controls.

Key questions

Q: How should security teams govern OAuth tokens in SaaS environments?

A: Treat OAuth tokens as active identities, not temporary conveniences. Track their scopes, owners, and expiry, and review them on a fixed cadence. Where possible, use least privilege, short-lived access, and event-driven re-certification when an app changes behaviour. The goal is to prevent delegated access from becoming permanent access.

Q: Why do service accounts create so much hidden risk in SaaS stacks?

A: Service accounts often bypass human-centric controls such as MFA, user alerts, and standard login monitoring. They can retain broad permissions across multiple systems and keep working after the workflow that created them is forgotten. That combination of privilege, persistence, and invisibility makes them a high-value NHI governance target.

Q: What is the difference between vendor risk management and NHI governance?

A: Vendor risk management asks whether a third party is acceptable to use. NHI governance asks what identities, tokens, and machine accounts that integration creates, what they can reach, and how long they remain valid. In SaaS supply chains, both are needed, but only NHI governance addresses the access itself.

Q: How can teams reduce SaaS supply chain exposure without blocking automation?

A: Start by classifying every integration as a governed identity with a business owner, a clear purpose, and a review cycle. Then apply least privilege, scope revalidation, and drift detection instead of blanket denial. This preserves automation while reducing the chance that an old grant becomes a standing backdoor.

Technical breakdown

Why OAuth tokens bypass traditional identity controls

OAuth tokens are delegated credentials, not interactive logins. They inherit access through scopes granted at authorisation time, so MFA events at the IdP do not re-run for every API call. That creates a control gap when teams assume login protections equal ongoing session protection. In SaaS environments, token lifetime, refresh logic, and granted scopes often outlast the review cycle. If the scope is broad and the token is not monitored, an attacker or rogue integration can operate quietly without triggering the same signals as a human account.

Practical implication: Treat OAuth grants as standing access and review them with the same discipline you apply to privileged accounts.

Service accounts as hidden non-human identities

Service accounts are machine identities created for automation, integrations, and delegated app functions. They rarely authenticate like humans, so they slip past user-centric controls, MFA prompts, and many alerting rules. In SaaS stacks, they often accumulate roles across multiple products and retain access long after the workflow that created them changes. The technical risk is not only overprivilege, but also invisibility: a service account can move laterally between connected systems, persist through vendor updates, and keep working when nobody remembers who owns it.

Practical implication: Inventory service accounts by owner, purpose, scope, and expiry, then review them as NHI assets rather than generic application settings.

How SaaS configuration drift expands the attack surface

Configuration drift happens when approved permissions, scopes, or sync settings change over time without a formal review. In SaaS supply chains, the vendor can introduce new behaviours, while users can add apps and integrations that alter data paths. The result is a moving trust boundary where the original security review no longer matches reality. Because these changes can occur outside the customer network, traditional perimeter logging often misses them. For NHI governance, drift is especially dangerous because it changes what identities can do without changing who approved them.

Practical implication: Revalidate connected app permissions on a fixed schedule and trigger review whenever scopes, owners, or data-sharing paths change.

Threat narrative

Attacker objective: The attacker wants durable, low-noise access to business-critical SaaS data and workflows without having to defeat MFA on every action.

1. Entry occurs when an employee connects a shadow SaaS app, Slack bot, or free AI tool using OAuth or API-level access that bypasses normal review.
2. Escalation follows when the granted token or service account has overprivileged scopes and can reach sensitive settings, files, or connected systems.
3. Impact comes from persistent, quiet access that supports lateral movement, data extraction, or long-term misuse across SaaS environments.

Breaches seen in the wild

• Salesloft OAuth token breach — hackers stole OAuth tokens to access Salesforce data via Salesloft.
• Dropbox Sign breach — compromised Dropbox Sign service account exposed API keys and OAuth tokens.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

OAuth grants have become standing NHI access in SaaS stacks. Teams still treat many third-party app permissions as one-time user decisions, but the token often outlives the business purpose that created it. That changes the governance model from consent to continuous entitlement review. Practitioners should manage OAuth connections as active identities with scope, lifetime, and ownership.

Service accounts are the most under-governed identities in modern SaaS supply chains. They are created for convenience, not scrutiny, and that makes them attractive for persistence and lateral movement. When a service account can operate across systems without human-style authentication, the right control set looks more like NHI lifecycle management than classic vendor risk management. Practitioners should classify them as privileged machine identities, not application details.

SaaS supply chain security is now an identity governance problem, not a procurement problem. Procurement can approve a vendor, but it cannot track how tokens, bots, and integrations mutate after deployment. That is why traditional third-party risk programs miss the real exposure. Practitioners should re-center control ownership in IAM, security engineering, and app governance.

Configuration drift creates identity blast radius. The useful concept here is that every change to scopes, syncs, or owners expands or shrinks the blast radius of a non-human identity. Once drift is accepted as normal, periodic review becomes insufficient. Practitioners should build drift detection and scope re-certification into the control plane, not the exception process.

From our research:

• 1 in 4 organisations are already investing in dedicated NHI security capabilities, with an additional 60% planning to do so within the next twelve months, according to The State of Non-Human Identity Security.
• Only 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which shows how quickly identity blind spots extend beyond the perimeter.
• For a broader control model, see 52 NHI Breaches Analysis for recurring breach patterns that begin with unmanaged machine access.

What this signals

The practical signal for security programmes is that SaaS visibility must move from inventorying vendors to inventorying access paths. When app-to-app connections are opaque, IAM teams lose the ability to answer a basic question: which non-human identities can still reach production data today?

Identity blast radius: once a token or service account is approved, the real risk is how far it can move before detection. That should push teams toward shorter review cycles, stricter scope management, and faster revocation workflows, especially where connected apps can change silently after approval.

With 1 in 4 organisations already investing in dedicated NHI security capabilities, the market signal is clear: token and service-account governance is becoming a core control, not an optional hardening task. Security leaders should plan for more machine identity telemetry, more re-certification, and tighter ownership of shadow SaaS.

For practitioners

• Inventory every SaaS integration as an NHI asset Create a register of OAuth apps, service accounts, bots, API keys, and certificates with owner, business purpose, scope, and expiry. Reconcile that register against approved vendor lists so shadow SaaS does not remain outside governance.
• Review OAuth scopes for least privilege Check delegated permissions for excessive read, write, and admin scopes, then remove anything that is not required for the current workflow. Re-authenticate and re-authorise after major app changes so stale grants do not persist indefinitely.
• Tie non-human identities to lifecycle controls Assign an owner, define a review cadence, and set expiry or rotation expectations for every service account and token. Use access reviews to catch dormant integrations, orphaned accounts, and permissions that no longer match the business use case.
• Detect configuration drift in connected apps Monitor for changes in scopes, data-sharing paths, and app ownership after initial approval. Feed those changes into a re-certification workflow so SaaS updates and user-added tools do not silently expand access.
• Correlate SaaS activity with identity signals Look for unusual token use, off-hours service account activity, and cross-app access patterns that do not fit the approved workflow. This is where identity-centric monitoring matters more than endpoint-centric alerting.

Key takeaways

• SaaS supply chain risk is fundamentally an NHI governance problem because tokens, bots, and service accounts can access core systems without human-style controls.
• OAuth grants and service accounts create standing access that can persist long after the original business need has changed, which expands identity blast radius.
• Security teams should inventory connected apps, revalidate scopes, and tie every non-human identity to ownership, expiry, and drift detection.

Key terms

• OAuth Token: An OAuth token is a delegated credential that lets an application act on behalf of a user or system within approved scopes. In SaaS environments, it can become long-lived access if teams do not monitor scope, expiry, and re-authorization events.
• Service Account: A service account is a non-human identity created for automation, integrations, and application workflows. It often carries permissions across systems, so its security depends on ownership, lifecycle controls, and review discipline rather than human login protections.
• Configuration Drift: Configuration drift is the gap between an approved security state and the system's current state after changes, updates, or new integrations. In SaaS supply chains, it can quietly expand access by altering scopes, sync rules, or ownership without a fresh review.

Deepen your knowledge

SaaS supply chain identity governance is a core topic in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is dealing with OAuth sprawl, shadow integrations, and machine accounts, it is worth exploring.

This post draws on content published by Wing Security: The part of the SaaS supply chain you forgot to secure. Read the original.