SaaS attack techniques expose the governance gap in IAM

At a glance

What this is: This analysis explains how attackers use OAuth tokens, API keys, session hijacking, and SaaS-to-SaaS lateral movement to compromise cloud applications and why conventional IAM visibility misses the abuse path.

Why it matters: It matters because IAM teams now have to govern non-human trust relationships, not only human authentication, or legitimate integrations will become the easiest path to data access and lateral movement.

Context

SaaS attack techniques are exploiting the trust fabric between applications rather than breaking through a network perimeter. In this model, OAuth tokens, API keys, and inherited integration permissions become the real control surface, and the governance gap appears when teams can authenticate users but cannot see how non-human access is used across connected services.

The article argues that legacy IAM assumptions break down in SaaS because bearer tokens can outlive passwords, MFA events, and user awareness. Once a token is issued to an application or integration, it can operate independently of the human login session that originally approved it, which is why compromise can spread through trusted app connections instead of through endpoint malware.

Key questions

Q: What breaks when OAuth tokens are treated as permanent access?

A: Permanent OAuth access turns a delegated token into standing privilege, which means a compromise can be reused until someone revokes it. That increases the chance of cross-platform data exposure, secret harvesting, and lateral movement. Organisations need identity ownership, scope review, and revocation discipline for tokens, not just for human accounts.

Q: Why do CRM and SaaS integrations increase lateral movement risk?

A: Because one approved connection can extend identity trust across multiple systems, including SSO, collaboration, and data platforms. The attacker does not need to steal every password if they can leverage a legitimate trust event to reach connected services. That is why integration inventory and token governance matter as much as endpoint security.

Q: What signs show that SaaS token abuse is becoming a persistence problem?

A: Watch for unexpected app reauthorisations, unusual API query bursts, deleted jobs or logs, and access that continues after normal password resets. Those signals suggest the attacker is operating through delegated trust rather than interactive login. The control question is whether the organisation can revoke the integration cleanly and trace all affected accounts.

Q: How should IAM teams govern third-party SaaS access after a breach?

A: They should recertify every downstream entitlement tied to the affected integration, identify which apps inherited trust from the compromised connection, and revoke anything without a clear owner. The same review should cover dormant test apps, vendor connectors, and service accounts, because each can preserve access beyond the original incident.

Technical breakdown

How OAuth tokens become the attack path

OAuth tokens are bearer credentials, which means possession is enough for use. In SaaS environments, that matters because the token often carries delegated access to mailboxes, files, CRM data, or admin functions without requiring the original password or MFA prompt again. Attackers abuse consent phishing, token theft from browsers or repos, and over-permissioned test applications to obtain that access. The critical failure is not OAuth itself but the governance model around it: if teams treat token issuance as a one-time authentication event, they miss the fact that the token is now a standing non-human credential with its own lifecycle.

Practical implication: Track every OAuth grant as a governed credential and review its scope, lifespan, and owning application.

Why SaaS lateral movement is different from network lateral movement

Traditional lateral movement depends on moving across hosts or subnets after initial compromise. SaaS lateral movement happens through legitimate application relationships, where one compromised integration or token can access a second system through normal API calls. That makes the activity look like business-as-usual traffic unless the organisation can map which app is calling which resource and for what reason. The problem becomes worse in multi-tenant SaaS and workflow chains, where one token can cascade into several downstream systems without touching an endpoint or network control that would normally raise an alert.

Practical implication: Model SaaS-to-SaaS relationships so unusual cross-application access becomes visible before data is exported.

Why traditional controls miss token abuse

CASBs, SIEMs, and EDR each see a different slice of the problem, but none of them fully explain how a token is being used in context. A CASB may see traffic without understanding which credential initiated it, SIEM may log the event without behavioural baseline, and EDR is irrelevant when the attacker never lands on an endpoint. That leaves a blind spot around non-human identities such as service accounts, API keys, and OAuth integrations. The technical gap is behavioural context: the security stack often records that access occurred, but not whether the access pattern matches the identity’s normal purpose.

Practical implication: Correlate token usage with identity intent and normal application behaviour, not just with authentication success.

Threat narrative

Attacker objective: The objective is to turn trusted SaaS access into broad, legitimate-looking data access that survives password resets and spreads across connected applications.

1. Entry begins with credential-based access, consent phishing, or a compromised third-party OAuth integration that gives attackers a valid foothold in the SaaS environment.
2. Credential access is then converted into token abuse, where attackers use bearer tokens or over-privileged integrations to operate without further password or MFA checks.
3. Escalation occurs through SaaS-to-SaaS lateral movement, allowing the attacker to reach production mailboxes, customer data, or connected applications through legitimate API paths.
4. Impact is data theft at scale, including sensitive SaaS content and downstream credentials that extend compromise into additional environments.

