SaaS lateral movement is invisible to traditional security tools

At a glance

What this is: This is an analysis of how attackers move laterally across SaaS environments through trusted OAuth tokens, API credentials, and integrations, while traditional security tools miss the activity.

Why it matters: It matters because SaaS-to-SaaS movement turns identity trust, token scope, and integration sprawl into a breach path that IAM, SecOps, and NHI teams have to govern together.

Context

SaaS lateral movement is the abuse of trusted application-to-application connections to move from one cloud service to another without traversing the network in the way traditional tools expect. In this model, the primary security problem is not endpoint compromise but identity and token trust across connected SaaS systems.

Obsidian Security argues that once attackers compromise one SaaS application, the integration graph becomes the route map. OAuth tokens, API credentials, service accounts, and refresh tokens can extend access far beyond the original foothold, creating a blast radius that conventional monitoring does not reconstruct well.

For IAM and NHI teams, the key governance issue is that access is no longer confined to a single application boundary. The attack surface now includes delegated SaaS relationships, token lifetime, scope design, and the operational visibility needed to understand what each integration can reach.

Key questions

Q: What happens when a compromised integration is used to move laterally in SaaS?

A: Once a compromised integration has legitimate access, an attacker can pivot into connected applications and operate as a trusted entity. That can expose private repositories, sensitive business data, and broader privileges than the original entry point suggested. The main containment priority is rapid detection, credential removal, and disabling the affected integration before further propagation occurs.

Q: Why do OAuth tokens increase lateral movement risk in SaaS environments?

A: OAuth tokens increase lateral movement risk because they can remain valid after the initial user session, bypass MFA, and preserve scoped access until revoked. In SaaS environments, that makes a single consented app a durable bridge into email, files, logs, and admin-adjacent data. Identity governance must treat token scope and revocation as first-class controls.

Q: How should security teams detect lateral movement across SaaS applications?

A: Security teams should correlate identity, token, and API activity across connected applications, not just watch individual login events. Effective detection looks for abnormal API volume, new endpoints, unusual timing, and access patterns that do not match the integration’s normal behavior. Cross-platform baselines are essential because the attack often appears legitimate inside any single SaaS product.

Q: How do security teams know if a SaaS integration is overprivileged?

A: A SaaS integration is overprivileged when it can read more objects, export more records, or access more sensitive fields than it needs for its stated purpose. Strong indicators include broad read access, bulk export capability, and scope creep after onboarding. Teams should compare granted permissions to actual usage and remove anything not justified by business function.

Technical breakdown

Why SaaS lateral movement bypasses endpoint and network controls

Traditional EDR and NDR tools are built to observe endpoints and network paths, but SaaS-to-SaaS movement often occurs through direct API calls between cloud services. Those calls use valid OAuth tokens or API credentials, so they look like ordinary application traffic rather than an intrusion. SIEM and CASB platforms can ingest parts of the picture, but they usually lack the cross-application context needed to reconstruct the chain from initial compromise to downstream access. The technical failure is not that the logs do not exist. It is that the control plane is split across multiple SaaS services, each seeing only its own slice of the transaction.

Practical implication: Treat cross-application identity correlation as a detection requirement, not an optional enhancement.

How OAuth tokens and API credentials extend the breach radius

OAuth access tokens, refresh tokens, API keys, and service account credentials function as bearer credentials in many SaaS integrations. Possession is enough to act, and in some cases refresh tokens survive password resets and other user-focused remediation. That means a compromise in one app can become persistent access to several connected apps if the token scope is broad or the integration chain is long. The architectural problem is integration trust without proportional containment. Once a privileged token is accepted by multiple applications, the attacker can move laterally without repeated authentication challenges or endpoint exploitation.

Practical implication: Reduce token scope and lifetime wherever integrations can still function with narrower access.

Why integration sprawl creates hidden privilege escalation paths

Every new SaaS integration increases the number of implicit trust relationships that have to be understood, monitored, and revoked when they become unsafe. When an integration has write, delete, or admin rights across multiple platforms, it becomes a privilege escalation path disguised as routine automation. The article's core point is that the dangerous layer sits between applications, not inside a single tenant. If teams cannot inventory which app can call which API with what scope, then they cannot model blast radius or contain compromise with confidence.

Practical implication: Inventory connected apps by scope and privilege, then remove or constrain overprivileged integrations.

Threat narrative

Attacker objective: The attacker wants to expand one SaaS foothold into broad, multi-application access that exposes sensitive data and administrative control across the ecosystem.

