SaaS integration security gaps are widening beyond traditional IAM

At a glance

What this is: This guide explains why SaaS-to-SaaS integrations have become a hidden access layer, with OAuth tokens, API keys, and automations creating persistent paths outside normal IAM controls.

Why it matters: IAM, IGA, and PAM teams need to govern delegated SaaS access as an NHI problem because these integrations can outlive users, bypass MFA, and widen blast radius across business systems.

By the numbers:

• The average enterprise SaaS platform now connects to 42+ third-party applications through integrations.
• 86% of organizations now prioritize SaaS security, yet most still lack visibility into the integrations connecting their applications.

Context

SaaS integration security is the governance of machine-to-machine and user-authorized connections between business applications. In this article, the problem is not the SaaS apps themselves but the OAuth tokens, API keys, webhooks, and automation platforms that create persistent access paths outside normal identity controls.

For IAM teams, the important shift is that these integration paths behave like non-human identities even when they were created by a human user. Once granted, they can persist after user offboarding, bypass MFA after initial authorization, and multiply across a SaaS estate faster than manual reviews can track.

The result is a hidden access layer that traditional application inventories often miss. That makes integration lifecycle, authorization scope, and behavioral monitoring the real control points, not just sign-in policy or endpoint posture.

Key questions

Q: What breaks when SaaS integrations are not governed as non-human identities?

A: Teams lose visibility into who or what can reach connected systems, and attackers can use trusted credentials to move through those integrations without triggering normal human-account controls. The practical failure is blast radius, not just access. One over-scoped token or service account can expose multiple downstream platforms, especially when ownership, rotation, and review are missing.

Q: Why do third-party SaaS integrations create risk even when employees use strong passwords and MFA?

A: OAuth permissions can grant a third party ongoing access to user data without sharing a password. If a malicious app, stolen token, or compromised SaaS provider is involved, MFA on the original account may not stop abuse of that existing consent. That is why delegated access must be governed like any other vendor dependency.

Q: How can security teams tell when a trusted integration is being abused?

A: Look for drift from the approved behavioural baseline. Unexpected source infrastructure, new user agents, API version changes, schema discovery, and unusually large QueryMore pagination bursts are all strong signals that a trusted integration is no longer acting normally. Those signals should be monitored as identity events, not just application logs.

Q: When should organisations re-evaluate SaaS automation after a third-party breach?

A: Organisations should re-evaluate whenever a breach shows that delegated access, OAuth grants, or service accounts can be abused at scale. The right response is to review scopes, revoke stale credentials, test closure logic, and confirm that automation identities cannot exceed their intended purpose.

Technical breakdown

Why OAuth tokens behave like persistent bearer credentials

OAuth access and refresh tokens are bearer credentials, which means possession is enough to use them. In SaaS integrations, the initial user authorization often happens once, after which the token continues to access data without repeated MFA checks. That design is useful for automation, but it also creates a long-lived trust boundary that sits outside traditional sign-in controls. Refresh tokens are especially important because they can extend access for months or years, surviving password changes and user offboarding if they are not explicitly revoked.

Practical implication: Treat integration tokens as governed credentials with their own inventory, revocation, and review process.

How iPaaS and custom API integrations expand blast radius

Integration platform as a service tools and custom API connections centralize multiple downstream authorizations in one place. If the integration hub is compromised, the attacker may inherit all of the connected OAuth grants, API keys, and workflow permissions attached to it. Custom integrations add another problem: developers frequently hardcode secrets, over-request scopes, and leave connections unaudited after deployment. That turns a convenient automation layer into a concentration point for credential exposure and data movement across SaaS estates.

Practical implication: Map every high-trust integration hub and custom connector to the systems and data it can reach.

Why traditional IAM visibility misses shadow SaaS paths

Traditional IAM tools are built to track users, sessions, and applications that pass through central authentication. SaaS integrations often bypass that model because a user can authorize a third-party app directly from within the SaaS product, creating a delegated path that IT never sees at approval time. Once authorized, these connections may remain active even after the original account changes. That is why inventory-only controls miss risk: the real issue is not merely whether an app exists, but whether it still has valid access and whether its behaviour remains normal.

Practical implication: Pair integration inventory with behavioural monitoring and periodic revocation of stale grants.

Threat narrative

Attacker objective: The attacker wants durable access to business data and workflows by abusing trusted SaaS integrations instead of breaking primary user authentication.

1. Entry occurs when a user or vendor integration authorizes a third-party SaaS connection that receives OAuth tokens or API keys with persistent access.
2. Credential access follows when attackers steal or inherit those tokens, often through a compromised integration partner, exposed secret, or overprivileged automation account.
3. Escalation occurs when the compromised integration is chained into other connected SaaS services, allowing the attacker to move through legitimate workflows and expand access.
4. Impact comes when the attacker uses the delegated access path to read, modify, or export business data across multiple downstream environments.

