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.
At a glance
What this is: This is an analysis of how SaaS attackers bypass MFA by abusing valid non-human credentials after authentication, with token persistence and SaaS-to-SaaS trust as the core risk.
Why it matters: It matters because IAM and SecOps teams cannot treat login success as the end of access control when OAuth tokens, session cookies, and API keys continue to carry privilege.
Context
MFA does not govern every access path in SaaS. Once a token, session cookie, or API key is issued, that bearer credential can authenticate API activity without returning to the login layer, which leaves post-authentication access outside the scope of conventional MFA monitoring.
That gap matters most in integrated SaaS environments, where third-party connections and backend API calls can extend trust far beyond the original user authentication event. In this model, the identity risk is not just whether MFA was completed, but whether the credential that survived it is still being governed.
The article uses token theft, session hijacking, and OAuth abuse to show that non-human identities often outlive the authentication moment that created them. For IAM, PAM, and SecOps teams, that shifts the control question from login assurance to credential lifecycle and behavioural visibility.
Key questions
Q: What breaks when SaaS access is governed only at the account level?
A: Account-level governance misses the session, grant and integration layers where SaaS access is actually exercised. That leaves security teams able to see who has a permission, but not how far that permission can propagate through connected apps, browser sessions or delegated workflows. The result is a false sense of control and slower containment when trust is abused.
Q: What breaks when a platform stores customer OAuth tokens and API keys without governance?
A: The platform stops being a neutral integration layer and becomes a delegated access repository with live production reach into customer systems. Without inventory, ownership, and revocation controls, the platform can expose many customer environments from a single compromise, and security teams lose the ability to contain access by customer, tool, or credential type.
Q: How should security teams handle token theft in SaaS environments?
A: Treat tokens as delegated non-human identities, not disposable implementation details. Inventory them, assign ownership, restrict scope, and automate revocation for stale or over-privileged access. Then monitor token use for unusual source systems, unusual locations, and unexpected downstream access chains so replayed credentials are caught before they spread.
Q: What should organisations do when a SaaS integration is no longer needed?
A: They should revoke the connection, remove its tokens or service account access, and confirm the data path is no longer active. Offboarding has to cover both the app relationship and the authorizations it accumulated, otherwise the integration can remain a trusted route into data long after the business use case ends.
Technical breakdown
Why bearer credentials bypass MFA in SaaS
Bearer credentials authenticate by possession, not by repeated user challenge. OAuth access tokens, refresh tokens, session cookies, and API keys all let a caller prove access without revisiting MFA once the credential exists. That is why the login layer and the application layer can drift apart: the user completed authentication once, but the credential now operates independently of the original identity event. In SaaS, this is normal architecture, not a bug. The security implication is that MFA protects the interactive sign-in moment, while the token becomes the true access mechanism for later API activity.
Practical implication: govern issued tokens as access credentials, not as harmless by-products of sign-in.
How SaaS-to-SaaS trust expands the attack surface
Modern SaaS integrations create delegated trust chains between applications, vendors, and service accounts. When an integration is authorised, the downstream token can inherit scopes broad enough to touch sensitive data across connected platforms. If that token is stolen or replayed, the attacker does not need to defeat the primary SaaS login flow. They simply ride the pre-established trust path. This is why the hidden layer of NHI risk is often broader than the original application boundary: access moves through backend connections that user-facing controls were never designed to observe.
Practical implication: map every third-party integration and inherited scope before treating the environment as MFA-covered.
Why static inventories miss active token abuse
Inventory tools show what credentials exist and what scopes they hold, but they do not prove who is using them or how. A stolen token can generate legitimate-looking API calls while appearing normal in a static access review. That creates a detection gap between posture and behaviour. In practice, the issue is not whether a credential exists, but whether its use matches the identity, location, velocity, and endpoint patterns that should be associated with it. Without behavioural monitoring, compromised tokens can remain invisible even when the surrounding authentication estate looks healthy.
Practical implication: pair credential inventory with behavioural analytics that can flag misuse of valid SaaS tokens.
Threat narrative
Attacker objective: The attacker wants persistent access to downstream SaaS data and workflows without ever triggering MFA or other login-layer controls.
- Entry occurs when attackers obtain a valid OAuth token, session cookie, or API key from a SaaS integration or user session.
- Credential access is unnecessary because the bearer credential already authenticates directly to the SaaS or API endpoint.
- Escalation happens when the compromised credential inherits trusted scopes that reach additional applications, data sets, or tenants.
- Impact follows when the attacker maintains authorised-looking access long enough to exfiltrate data or move laterally through SaaS connections.
Breaches seen in the wild
- Fake Dependabot commits 2023: Stolen GitHub tokens were used to push fake Dependabot commits to hundreds of repos, adding workflows that stole Actions secrets.
- CoPhish OAuth phishing via Copilot Studio: Datadog showed Copilot Studio agents on a Microsoft domain can front OAuth consent phishing and forward stolen tokens; no victims reported.
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
MFA bypass is really a post-authentication governance problem: once a bearer credential exists, the trust boundary shifts away from the login event and into the token lifecycle. That makes login-centric assurance insufficient for SaaS estates built on OAuth, session cookies, and API keys. Practitioners need to treat issued credentials as the real access plane, because that is where abuse now happens.
Hidden-layer NHI risk is the right name for this control blind spot: the article shows that service access often survives the authentication moment that created it. Traditional MFA assumes the access decision is tied to a human challenge, but SaaS integrations and refreshable tokens can outlive that assumption. The implication is that access governance must follow the credential, not the user session alone.
Token persistence is a governance failure, not just a detection gap: refresh tokens can mint new access after password resets and MFA changes, which means the compromise window can persist unless the credential itself is revoked. That is a lifecycle problem for non-human identity, not a login problem. The practitioner conclusion is that revocation, ownership, and scope control matter more than the original authentication event.
Behavior must replace static inventory as the deciding signal: static access lists show entitlement, but they do not reveal hostile reuse of valid credentials. That makes the trust model brittle when attacker activity is indistinguishable from authorised API traffic. The broader lesson is that SaaS security now depends on behavioural proof of legitimacy, not just the presence of a valid token.
From our research library:
- Systems with least-privileged AI access had a 17% incident rate vs 76% for over-privileged systems. Organisations failing to scope AI access properly are 4.5x more likely to experience a security incident, according to the 2026 Infrastructure Identity Survey.
- 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
- Read next: AI Agent Observability, Audit and Incident Response Guide
What this signals
Hidden-layer credential governance: MFA will keep looking effective if teams only measure login success, but SaaS compromise increasingly happens after authentication through valid bearer credentials. Security programmes need to move their control point from the front door to the credential itself, especially where integrations and service access blur human and non-human ownership.
The operational test is whether your environment can explain every token's purpose, scope, owner, and revocation path. If it cannot, static access reviews will continue to miss compromised credentials that appear normal until the data starts moving.
For practitioners
- Inventory all bearer credentials across SaaS integrations Build a complete register of OAuth tokens, refresh tokens, session cookies, API keys, and service accounts that can access SaaS applications outside the primary login flow.
- Revoke long-lived tokens on ownership change Tie token revocation to offboarding, vendor change, application replacement, and suspected compromise so credentials do not survive the relationship that created them.
- Add behavioural detection for valid-token abuse Monitor API calls, source geography, velocity, and endpoint sequences so legitimate credentials that are being reused by attackers stand out from normal traffic.
- Scope third-party SaaS access to minimum effective permissions Review delegated scopes for integrations and reduce write access, tenant-wide reach, and cross-application trust where the integration does not need them.
Key takeaways
- The article shows that MFA is only one layer of SaaS protection, and valid tokens can continue to authorise access after the user challenge is complete.
- Its core evidence is the gap between authentication controls and post-authentication credential use, where static inventories and login logs fail to reveal abuse.
- The practical response is to govern token lifecycle, delegated scope, and behavioural detection as the real control plane for SaaS access.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 — Secret Leakage | Stolen tokens and cookies are the central abuse path in this SaaS MFA bypass analysis. |
| NHI-04 — Insecure Authentication | The article shows authentication is bypassed when tokens operate outside the MFA flow. | |
| NHI-07 — Long-Lived Secrets | Refresh tokens and persistent API credentials extend exposure long after initial issuance. | |
| Recommendation — Scan SaaS integrations for exposed tokens and revoke any bearer credential that may have leaked. Treat post-authentication bearer tokens as authentication assets and restrict their reach. Shorten credential lifetimes and revoke long-lived SaaS secrets on compromise or ownership change. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Token lifecycle management is central to limiting bearer-credential abuse. |
| Recommendation — Apply IA-5 to govern issuance, rotation, and revocation of SaaS credentials. | ||
| MITRE ATT&CK | TA0006;TA0010 — Credential Access; Exfiltration | The article centres on stolen credentials used for access and downstream data theft. |
| Recommendation — Map token abuse to credential access and exfiltration detections in your monitoring pipeline. | ||
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 reach: The set of systems, ports, and protocols an identity can use after it has successfully authenticated. In practice, this is where many identity attacks escalate, because the risk sits in what the identity can touch, not only in how it logged in.
- Delegated trust: Delegated trust is the decision to let another system or organization issue, validate, or transmit access on your behalf. It is common in cloud and SaaS environments, but it becomes risky when scope, duration, and revocation are not tightly controlled. In NHI governance, delegated trust must be explicit and continuously reviewable.
- Behavioral Detection: A monitoring approach that looks for unusual activity rather than relying only on static inventories. For SaaS integrations, it detects drift in token use, data movement, timing, and endpoint behavior so teams can spot compromise, misuse, or automation that no longer matches its expected pattern.
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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on August 15, 2026.
Updated on October 12, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org