Notifications
Clear all
Topic starter
15/08/2026 6:10 pm
TL;DR: OAuth tokens, session cookies, and API keys let attackers bypass MFA entirely in SaaS environments, according to Obsidian Security’s analysis of Salesloft-Drift and related token abuse patterns. The real issue is post-authentication access governance: once a bearer credential exists, traditional login-centric controls no longer define the trust boundary.
NHIMG editorial — based on content published by Obsidian Security: SaaS Supply Chain MFA Bypass Explained
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.
Questions worth separating out
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.
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.
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.
Practitioner guidance
- 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.
- Shorten token lifetime and revoke on risk Set aggressive expiry and explicit revocation workflows for refresh tokens and high-value API credentials.
- Add behavioural monitoring for valid credentials Detect anomalous API call patterns, unusual source locations, abnormal data volumes, and new SaaS-to-SaaS paths.
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
👉 Read Obsidian Security's analysis of MFA bypass in SaaS supply chains →
MFA bypass in SaaS: what identity teams are missing?
Explore further
15/08/2026 6:18 pm
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.
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.
A question worth separating out:
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.
👉 Read our full editorial: MFA bypass in SaaS exposes the hidden layer of NHI risk
