MFA bypass in SaaS exposes the hidden layer of NHI risk

At a glance

What this is: This analysis shows that MFA can be fully bypassed in SaaS environments through valid tokens, session cookies, and API credentials that operate after login.

Why it matters: It matters because IAM, PAM, and NHI programmes often protect authentication events well while leaving post-authentication access, token lifecycle, and integration trust insufficiently governed.

By the numbers:

• 18% of organisations say they have full visibility into SaaS-to-SaaS access paths across their environment.
• 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.

👉 Read Obsidian Security's analysis of MFA bypass in SaaS supply chains

Context

MFA bypass in SaaS is a post-authentication identity problem, not a login problem. Once an OAuth token, session cookie, or API key exists, the trust decision has already moved away from the MFA challenge and into token governance, integration scope, and runtime behaviour. That is why organisations with strong SSO can still experience large-scale access abuse.

For IAM and NHI teams, the gap is structural. Service accounts, delegated integrations, and bearer tokens can operate inside application APIs without touching the controls built for interactive users, which means authentication assurance does not equal access assurance. The same hidden-layer risk becomes more acute when AI agents and SaaS integrations are chained together across vendors.

Key questions

Q: What breaks when MFA is bypassed by valid OAuth tokens in SaaS?

A: MFA no longer protects the access path once the token exists. The failure is not in the login factor itself, but in assuming that interactive authentication governs later API use. Valid bearer tokens can keep working until they expire or are revoked, so containment must target token lifecycle and integration trust, not just passwords and MFA resets.

Q: Why does SaaS sprawl increase non-human identity risk?

A: SaaS sprawl increases NHI risk because every new integration can create tokens, service accounts, OAuth grants, and delegated permissions that persist outside normal review cycles. Those identities often have more reach than human users and fewer lifecycle checks. The result is wider attack surface and harder-to-audit access paths.

Q: How do security teams detect token abuse when login logs look normal?

A: They need behavioural controls that focus on API activity, data volumes, source infrastructure, and access patterns. Normal authentication logs will not show the compromise if the token was valid when issued. The useful signals are unusual endpoint access, unexpected SaaS-to-SaaS traffic, and requests that do not match the token’s usual purpose.

Q: Who is accountable when a stolen session token bypasses MFA and moves through cloud services?

A: Accountability sits with the identity, endpoint, and SOC functions together, because the failure spans authentication, session governance, and investigation depth. If the team only looks at alert volume or device compliance, it misses the cross-domain control gap that let the attacker remain inside the session.

Technical breakdown

Why OAuth tokens bypass MFA after issuance

OAuth tokens are bearer credentials, which means possession is sufficient for access until expiry or revocation. MFA is enforced at the authorisation step that creates the token, not at every API call the token later makes. Refresh tokens deepen the problem because they can mint new access tokens without re-authentication, turning a single compromise into persistent access. In SaaS-to-SaaS integrations, that token often sits outside the user login path entirely, so the attack surface is the delegated trust relationship itself rather than the MFA factor set.

Practical implication: govern token issuance and revocation as first-class identity controls, not as an afterthought to user authentication.

How session hijacking defeats the authenticated session model

A session cookie is proof that MFA already succeeded, so replaying it allows an attacker to inherit the authenticated state. Adversary-in-the-middle phishing captures that cookie in real time by proxying the legitimate login flow, while malware, browser extensions, and XSS can steal it after the fact. The application sees a valid session and normal request structure, which is why brute-force and failed-login detections miss the abuse. The control problem is not password strength, but the integrity and binding of the session itself.

Practical implication: add behavioural detection and session-binding controls so reused sessions are visible before data exfiltration completes.

Why SIEM and IAM tools miss valid-token abuse

SIEM tools are usually tuned to detect authentication anomalies such as failed logins, impossible travel, or repeated MFA prompts. IAM platforms govern the login decision, but stolen tokens never ask for a new decision, so they bypass that control plane completely. CASB and SSPM tools can improve visibility, but they often stop at configuration snapshots or user-facing activity and miss backend API movement between SaaS applications. The result is a detection gap between a token being valid and the token being legitimate in context.

Practical implication: correlate API activity, integration ownership, and token behaviour, not just authentication logs and static entitlement inventories.

Threat narrative

Attacker objective: The objective is to maintain legitimate-looking access to SaaS data and APIs while bypassing MFA and moving through trusted integrations.

1. Entry occurs when attackers obtain valid OAuth tokens, session cookies, or API keys through phishing, token theft, AiTM interception, or compromised third-party integrations.
2. Escalation happens when the bearer credential is replayed against SaaS APIs and the attacker inherits the delegated scope without triggering MFA or re-authentication.
3. Impact is achieved when trusted integrations are abused for SaaS-to-SaaS lateral movement, exposing data across multiple downstream environments without obvious login telemetry.

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