Breaches seen in the wild

• Salesloft OAuth token breach: hackers stole OAuth tokens to access Salesforce data via Salesloft.
• 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

OAuth governance is now the primary IAM control plane for SaaS risk: The article shows that the decisive question is no longer whether the user authenticated, but whether the token, app, or integration should have been trusted at all. OAuth grants and API keys operate as non-human credentials with their own privilege lifetimes, which means identity governance has to inspect delegated access paths as carefully as human logins. Practitioners should treat every app grant as an access decision that must be owned, reviewed, and revoked on a lifecycle schedule.

Identity does not stop at the browser session: SaaS compromise succeeds because trust is delegated into applications that can continue acting after the original human session is over. That makes the hidden layer of integrations a governance issue, not just a detection issue, because the real access graph is between applications, not only between users and systems. The implication is that IAM programmes need inventory, ownership, and recertification for non-human access paths before they can claim control over the SaaS estate.

Token-based lateral movement is the SaaS equivalent of privilege creep: Once an attacker inherits a trusted integration, the compromise expands through legitimate APIs rather than noisy malware or endpoint tradecraft. That pattern fits OWASP-NHI concerns around overprivileged non-human identities and long-lived secrets, but the broader lesson is that SaaS trust chains now determine blast radius. Practitioners should assume that every unnecessary permission on an integration increases the distance an attacker can travel without resistance.

Trusted integrations have become the new third-party attack surface: The article’s breach examples show that compromise often begins outside the target application and then rides in through delegated SaaS relationships. This is a supply-chain problem in identity form, where one weak app grant can expose many downstream tenants and datasets. The practical conclusion is that third-party access needs the same scrutiny as privileged human access, because inherited trust is now a direct route to data loss.

Behavioral detection is becoming the only durable control layer for SaaS abuse: Static policy checks cannot explain whether an OAuth token is being used in line with its purpose, especially when the activity stays inside legitimate APIs. The named concept here is the hidden layer of SaaS trust: application-to-application relationships that remain invisible until they are abused. Security teams should build controls around token intent, normal resource patterns, and integration ownership, because traditional perimeter logic no longer describes the attack surface.

From our research library:

• The average enterprise SaaS platform connects to 42 or more third-party applications through OAuth tokens, API keys, webhooks and automation platforms.

What this signals

Hidden layer of SaaS trust: The real control problem is the web of delegated access between applications, not only the user account that approved it. Once organisations start governing app-to-app trust as a first-class identity relationship, token abuse becomes easier to classify and harder to miss.

Security teams should expect the SaaS attack surface to keep expanding because integrations are multiplying faster than most identity governance programmes can inventory them. The practical shift is from checking whether a login succeeded to checking whether a non-human credential still has a legitimate reason to exist.

For practitioners

• Inventory every OAuth grant and API key Map which applications, service accounts, and integrations can reach critical SaaS platforms such as email, CRM, and data warehouse services. Include test apps, dormant integrations, and vendor-managed connectors in the same inventory so hidden access does not escape review.
• Revoke excessive permissions on test and legacy apps Find older integrations with broad scopes, especially those that were created for testing or never moved into production governance. Remove permissions that exceed the app’s current business purpose and retire any integration that no longer has an accountable owner.
• Build behavioral baselines for non-human access Establish what normal looks like for each integration, including source, destination, timing, and data volume. Alert on token use that touches new resources, unusual geographies, or SaaS-to-SaaS paths the application has never used before.
• Treat third-party integrations as privileged pathways Apply the same approval, review, and offboarding discipline to connected apps that you apply to admin accounts. If a vendor relationship changes, the token and its downstream entitlements must be reviewed as part of the same access decision.
• Segment detection by credential type Separate human authentication events from bearer-token activity, since password resets and MFA prompts do not interrupt active token use. Detection logic should distinguish a human login from an app credential operating inside a SaaS API.

Key takeaways

• SaaS compromise now rides on delegated trust, where OAuth tokens, API keys, and integrations can be abused even when passwords and MFA are intact.
• The article shows how one compromised app or token can spread access across connected systems, turning normal API traffic into a lateral movement path.
• IAM teams need to inventory, baseline, and recertify non-human access paths or they will keep governing the login while missing the actual control point.

Key terms

• 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.
• 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.
• Consent Phishing: A social engineering attack that persuades a user to approve a malicious OAuth application. The attacker gains delegated access through legitimate authorization rather than stealing a password, which makes the resulting token-based access harder to detect and revoke than a normal sign-in compromise.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

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.