SaaS lateral movement is invisible to traditional security tools

At a glance

What this is: This guide explains how lateral movement in SaaS security works through trusted integrations and token-based access, and why traditional tools miss it.

Why it matters: IAM and NHI teams need to treat SaaS integrations as an access plane, because compromised non-human identities can move laterally without triggering network-centric defenses.

By the numbers:

• Real incident: the Salesloft-Drift breach allowed attackers to move from Drift to more than 700 Salesforce instances through chained OAuth access.

👉 Read Obsidian Security's full analysis of SaaS lateral movement and OAuth token abuse

Context

SaaS lateral movement is the practice of moving from one cloud application to another through trusted connections rather than through network segments. In NHI terms, the access path is often an OAuth token, API key, service account, or integration that was originally created for routine business use.

That matters because IAM controls built around users, subnets, or endpoint telemetry do not model the hidden relationships between connected applications. When an attacker inherits a valid non-human identity, the breach can expand through legitimate API calls while EDR, SIEM, and CASB see only ordinary cloud activity.

For most enterprises, the problem is not that SaaS lacks controls, but that the controls are fragmented across platforms and rarely evaluated as a shared blast radius. The starting position described here is typical, not exceptional, which is why SaaS-to-SaaS movement remains a practical gap in NHI governance.

Key questions

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: Why do traditional IAM and SIEM controls miss SaaS lateral movement?

A: Traditional IAM and SIEM tools are usually optimized for human login events, endpoint telemetry, and isolated application logs. SaaS lateral movement often uses valid OAuth tokens or API keys, so there is no suspicious authentication event to flag. The attack happens inside trusted cloud-to-cloud traffic, which makes single-system monitoring incomplete.

Q: What is the difference between user compromise and SaaS integration compromise?

A: User compromise usually starts with a person’s account and is constrained by human authentication controls. SaaS integration compromise starts with a non-human identity such as an OAuth grant, API key, or service account, then moves through connected applications. The second pattern is harder to see because the attacker is using delegated machine access, not a visible user session.

Q: Should organisations treat OAuth tokens like standing access?

A: Yes, because OAuth tokens can behave like persistent access when refresh tokens survive password resets and scopes are too broad. Organisations should manage them as production credentials with ownership, expiry, review, and revocation controls. If a token can reach sensitive data or multiple apps, it should be governed like privileged access.

Technical breakdown

How OAuth tokens enable SaaS lateral movement

OAuth tokens are delegated credentials that let one application act on behalf of a user or service without repeated logins. In SaaS environments, attackers prefer bearer-style tokens because possession alone is enough to access downstream systems. Refresh tokens extend that risk by keeping access alive after password resets or session expiry. The key failure mode is not broken authentication, but over-trusted delegation across applications. Once one integration is compromised, the attacker can enumerate connected apps, reuse granted scopes, and pivot through approved API paths while appearing authorized.

Practical implication: Inventory OAuth grants, shorten token lifetimes, and revoke high-risk refresh tokens as soon as abnormal cross-app activity appears.

Why API credentials and service accounts create hidden blast radius

API keys and service account credentials often operate outside normal user controls, yet they frequently hold broader permissions than human users. They are used by automation, CI/CD, reporting, and sync jobs, which makes them easy to overlook during access reviews. When those identities are overprivileged, a compromise in one SaaS platform becomes a route into many others. The architectural problem is cross-application trust without cross-application governance. Security teams need to treat these identities as production access, not as background plumbing.

Practical implication: Classify every service account and API key by connected systems, privilege level, and rotation owner before an incident forces the mapping.

Why EDR, SIEM, and CASB miss SaaS-to-SaaS movement

EDR watches endpoints, SIEM correlates logs, and CASB focuses on cloud usage, but SaaS lateral movement happens inside cloud APIs between trusted applications. That means the attack may generate no suspicious process, no endpoint payload, and no abnormal user login. The attacker can exploit valid permissions through legitimate API calls, so each platform sees isolated, low-signal events. Detection therefore depends on behavioral baselines that correlate identity, token use, and application relationships across the full SaaS estate, not on single-system alerts.

Practical implication: Build detections around cross-app API patterns, not just authentication anomalies or endpoint events.

Threat narrative

Attacker objective: The objective is to expand access from one compromised SaaS application into multiple downstream environments while remaining inside legitimate cloud API traffic.

1. Entry occurs when an attacker compromises one SaaS application or steals an OAuth token, API key, or service account credential tied to an integration.
2. Escalation follows when the attacker enumerates connected applications and reuses delegated scopes to access downstream systems with broader permissions.
3. Impact occurs when the attacker exfiltrates data, modifies records, or reaches additional customer environments through chained SaaS trust relationships.