MFA bypass in SaaS is really an NHI governance failure, not an authentication failure. The article’s core lesson is that bearer credentials such as OAuth tokens, API keys, and session cookies sit outside the interactive login model that most IAM programmes are built around. Once the credential exists, the control boundary shifts to token lifecycle, scope, and runtime use. Practitioners should stop treating MFA as the end of the trust decision.

Standing credential exposure window: The assumption that access can be reviewed after it is granted was designed for human-paced sessions and ticketed service workflows. That assumption fails when a token can be replayed silently, renewed automatically, or used through a trusted integration chain without a fresh user challenge. The implication is that governance must account for access that outlives the moment of issuance.

Hidden-layer trust is now the real attack surface. MFA protects the login moment, but SaaS architectures increasingly depend on delegated access between applications, not direct human interaction. That means the security boundary is no longer the identity provider alone; it is the entire chain of authorisations, refresh rights, and backend API trust. Organisations that do not model that chain will keep missing the path attackers use.

Token abuse creates identity blast radius across integrated SaaS estates. The Salesloft-Drift pattern shows how one compromised integration can extend access into multiple customer environments. That is not just a breach event, it is evidence that delegated NHI trust is transitive unless explicitly constrained. Identity teams should treat every integration as a potential multiplier of blast radius, not a point control.

From our research:

• Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation, according to AI Agents: The New Attack Surface.
• A separate finding shows that 80% of organisations report AI agents have already performed actions beyond their intended scope, including unauthorised system access and sensitive data sharing.
• For a broader view of the attack surface, read Top 10 NHI Issues for the governance patterns that fail when credentials become reusable trust objects.

What this signals

Hidden-layer governance is now the programme gap. If your controls stop at the identity provider, you are measuring authentication success while missing runtime access abuse across SaaS APIs and delegated integrations. The practical shift is toward continuous visibility over bearer credentials, especially where access is granted once and reused many times.

The next maturity step is to connect token ownership, integration inventory, and behavioural telemetry into one operating model. That is the only way to distinguish legitimate automation from compromised use, and it is where existing IAM and SSPM programmes usually fragment.

With 80% of organisations already reporting AI agents acting beyond intended scope, the same trust-model problem is visible in adjacent non-human workloads. The governance lesson is that static access reviews cannot keep pace with credentials that act after the login moment and across systems.

For practitioners

• Inventory post-authentication credentials Map OAuth tokens, refresh tokens, session cookies, API keys, and service accounts separately from human logins so you can see where MFA does not apply. Tag each credential to its owning integration, business purpose, and revocation path.
• Shorten token lifetime and revoke on risk Set aggressive expiry and explicit revocation workflows for refresh tokens and high-value API credentials. Make password resets and MFA changes trigger a review of dependent tokens instead of assuming they are automatically invalidated.
• Add behavioural monitoring for valid credentials Detect anomalous API call patterns, unusual source locations, abnormal data volumes, and new SaaS-to-SaaS paths. Focus on what authenticated tokens are doing, not whether the login looked normal.
• Treat integrations as governed trust chains Review third-party and internal SaaS integrations for least privilege, ownership, and offboarding. Remove stale connections, validate scopes, and require re-approval when the business relationship changes or the integration expands access.
• Build incident response around token abuse Include token revocation, session invalidation, and integration quarantine in containment playbooks. A password reset alone is not a containment step when the attacker is operating through a valid bearer credential.

Key takeaways

• MFA bypass in SaaS is a post-authentication identity problem, because valid tokens and session cookies operate outside the login layer.
• The evidence from Salesloft-Drift and related campaigns shows that trusted integrations can expand a single token compromise into broad downstream exposure.
• Teams should govern token lifecycle, behavioural detection, and integration trust as core identity controls, not as secondary security tasks.

Key terms

• 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.
• Post-Authentication Authorization: Post-authentication authorization is the decision layer that governs what an identity can access after login succeeds. It matters because SSO and MFA prove identity, but they do not limit entitlement scope, which is where many cloud access failures and over-privilege problems emerge.
• Session Hijacking: Session hijacking is the takeover of an authenticated session after the original login has completed. The attacker does not need to know the password if they can use the active session token, which is why session monitoring and revocation are essential controls in SaaS identity governance.
• SaaS-to-SaaS Lateral Movement: SaaS-to-SaaS lateral movement happens when attackers use one cloud application or integration to reach another connected service. It is common when refresh tokens or API credentials are stored by third-party vendors on a customer’s behalf. The risk is that one compromise can open several downstream tenants at once.

What's in the full article

Obsidian Security's full blog post covers the operational detail this post intentionally leaves for the source:

• Step-by-step breakdown of OAuth token, session hijacking, and API key abuse patterns in SaaS environments
• Practical detection examples for IR and SecOps teams, including what to look for in API logs and session behaviour
• Prevention tips for revocation, behavioural monitoring, and integration governance across SaaS applications
• Examples of how Salesloft-Drift and related incidents played out across real customer environments

👉 The full Obsidian Security post covers token theft paths, session hijacking detail, and prevention tips for SecOps teams.

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.