Breaches seen in the wild

• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
• tj-actions/changed-files compromise 2025: A stolen bot token let attackers poison tj-actions/changed-files so pipelines printed their CI/CD secrets to public logs (CVE-2025-30066).

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 security is now an identity governance problem, not just an application control problem: SaaS-to-SaaS connections behave like delegated identities with their own issuance, scope, persistence, and revocation challenges. That makes lifecycle governance as important as initial authorization. The practitioner conclusion is straightforward: if the integration can act, it must be governed like an identity.

Persistent OAuth access is an identity trust boundary that MFA does not cover: once the bearer token is issued, the control plane has already moved away from interactive authentication. That means traditional human IAM assumptions do not hold for the steady-state risk. The practitioner conclusion is that token lifetime, scope, and offboarding matter more than login policy at the point where access persists.

Hidden integration paths create identity blast radius across the SaaS stack: one overprivileged connector can expose multiple systems because modern business workflows are chained together by machine-held credentials. Obsidian Security's article shows that the problem is not isolated apps but the trust graph between them. The practitioner conclusion is to govern the graph, not just the endpoint app.

Supply chain exposure in SaaS now includes delegated SaaS access and not just software dependencies: when a third-party provider inherits tokens into customer environments, the compromise path is operational as much as technical. This broadens the meaning of third-party risk for identity teams. The practitioner conclusion is that vendor access review must include integration grants, not only contractual assurance.

Continuous behavioural monitoring is the only way to see when a legitimate integration becomes abnormal: static inventory tells you what exists, but not whether it is being abused. For identity programmes, that shifts detection from existence to usage patterns. The practitioner conclusion is to combine entitlement governance with anomaly detection for integration accounts and tokens.

From our research library:

• The blast radius of the Salesloft-Drift OAuth supply chain attack was 10 times greater than earlier incidents in which attackers breached Salesforce directly.
• Read next: SaaS-to-SaaS and OAuth App Governance Guide

What this signals

Integration blast radius is now the governing concept: security teams should stop thinking about SaaS risk as one app at a time and start mapping how delegated access moves across tools, users, and vendors. The control failure is not visibility alone, but the absence of ownership over the hidden trust graph that connects the estate.

Bearer credentials need lifecycle governance, not just authentication policy: refresh tokens and API keys persist after the human event that created them, so revocation discipline matters more than login friction. That shifts the programme conversation from sign-in hardening to entitlement hygiene and continuous review.

Third-party exposure is routine, not exceptional: according to the Ultimate Guide to NHIs, 92% of organisations expose NHIs to third parties, which makes delegated SaaS access a mainstream governance problem rather than a corner case. The practitioner response is to treat integration grants as first-class assets in identity governance.

For practitioners

• Inventory every SaaS integration grant Build a complete register of OAuth tokens, API keys, webhooks, iPaaS flows, and third-party apps across core SaaS systems, then tie each grant to an owner and business purpose.
• Revoke stale delegated access on a schedule Remove integration grants that no longer support an active business process, and force reauthorization for connections that have not been used or reviewed recently.
• Downscope overprivileged integration permissions Review existing scopes against actual workflow needs, then reduce write, admin, and broad-read permissions to the minimum required for the integration to function.
• Monitor integration behaviour for drift Baseline normal token use, data access volume, and destination patterns so unusual exports, new recipients, or cross-application chaining can trigger investigation.
• Gate new third-party connections before authorization Require security review for new integrations that can read mail, files, customer records, or admin settings, especially where user-authorized OAuth flows bypass central approval.

Key takeaways

• SaaS integrations create a hidden identity layer that can bypass MFA, persist after user change, and spread access across connected tools.
• The main evidence is structural: enterprises now connect dozens of third-party applications, and one compromised integration can fan out across many downstream environments.
• The practical response is to govern integration grants as credentials, not convenience features, with inventory, scope reduction, revocation, and behaviour monitoring.

Key terms

• SaaS Integration Security: The practice of governing the trust relationships between cloud applications, including OAuth grants, API keys, webhooks, and automations. It focuses on how software connects, what data those connections can reach, and how quickly access can be reduced or revoked when the business need changes.
• Bearer Credential: A bearer credential is a secret that grants access to whoever possesses it, without requiring proof of the original user at every request. In SaaS and cloud environments, OAuth tokens, session cookies, and similar artifacts behave this way, which makes theft and replay a direct access path.
• 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.
• Integration Blast Radius: Integration blast radius is the amount of downstream access and data exposure a compromised connection can create. It is determined by scopes, tenant reach, and connected systems, so it is a governance measure as much as a technical one.

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.