Breaches seen in the wild

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

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

NHI Mgmt Group analysis

SaaS lateral movement is really NHI blast-radius abuse, not just credential theft. The security failure is the ability to reuse one trusted non-human identity across multiple applications with minimal friction. That means the governing question is not whether a token is valid, but how far that token can travel before controls stop it. Practitioners should treat every integration as a potential lateral path.

Ephemeral access alone does not solve SaaS trust debt. Short-lived tokens reduce exposure time, but they do not fix excessive scopes, missing correlation, or unowned integrations. A short-lived credential can still move very quickly through a large SaaS estate. The practical conclusion is that lifecycle controls must be paired with topology-aware monitoring.

Traditional identity controls fail when the application is the perimeter. SaaS ecosystems invert the old model because trust is encoded in APIs, app grants, and refresh tokens rather than in network segmentation. This creates a governance gap that sits between IAM, SecOps, and SaaS administration. Teams need shared ownership of the access plane, or the blind spot remains.

Integration sprawl is now an attack surface management problem. Every additional OAuth connection increases the number of places an attacker can pivot after the first compromise. That expands incident scope even when the original breach is contained. Practitioners should manage integrations as critical assets, with review, restriction, and revocation processes equal to their data sensitivity.

From our research:

• Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which makes app-to-app lateral movement harder to detect and contain.
• The forward pivot is to treat connected applications as governed identity paths, as discussed in Top 10 NHI Issues.

What this signals

Identity blast radius is the operational metric that matters here. Once a single SaaS integration can open access to multiple connected systems, the issue is not the credential itself but the number of downstream paths it can unlock. Teams should measure how far each OAuth grant, API key, or service account can travel before revocation or segmentation stops it.

With only 1.5 out of 10 organisations highly confident in securing NHIs, the governance gap is structural rather than tactical. That confidence gap should push practitioners toward ownership models, topology mapping, and shorter review cycles for non-human access.

Security programmes should prepare for a world where SaaS connections are treated as first-class access relationships. That means integrating NHI review into SaaS procurement, requiring revocation workflows for every connector, and validating whether each app-to-app trust path still has a business justification.

For practitioners

• Map every SaaS integration path Build an inventory of which applications connect to which others, what scopes they hold, and which data they can reach. Include owner, business purpose, and revocation path so that incident response can isolate the right connections quickly.
• Enforce least privilege on OAuth scopes Review delegated permissions for every app-to-app connection and remove write, delete, and admin access unless the workflow truly requires it. Treat broad scopes as standing blast radius, not convenience.
• Automate rapid token revocation Create a playbook that revokes OAuth tokens, refresh tokens, and API credentials within minutes of suspicious cross-app activity. Link revocation to detection thresholds rather than waiting for manual confirmation.
• Correlate identity across SaaS platforms Use analytics that connect the same token, service account, or integration to activity in multiple applications. The goal is to detect movement patterns that would look normal if viewed in isolation.
• Reduce integration sprawl before it becomes incident scope Retire unused connectors, block unapproved integrations, and require security review for new app-to-app trust. The smaller the integration graph, the fewer lateral paths an attacker can exploit.

Key takeaways

• SaaS lateral movement turns trusted integrations into attack paths that bypass network-centric security tools.
• OAuth tokens, API credentials, and service accounts are the main non-human identities that expand blast radius across connected apps.
• Practitioners should govern SaaS integrations as production access, with scope minimisation, rapid revocation, and cross-platform correlation.

Key terms

• SaaS Lateral Movement: SaaS lateral movement is the act of moving from one cloud application to another through trusted integrations, OAuth grants, API keys, or service accounts. It matters because the attacker can expand access without touching endpoints or network segments, which makes traditional perimeter-centric detection less effective.
• OAuth Token: An OAuth token is a delegated credential that allows an application to access another service on behalf of a user or system. In SaaS environments, it can become a lateral movement mechanism when scopes are broad, refresh tokens persist, or the token is stolen from an integration chain.
• Non-Human Identity: A non-human identity is any machine-operated credential or autonomous actor used to authenticate and act in systems, including service accounts, API keys, tokens, certificates, bots, workloads, and AI agents. These identities often have broad, persistent, or poorly reviewed privileges, making them central to SaaS governance.

Deepen your knowledge

SaaS lateral movement and non-human identity governance are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are mapping app-to-app trust paths in your environment, it is worth exploring.

This post draws on content published by Obsidian Security: What is Lateral Movement in SaaS Security? Read the original.