TL;DR: SaaS breaches surged 300% in 2024, and once initial access is established the average time to compromise core systems falls to 9 minutes, according to Obsidian Security. The pattern shows that token abuse, not password weakness, is now the more durable enterprise risk, and identity governance has to follow the non-human trust chain.
At a glance
What this is: This analysis shows how attackers compromise SaaS applications through OAuth tokens, session hijacking, and trusted integrations rather than traditional malware or perimeter intrusion.
Why it matters: It matters because IAM teams need to govern non-human identities, not just users, or they will miss the access paths attackers now exploit most reliably.
By the numbers:
- SaaS breaches surged 300% in 2024.
- The average enterprise uses 342 SaaS applications.
- 28% of organizations experienced cloud or SaaS-related data breaches in the past year.
👉 Read Obsidian Security's analysis of SaaS attack techniques and OAuth abuse
Context
SaaS attack techniques are the methods attackers use to abuse trusted cloud application relationships, especially OAuth tokens, API keys, and session tokens. In this model, the primary governance problem is not endpoint compromise but delegated access that can persist after passwords are changed and MFA has been enforced.
The article's central claim is that SaaS environments have become the new identity attack surface because integrations create large numbers of non-human identities that many enterprises do not inventory or monitor well. That starting point is typical for modern cloud estates, which means the control gap is systemic rather than exceptional.
Key questions
Q: How should security teams govern OAuth tokens in SaaS environments?
A: Treat OAuth tokens as governed credentials with owners, scopes, expiration, and revocation paths. Review them on a schedule, remove unused grants, and tie every high-risk token to a business justification. If a token can reach production data, it needs the same oversight as privileged human access.
Q: Why do SaaS attacks often bypass MFA?
A: Because MFA only protects the login event, while a valid session token or OAuth bearer token can remain trusted after authentication. Once the attacker has the token, they may not need another prompt. That is why token lifecycle controls matter as much as sign-in policy.
Q: What is the difference between SaaS lateral movement and traditional network lateral movement?
A: Traditional lateral movement crosses systems by exploiting network trust and internal connectivity. SaaS lateral movement crosses applications through valid tokens, approved integrations, and API calls that appear legitimate. The first is a perimeter problem, while the second is an identity and authorization problem.
Q: Should organisations prioritise token rotation or app inventory first?
A: Start with app inventory, because you cannot govern what you cannot see. Once the full integration map exists, rotation and scope reduction become far more effective. In practice, inventory exposes ownership gaps, stale apps, and the largest blast-radius paths before you spend effort on renewal.
Technical breakdown
OAuth token abuse in SaaS environments
OAuth tokens are bearer credentials, which means possession is enough to use them. In SaaS ecosystems, they often outlive user sessions, bypass password changes, and continue working after MFA resets because the application trusts the token, not the person who originally approved it. Consent phishing, token theft from browser storage, and compromised third-party integrations all exploit the same architectural assumption: delegated access is safe if the original authorization looked legitimate. For IAM teams, the issue is not only authentication but the lifecycle of tokens, scopes, and app consent.
Practical implication: Treat OAuth grants as governed credentials and review them with the same discipline as privileged accounts.
Session hijacking and why browser trust is fragile
Session hijacking steals the authenticated state rather than the password. Once an attacker captures a session cookie or token, they inherit the user's active access without triggering a fresh login challenge. In SaaS tools, this is especially dangerous because browser extensions, developer tools, and adversary-in-the-middle interception can preserve enough session context for silent access. The result is a control gap between identity verification at login and trust in every action that follows. Security teams need visibility into session use, not only sign-in events.
Practical implication: Add controls that detect abnormal session reuse, unusual device context, and impossible travel after authentication.
Why SaaS lateral movement is different from network lateral movement
In SaaS environments, lateral movement happens through authorized application relationships rather than network hops. Attackers chain access across mailboxes, document stores, customer records, and connected tools by using valid tokens and approved APIs. That makes the movement look like normal business activity unless controls understand which non-human identities are talking to which resources and why. The security boundary is therefore the integration graph, not the perimeter. This is where traditional monitoring fails, because the traffic is legitimate even when the intent is not.
Practical implication: Map application-to-application trust paths and flag any token that reaches systems it has never touched before.
Threat narrative
Attacker objective: The attacker wants durable, low-noise access to sensitive SaaS data and downstream integrations without triggering endpoint or perimeter defenses.
- Entry occurs through compromised SaaS credentials, excessive OAuth permissions, or stolen session tokens rather than malware or network exploitation.
- Escalation happens when the attacker reuses trusted tokens and weakly governed integrations to move from a legacy account or test app into production resources.
- Impact follows as the attacker exports data through legitimate APIs and connected applications while blending into normal SaaS activity.
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 attack techniques expose an identity governance gap, not a tooling gap. The issue is that enterprises still treat many SaaS integrations as convenience features rather than governed access paths. Once an OAuth token or session token is issued, the trust model becomes much broader than most review processes assume. Practitioners should therefore audit delegated access as a core IAM control, not as an app-admin task.
Identity blast radius is the right concept for modern SaaS risk. A single compromised non-human identity can connect mail, storage, CRM, and analytics systems in a way that bypasses traditional segmentation. That is why compromise can spread faster in SaaS than in many on-premises environments. Teams should measure blast radius by connected permissions, not by the number of affected endpoints.
Token lifecycle governance matters more than password hygiene once integrations proliferate. Password resets, MFA prompts, and endpoint tooling do not revoke a valid token that still has scope and trust. That makes token inventory, consent review, and rotation policy the practical control plane for SaaS identity security. Organisations that do not govern the full lifecycle of non-human credentials are defending the wrong layer.
The hidden layer between SaaS apps is now a primary attack surface. The article's examples show that abuse often happens inside trusted integrations, where activity resembles ordinary business traffic. This is where visibility needs to move from application logs to relationship-aware identity telemetry. Practitioners should assume that the most dangerous path is the one that looks administratively normal.
SAAS compromise is becoming an NHI problem before it is a user problem. That shift should change board-level reporting, incident response planning, and access review scope. When service accounts, OAuth apps, and tokens are treated as first-class identities, the organisation can reduce both dwell time and blast radius. Security teams should align governance with the identities attackers actually use.
From our research:
- 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
- A separate finding shows only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, which explains why delegated access still outpaces governance in practice.
- For a broader control framework, see 52 NHI Breaches Analysis for breach patterns that show how unmanaged credentials turn into lateral movement.
What this signals
Identity governance for SaaS now has to extend into the application graph. As organisations add more integrations, the useful control boundary is no longer the account alone but the relationship between accounts, apps, and data. With 1 in 4 organisations already investing in dedicated NHI security capabilities, the market is signalling that token oversight is moving from niche hygiene to programme requirement.
The operational signal is clear: teams should build detection around non-human identity behavior, not only sign-in logs or endpoint telemetry. If a token suddenly reaches a mailbox, dataset, or region it has never touched before, the control should fire immediately. That approach aligns with a Zero Trust Architecture mindset and with external guidance such as the NIST Cybersecurity Framework 2.0 and the OWASP Non-Human Identity Top 10.
Token trust debt: the longer an organisation leaves delegated access unmanaged, the more likely that routine SaaS convenience becomes durable attack surface. Practitioners should expect more incidents that look like normal business activity until the blast radius is already large. The response is to collapse standing trust, shorten token lifetimes, and make app approval a monitored security event.
For practitioners
- Inventory all OAuth grants and service integrations Build a live inventory of SaaS applications, delegated permissions, service accounts, and webhooks for critical systems such as email, CRM, and document stores. Prioritise unowned or stale integrations first.
- Review and constrain token scopes Identify tokens with broad read, write, or admin permissions and compare them to actual application use. Reduce scopes, remove unused grants, and require re-approval for high-risk access.
- Monitor for abnormal non-human identity behavior Alert on OAuth tokens, API keys, or sessions that access new datasets, new tenants, or new geographic regions. Relationship-aware detection is more useful than raw login anomaly checks.
- Treat third-party app approval as a privileged action Apply approval workflow, owner assignment, and periodic recertification to every new SaaS integration. A single click can create durable access that outlives the original business need.
Key takeaways
- SaaS compromise now often begins with trusted tokens and integrations rather than malware or endpoint exploitation.
- The scale of the problem is already material, with breach frequency and compromise speed both moving in the attacker’s favor.
- Practitioners should govern delegated access, map integration trust, and treat non-human identity lifecycle controls as core IAM work.
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 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-03 | Token rotation and scope control are central to the article's attack pattern. |
| NIST CSF 2.0 | PR.AC-4 | SaaS integration trust maps directly to access control and least privilege. |
| NIST Zero Trust (SP 800-207) | The article shows why continuous verification is needed after token issuance. |
Apply continuous verification to SaaS sessions and revoke trust when behavior deviates from expected use.
Key terms
- OAuth Token: A bearer credential that lets an application access resources on a user's behalf. In SaaS environments, the token often matters more than the password because it can persist after login changes and may continue working until it is explicitly revoked or expires.
- Non-Human Identity: A digital identity used by software rather than a person, including service accounts, API keys, tokens, certificates, and AI agents. These identities need ownership, lifecycle control, and monitoring because they often carry persistent access into critical systems.
- 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.
- Session Hijacking: The theft or reuse of an authenticated browser or application session so the attacker can act as the victim without repeating the login process. In SaaS, this can bypass password resets and MFA because the existing session remains trusted until it is invalidated.
Deepen your knowledge
SaaS token governance and non-human identity lifecycle controls are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is trying to close integration-driven access gaps, it is worth exploring.
This post draws on content published by Obsidian Security: SaaS attack techniques and how threat actors compromise SaaS applications. Read the original.
Published by the NHIMG editorial team on 2026-02-04.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org