TL;DR: SaaS supply chain attacks exploit hidden SaaS-to-SaaS connections, and the article argues that traditional VRM, SBOM, and CI/CD controls only cover part of the exposure picture while integration-layer risk remains under-governed, according to Obsidian Security. The governance gap is now centred on ephemeral OAuth access, shadow integrations, and cross-app privilege drift, not just vendor posture.
At a glance
What this is: This guide explains how SaaS supply chain risk moves through OAuth and API integrations, with the key finding that hidden connections now create the most overlooked access paths.
Why it matters: IAM, IGA, and PAM teams need to govern SaaS integrations as an access surface, because overprivileged tokens and shadow automations can bypass vendor-focused risk reviews.
By the numbers:
- SaaS to SaaS data moves 10x faster than human to SaaS, making integration monitoring far harder than traditional review cycles.
- 15% of all SaaS breaches originate from a third-party or supply chain compromise, according to IBM Cost of a Data Breach Report, 2025, cited by Obsidian Security.
- The average cost of a SaaS breach in the article is $4.91 million per breach, according to IBM Cost of a Data Breach Report, 2025, cited by Obsidian Security.
Context
SaaS supply chain security now extends beyond vendor posture and build integrity. In practical terms, the problem is not just whether a supplier is trustworthy, but whether OAuth grants, API connections, and automations have created hidden access paths inside the environment.
Traditional third-party risk management and software inventory tools only see part of that picture. They can document external risk or application components, but they do not reliably expose live SaaS-to-SaaS privilege, shadow integrations, or the way access expands after a one-click connection is approved.
That gap matters because integration sprawl changes faster than periodic review models can track. For identity programmes, the question is no longer only which vendor is connected, but which non-human permissions each connection has accumulated and whether those permissions are still justified.
Key questions
Q: What breaks when SaaS integrations are created without security oversight?
A: When integrations are created without security oversight, teams lose context on which vendors can access which applications and how much data they can reach. That breaks third-party risk management, because security and compliance teams cannot reliably assess exposure, enforce least privilege, or remove unnecessary access. The result is sprawl, hidden trust relationships, and a wider attack surface than the organisation believes it has.
Q: Why do OAuth tokens and API integrations create supply chain risk?
A: They create risk because they let one application act inside another with delegated authority. If the token is over-scoped or compromised, the attacker inherits that access and can reach sensitive workflows, customer data, or downstream credentials. The danger comes from trust reuse across apps, not from the token format itself.
Q: What signals show that SaaS governance is not working?
A: Look for delayed offboarding, repeated manual exports, inconsistent access review responses, and inactive accounts that still carry paid licenses. Those signals indicate that entitlement ownership and usage data are not reconciled often enough to support reliable governance.
Q: How should teams balance vendor risk management with integration monitoring?
A: Vendor risk management should remain the baseline for supplier assurance, but it cannot replace monitoring of live SaaS connections. Teams need both views because supplier posture describes the outside of the relationship, while integration monitoring reveals who can actually move data and actions between applications. Without both, important exposure stays invisible.
Technical breakdown
Why OAuth integrations create a hidden access layer
OAuth tokens and API integrations are effectively delegated authorisations between applications. Once a user or app consents, the connected service can act with whatever scopes were granted, often without the security team seeing the full chain of trust. That makes the integration layer behave like an access fabric, not just a convenience feature. The risk grows when scopes are broad, automations are unmonitored, and the connection continues long after the business need changes. In identity terms, the issue is not authentication failure. It is persistent delegated access with poor lifecycle governance and little visibility into downstream use.
Practical implication: Treat every SaaS integration as a governed non-human identity and inventory its scopes, owners, and revocation path.
Why SBOM and VRM only cover part of SaaS supply chain risk
SBOM tools describe software components and VRM tools assess supplier posture from the outside. Both are useful, but neither is designed to map the live permissions created when one SaaS platform connects to another through OAuth or API tokens. That means they can miss the actual route attackers use once they gain access through a third party. The core architectural mismatch is that these tools are mostly static or point-in-time, while SaaS integrations are dynamic and user-created. The control problem is therefore not simply third-party risk. It is access governance over a changing mesh of connected services.
Practical implication: Use vendor assessments for baseline assurance, then add integration governance for the permissions that actually move data.
How supply chain compromise becomes cross-app privilege drift
When a third-party integration is compromised, the attacker does not need to break the target SaaS platform directly. They can reuse the delegated trust already embedded in the token or integration and move across connected systems. That is why the article links OAuth compromise to lateral access, data export, and credential exposure in downstream environments. The technical failure is privilege drift across apps: a connection starts narrow, then grows broad enough to expose sensitive business flows. Once that drift exists, the blast radius is set by the scope of the integration, not by the posture of the original vendor.
Practical implication: Review connected-app scopes as a blast-radius control, not as a one-time onboarding check.
Threat narrative
Attacker objective: The attacker aims to turn one compromised SaaS integration into broad access across downstream business systems and the sensitive data they expose.
- Entry occurs through a compromised third-party SaaS integration, where attackers obtain OAuth tokens or equivalent delegated access.
- Credential access follows when the token grants legitimate cross-app permissions that can be reused without breaking into the target directly.
- Escalation happens as the compromised connection is used to reach downstream SaaS environments and export sensitive data or additional credentials.
- Impact is achieved through cascading access across multiple business systems, widening the blast radius beyond the original integration.
Breaches seen in the wild
- Klue OAuth Supply Chain Breach: OAuth tokens compromised in Klue integration breach affecting 700+ organisations via Salesforce data access chain.
- 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 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
Integration-layer privilege drift is now the core SaaS supply chain problem: vendor posture still matters, but it no longer tells the whole story because the exploitable surface sits in live OAuth grants, API links, and automations. Those connections can outgrow the approval that created them, and the result is access that is technically valid but operationally unjustified. The practitioner conclusion is simple: govern the connection, not just the supplier.
SaaS integrations behave like non-human identities: they have scopes, lifecycles, owners, and revocation requirements, even when the tooling rarely labels them that way. The governance gap appears when teams treat integrations as configuration rather than as delegated identity objects with access paths. That framing matters because access reviews and offboarding logic only work when the thing being reviewed is explicitly in inventory. Practitioners should model integrations as governed NHI, not as incidental plumbing.
Traditional third-party risk tools are necessary but insufficient: SBOM, VRM, and build integrity controls answer different questions from the one attackers exploit in SaaS ecosystems. They help with component visibility, supplier posture, and pipeline assurance, but the breach path here is the live permission relationship between apps. Ephemeral delegated access window: this article shows that short-lived OAuth consent can still carry long-lived business impact when revocation, monitoring, and scope reduction lag behind. Practitioners should align control design to the lifetime of the permission, not the lifetime of the vendor contract.
Shadow SaaS is now a governance issue, not just an inventory issue: employees can create integrations quickly, which means new access paths appear faster than manual approval workflows can react. That is especially important when AI-driven workflows increase the number of connected apps and tokens. The implication is that SaaS identity governance must move closer to issuance time, where risky grants are first created, rather than relying on later periodic review. Practitioners should assume that unknown integrations are active controls waiting to be abused.
The market is converging on integration governance as a distinct control plane: the article reflects a broader shift from vendor scoring toward permission-aware SaaS security. That shift is important because it collapses the old separation between application security, third-party risk, and identity governance. The more connected the SaaS estate becomes, the more identity teams will be asked to own delegated access across business applications, not just human login flows. Practitioners should prepare for identity governance to expand into SaaS-to-SaaS trust management.
From our research library:
- 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.
- 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
Ephemeral delegated access window: SaaS-to-SaaS risk now sits in the time between consent and revocation, not just in supplier onboarding. That means identity teams need to treat every connected app as a living permission object, because review cycles that were designed for static suppliers cannot keep pace with integration churn.
The control gap is broad enough that static vendor scoring should be treated as input, not assurance. If a connected SaaS app can create, expand, or reuse access without central oversight, the real question is whether the organisation can see and revoke that path before it becomes a breach vector.
For practitioners
- Inventory all OAuth and API integrations Build and maintain an inventory of connected SaaS applications, including shadow integrations, with owners, scopes, and business purpose recorded for each connection.
- Classify integrations as governed non-human access Treat each token, automation, and app connection as a non-human identity with a defined lifecycle, revocation path, and approved scope.
- Review scopes against actual data movement Compare granted OAuth scopes and API permissions to the data and actions the integration truly needs, then remove any excess access.
- Add monitoring for suspicious cross-app activity Alert on unusual token use, unexpected data export, and lateral activity across SaaS platforms so compromised integrations can be contained quickly.
- Reassess third-party risk at the integration layer Use vendor reviews as baseline assurance, but add direct checks for live integrations, automations, and permissions that static supplier assessments miss.
Key takeaways
- SaaS supply chain attacks are increasingly driven by hidden OAuth grants and API integrations rather than by direct compromise of the target platform.
- The article shows that static vendor risk tools and build-focused controls leave the live integration layer under-governed, which is where privilege drift accumulates.
- Practitioners need to inventory, classify, monitor, and revoke SaaS-to-SaaS permissions with the same discipline used for other non-human access paths.
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 SP 800-53 Rev 5, NIST CSF 2.0 and CSA Cloud Controls Matrix set 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 | The article centres on compromised SaaS-to-SaaS integrations and delegated third-party access. |
| NHI-05 — Overprivileged NHI | The core exposure is over-scoped OAuth access and broad token permissions across apps. | |
| NHI-09 — NHI Reuse | The article describes reused trust across connected SaaS applications and downstream environments. | |
| Recommendation — Inventory third-party SaaS integrations and revoke any delegated access that exceeds the business need. Reduce OAuth scopes to the minimum required and remove any excess integration permissions. Separate integration trust domains so one SaaS connection cannot be reused to reach multiple systems. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token lifecycle and revocation are central to controlling compromised integrations. |
| Recommendation — Apply authenticator lifecycle controls to track, rotate, and revoke SaaS tokens promptly. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article is about governing permissions and entitlements created by SaaS integrations. |
| Recommendation — Continuously review entitlements for connected apps and remove access that no longer matches purpose. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The attack path uses compromised OAuth access to move across connected SaaS environments. |
| Recommendation — Map SaaS integration abuse to credential access and lateral movement detections in your monitoring stack. | ||
| CSA Cloud Controls Matrix | IAM — Identity and Access Management | The article is fundamentally about cloud identity governance over SaaS connections. |
| Recommendation — Extend cloud IAM governance to SaaS integrations, tokens, and delegated permissions. | ||
Key terms
- SaaS Supply Chain Attack: A SaaS supply chain attack is an intrusion path that uses trusted integrations, tokens, or third-party services to reach a target environment indirectly. The attacker relies on inherited trust between applications rather than breaking the main system first, which makes detection and containment harder.
- 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.
- 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.
- Interaction layer: The point where a user, agent, or automation interacts with the business flow, such as login, checkout, account creation, or API use. This layer matters because it exposes behaviour, not just network characteristics, and it is often where agentic misuse becomes visible before deeper compromise occurs.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on May 28, 2026.
Updated on October 8, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org