1. Entry occurs when an attacker compromises one SaaS application, steals an OAuth token, or harvests API credentials from an integration path.
2. Credential access and discovery happen as the attacker enumerates which downstream SaaS applications, scopes, and endpoints the trusted connection can reach.
3. Escalation follows when overprivileged integrations or refresh tokens are used to pivot into higher-value applications and maintain persistent access.
4. Impact is achieved when the attacker reaches sensitive data or administrative functions across multiple SaaS environments without triggering traditional endpoint or network alerts.

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.
• GitHub OAuth token breach 2022: Stolen Heroku and Travis CI OAuth tokens let an attacker clone private repos from dozens of orgs, including npm, and reuse an AWS key found in them.

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

Cross-application trust is the new lateral movement perimeter: SaaS breaches now turn on delegated relationships, not network adjacency. The critical control question is no longer which host was reached, but which application was trusted to reach what. That shifts identity governance from isolated tenant administration to oversight of the integration graph. Practitioners should treat SaaS-to-SaaS trust as a first-class governance surface.

Bearer credential sprawl creates identity blast radius: OAuth tokens, refresh tokens, API keys, and service accounts all become movement primitives once an attacker lands in a connected platform. Each credential carries different persistence and revocation properties, which means the real risk is not only theft but the length of time the token remains operational. The practitioner implication is that lifecycle control has to follow the credential across every SaaS boundary it can touch.

Integration privilege is often more dangerous than user privilege: A low-friction SaaS integration can quietly hold broader access than any individual user session. That is why privilege reviews limited to human accounts miss the paths attackers actually use. The field needs to recognise that overprivileged NHI controls now define SaaS blast radius as much as human IAM does. Practitioners should prioritise scope governance for machine-to-machine access.

Traditional detection architecture underestimates SaaS compromise because it assumes visible movement: Endpoint, perimeter, and single-platform monitoring all presuppose that attacker activity will cross a control boundary they can observe. SaaS lateral movement breaks that assumption by remaining inside authenticated API flows. The implication is that SecOps and IAM teams must share a common model of cross-platform identity behaviour rather than treating SaaS telemetry as an isolated alert stream.

Identity security for SaaS now depends on governing delegated reach, not just authenticating callers: The article’s strongest lesson is that authentication success can coexist with catastrophic abuse. That makes scope design, token lifetime, and offboarding discipline the meaningful control set for this problem space. Practitioners should reframe SaaS security around who can act on behalf of whom, and for how long.

From our research library:

• 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.

What this signals

Identity governance has moved into the integration layer: SaaS environments now expose trust relationships that sit outside traditional network and endpoint controls. That means the governance model has to inventory delegated access, token scope, and cross-application reach as part of routine identity oversight.

Blast radius is the decisive control variable: When a single token can open multiple downstream applications, the question is not just whether access exists but how far it travels. Practitioners should focus on reducing delegated reach and shortening the useful life of credentials that can be replayed across services.

For practitioners

• Map the SaaS integration graph Document which applications, service accounts, OAuth apps, and API keys can reach each SaaS system, then label the scopes and privileges they carry.
• Shorten token lifetime and scope Reduce OAuth scopes and refresh-token persistence wherever integrations can operate with narrower delegated access.
• Remove unnecessary third-party connections Retire integrations that do not support a current business use case, especially those that bridge low-trust tools into high-value SaaS platforms.
• Build cross-platform anomaly detection Correlate API usage, identity context, and timing across multiple SaaS platforms so that abnormal pivots stand out from normal integration traffic.
• Test revocation against live dependencies Validate that revoking a token or disabling a service account actually stops access in every connected application, including downstream refresh paths.

Key takeaways

• SaaS lateral movement exploits trusted integrations and bearer credentials, so standard endpoint and perimeter tooling misses the most relevant activity path.
• The breach impact grows when OAuth scopes, refresh tokens, and service account permissions are broader than the business need.
• Practitioners should govern the integration graph, reduce delegated reach, and validate that revocation actually removes downstream access.

Key terms

• SaaS Lateral Movement: The movement of an attacker across cloud applications using valid tokens, integrations, and APIs instead of network exploits. It is a governance problem because the attacker follows trusted business connections, which can make malicious activity look normal in logs.
• 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.
• Transformation Graph: A transformation graph is a directed structure that connects multiple rewrite rules into an ordered refactoring workflow. Each node represents a rule, and edges define how matches, captured values, and scope flow between rules. This supports controlled cascading changes instead of isolated, one-off edits.
• Blast Radius: The potential scope of damage if a specific credential or identity is compromised. Identities with broad permissions have a larger blast radius and represent a higher priority for least-privilege enforcement and security controls.

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.