When investigating a security incident, most IR teams ask the same questions: Was MFA enabled? Were credentials compromised? Did we see failed login attempts? But what happens when attackers never touch your login page at all?
The uncomfortable truth is that MFA bypass techniques have evolved far beyond credential theft. Attackers no longer need to crack your multi-factor authentication when they can simply walk around it using valid OAuth tokens, stolen session cookies, or persistent API credentials. These techniques exploit the hidden layer between your SaaS applications, where authentication controls don't apply and traditional security tools have no visibility.
The Salesloft-Drift breach demonstrated this reality with painful clarity. Attackers used valid OAuth tokens to access more than 700 companies without triggering MFA a single time. No brute force attacks. No credential stuffing. Just legitimate tokens riding trusted connections straight into customer environments.
Key Takeaways
MFA protects authentication moments, not post-authentication access. OAuth tokens and API credentials bypass MFA entirely once issued.
Token persistence creates long-term exposure. Refresh tokens maintain access even after password resets and MFA changes.
Traditional security tools monitor the wrong layer. SIEMs track login failures while attackers abuse valid tokens through API calls.
Real breaches prove the risk. Salesloft-Drift (700+ organizations) and CircleCI incidents show how token theft bypasses all authentication controls.
Prevention requires behavioral detection. Static inventories can't identify compromised credentials being used legitimately.
What is MFA Bypass?
MFA bypass refers to techniques that allow attackers to gain unauthorized access to systems and data without completing multi-factor authentication challenges. The critical distinction: attackers don't "crack" MFA through technical exploits. They route around it entirely by exploiting authentication mechanisms that function independently of your MFA infrastructure.
Most organizations operate under a dangerous misconception: "We are secure because we have SSO and MFA." This belief assumes that strong authentication controls at the login layer protect all access to SaaS applications and their data.
The operational reality tells a different story. OAuth tokens, API keys, service accounts, and session cookies all grant access to SaaS applications and their APIs without requiring users to authenticate through your SSO provider or complete MFA challenges. These non-human identities and bearer tokens operate in the hidden layer between your applications, completely outside your authentication perimeter.
When an OAuth refresh token is issued to a third-party integration, that token can mint new access tokens. For an external party to login, they don’t need to complete an MFA challenge. It simply presents the token, and your SaaS application grants access. This is not a vulnerability; it's how modern SaaS architectures function by design.
The same principle applies to stolen session tokens. Once a user completes MFA and establishes an authenticated session, the session cookie becomes a bearer token. Whoever possesses that cookie inherits the authenticated session without needing credentials or MFA codes. The application cannot distinguish between the legitimate user and an attacker replaying the stolen session.
This fundamental architecture creates persistent exposure that traditional authentication controls cannot address. Understanding these mechanisms is essential for incident responders investigating how attackers maintained access despite "strong authentication" being in place.
How Attackers Bypass MFA in SaaS Environments
Token Theft & Replay Attacks
OAuth refresh tokens represent one of the most effective MFA bypass techniques because they grant persistent, renewable access without ever triggering authentication controls. Unlike passwords that require MFA verification during login, refresh tokens function as bearer credentials. Whoever possesses the token can use it to request new access tokens from the SaaS application's authorization server.
Most SaaS applications implement OAuth tokens as bearer tokens, something like a key. Whoever has this key can use it. There is no additional verification of identity, no device binding, no MFA challenge. The token itself is the authentication mechanism.
The Salesloft-Drift breach in 2025 demonstrated this attack vector with devastating impact. Attackers compromised OAuth tokens that Salesloft's integration used to access customer Drift accounts. Because these were valid, legitimately issued tokens, they bypassed all authentication controls. The attackers used these tokens to access more than 700 companies' data across multiple SaaS applications including Gainsight and Salesforce instances. MFA never triggered because the authentication moment had already occurred when the integration was originally authorized.
This incident revealed how SaaS-to-SaaS lateral movement works in practice. A single compromised OAuth token at one vendor can extend access across an entire network of integrated applications. Each integration represents a trusted connection that attackers can ride straight into customer environments, one integration away from your most sensitive data.
Token replay attacks exploit this same principle. An attacker who steals an access token or refresh token can replay it against the SaaS application's API endpoints. The application validates the token signature and scope, confirms it hasn't expired, and grants access. From the application's perspective, this is legitimate API activity using valid credentials.
For incident responders, this creates a detection challenge. Traditional security tools monitor for failed authentication attempts, suspicious login patterns, and credential compromise indicators. But token replay attacks generate none of these signals. The authentication already succeeded when the token was originally issued. What you're seeing is authorized API access using valid credentials; the very definition of normal behavior from a static inventory perspective.
Session Hijacking
Session hijacking represents another powerful MFA bypass technique that exploits the post-authentication phase. Once a user successfully completes MFA and establishes an authenticated session, the SaaS application issues a session cookie that maintains that authenticated state. This cookie functions as proof of completed authentication, allowing the user to interact with the application without re-authenticating for every request.
Attackers who steal these session cookies inherit the fully authenticated session. The SaaS application cannot distinguish between the legitimate user presenting the cookie and an attacker replaying it. The MFA challenge was already completed during the initial authentication. The session cookie is now the bearer credential that grants access.
Adversary-in-the-middle (AiTM) phishing kits have industrialized this attack technique. These sophisticated phishing frameworks proxy the real authentication flow, capturing credentials and session tokens in real-time as users complete legitimate MFA challenges. The user authenticates against the real SaaS application through the attacker's proxy, completes their MFA verification, and receives their session cookie. The AiTM kit captures that session cookie and immediately replays it, gaining authenticated access while the user believes they simply logged in normally. A similar occurrence happened in July 2022, Microsoft detected multiple iterations of an AiTM phishing campaign using the Evilginx2 phishing kit that attempted to target more than 10,000 organizations since September 2021.
This attack bypasses MFA completely because the attacker never needs to solve the MFA challenge themselves. They simply wait for the legitimate user to solve it, then steal the resulting authenticated session. From the SaaS application's perspective, both the user's subsequent activity and the attacker's malicious actions appear as legitimate requests from an authenticated session.
Understanding AI phishing detection capabilities becomes critical as AiTM kits grow more sophisticated in mimicking legitimate authentication flows.
Session token theft can occur through multiple vectors beyond phishing. Malware on user devices can extract session cookies from browser storage. Network-level attacks on unencrypted connections can intercept cookies in transit. Compromised browser extensions can exfiltrate authentication tokens. Cross-site scripting vulnerabilities can expose session cookies to attacker-controlled scripts.
For SecOps teams, detecting session hijacking requires behavioral analysis rather than authentication monitoring. The authentication event was legitimate. The session establishment was valid. What indicates compromise is anomalous behavior within that authenticated session: unusual IP addresses, unexpected geographic locations, abnormal access patterns, or data exfiltration activities that deviate from the user's typical behavior.
Consent Phishing (OAuth Phishing)
Consent phishing, also called OAuth phishing, exploits the OAuth authorization flow itself to achieve MFA bypass without stealing credentials at all. Instead of compromising passwords or intercepting session tokens, attackers trick users into authorizing malicious OAuth applications that request access to their SaaS data.
The attack flow is deceptively simple. An attacker creates a malicious OAuth application and registers it with a SaaS platform's app marketplace or developer portal. The application requests broad OAuth scopes: permissions to read emails, access files, modify data, or perform administrative actions. The attacker then distributes authorization links through phishing emails, often disguised as legitimate service requests or productivity tools.
When a user clicks the authorization link, they are redirected to the real SaaS provider's OAuth consent screen. This is not a phishing page; it's the legitimate authorization interface. The user completes MFA if required by their organization's policies, reviews the requested permissions (often too quickly), and clicks "Allow." The SaaS platform then issues an OAuth token to the attacker's application, granting it the authorized access.
From this point forward, the attacker has persistent API access to the user's data without ever needing credentials or MFA codes. The OAuth token functions independently of the user's password. Even if the user changes their password or updates their MFA settings, the previously issued OAuth token remains valid until explicitly revoked.
This technique bypasses MFA by exploiting user trust and the legitimate OAuth authorization process. The user completed MFA during the authorization flow, validating their identity. But they authorized access for a malicious application controlled by the attacker. The SaaS platform correctly issued a token based on valid user consent; the problem is that the consent was obtained through deception.
OAuth phishing attacks are particularly dangerous because they leave minimal forensic evidence. There are no failed login attempts, no credential compromise indicators, no malware signatures. What appears in logs is a legitimate OAuth authorization followed by normal API activity using valid tokens. Traditional security tools monitoring authentication events see nothing suspicious.
For incident response teams, identifying consent phishing requires visibility into OAuth authorizations across your SaaS applications. Which third-party apps have users authorized? What scopes do those applications hold? Are there recently authorized apps with suspicious permission requests? Are there OAuth applications making unusual API calls or accessing sensitive data inconsistent with their stated purpose?
Service Account & API Key Exploitation
Service accounts and API keys represent a category of non-human identities that never had MFA protection in the first place. These machine identities enable automation, integrations, and backend processes that need to interact with SaaS applications programmatically. By design, they authenticate using static credentials: API keys, client secrets, service account tokens, rather than interactive login flows that could support MFA challenges.
This architectural reality creates persistent exposure. Service accounts often operate with elevated privileges, requiring broad access to perform their automated functions. They run 24/7, making API calls continuously without human oversight. And they authenticate using credentials that, if compromised, grant immediate access without any MFA barrier.
The CircleCI breach in January 2023 demonstrated the catastrophic impact of API key exploitation. Attackers compromised CircleCI's secret management system and exfiltrated customer API keys, tokens, and credentials stored in environment variables. These stolen credentials included service account tokens for customers' SaaS applications, cloud infrastructure, and development tools.
Because these were valid API credentials for service accounts, they bypassed all authentication controls. No MFA challenges. No login attempts. Just direct API access using legitimate credentials. Customers whose secrets were stolen faced a nightmare scenario: attackers had persistent access to their production systems using credentials that appeared completely legitimate in all security logs.
Service account security becomes critical for preventing this attack vector. Unlike user accounts where you can enforce MFA at authentication, service accounts require different controls: credential rotation policies, least privilege access, behavioral monitoring, and immediate revocation when suspicious activity is detected.
The challenge for SecOps teams is that service accounts generate enormous volumes of API activity, making behavioral anomalies harder to detect. A compromised service account making unusual API calls might be difficult to distinguish from legitimate automation that changed its behavior due to code updates or configuration changes.
API key management requires visibility into which service accounts exist, what access they hold, when they were last rotated, and whether they're still actively used. According to Obsidian's network data, organizations discover an average of 40% more service accounts than they believed existed when they first gain comprehensive visibility into their SaaS environments. Many of these are stale credentials with admin permissions
Understanding the scope of non-human identity security challenges helps organizations address this expanding attack surface.
Why MFA Doesn't Protect Your SaaS Integrations
Consider the common responses during common security events and how that’s still ineffective:
User password reset: The OAuth tokens previously issued to integrations that user authorized remain valid. The integration continues accessing data using its token, completely unaffected by the password change.
MFA settings updated: Existing OAuth tokens continue functioning. They were issued based on a previous authorization and don't require re-authentication when MFA policies change.
Employee termination: Unless your offboarding process explicitly includes OAuth token revocation, integrations authorized by departed employees continue accessing your SaaS data indefinitely.
This independence creates a critical gap in incident response. When investigating a potential compromise, most IR teams focus on credential resets and MFA verification. They ensure the user's password is changed, confirm MFA is enabled, and verify no unauthorized devices are registered. But if the attacker stole an OAuth token or compromised a service account, none of these remediation steps revoke their access.
The Salesloft-Drift breach exemplified this gap. Organizations that discovered they were affected couldn't simply reset user passwords to remediate the exposure. The attackers were using OAuth tokens issued to Salesloft's integration. Remediation required identifying and revoking those specific integration tokens across hundreds of affected SaaS applications, a process that required visibility most organizations didn't have.
Refresh tokens compound this persistence problem. While access tokens typically expire within hours, refresh tokens can remain valid for months or indefinitely. An attacker who steals a refresh token can continue minting new access tokens long after the initial compromise.
For security teams, this reality demands a fundamental shift in how you think about authentication controls. MFA remains essential for protecting the authentication moment, but it provides zero protection for the post-authentication access layer where OAuth tokens, API keys, and service accounts operate. That hidden layer requires different visibility, different monitoring, and different response procedures.
The Token Persistence Problem
Understanding the distinction between access tokens and refresh tokens is critical for incident responders investigating MFA bypass attacks. These two token types have fundamentally different lifecycles and security implications.
Access tokens are short-lived credentials, typically expiring within 1-24 hours depending on the SaaS provider's configuration. These tokens grant direct API access but have limited validity periods. When an access token expires, the client must obtain a new one to continue accessing the API.
Refresh tokens are long-lived credentials designed to obtain new access tokens without requiring user re-authentication. A refresh token might remain valid for 90 days, 180 days, or indefinitely until explicitly revoked. When an access token expires, the client presents the refresh token to the authorization server and receives a fresh access token; no user interaction required, no MFA challenge, no authentication event logged.
This design creates the token persistence problem: an attacker who steals a refresh token can maintain access far longer than the access token's expiration period would suggest. Even if your incident response procedures include revoking active access tokens, the attacker can use the refresh token to immediately mint new access tokens and continue their attack.
Consider a realistic breach timeline:
Day 1: Attacker compromises an OAuth refresh token through a consent phishing attack. They begin exfiltrating data using the associated access token.
Day 3: Your security team detects anomalous API activity and begins investigation.
Day 5: Investigation confirms compromise. The IR team resets the user's password and revokes the current access token.
Day 5 (30 minutes later): Attacker uses the refresh token to obtain a new access token. Data exfiltration resumes. Your security tools see a new, valid access token being used, potentially appearing as normal integration activity if you lack behavioral context.
Day 7: Security team discovers data exfiltration has continued. Additional investigation reveals the refresh token was never revoked.
Day 10: Refresh token finally identified and revoked. Persistent access eliminated.
This scenario plays out regularly in real incidents. Password resets and MFA changes don't invalidate existing tokens in most SaaS applications. Organizations need explicit token revocation procedures that address both access tokens and refresh tokens.
The persistence problem extends beyond individual user tokens. Service accounts and integration tokens often have even longer lifecycles. Some service account credentials never expire unless explicitly rotated. API keys issued years ago might still grant admin-level access to critical SaaS applications, completely forgotten by the teams who originally created them.
The average enterprise has 40% more active OAuth tokens than they can account for in their integration inventories. These are the blind spots in integrations where attackers operate. Stale tokens with admin permissions, forgotten service accounts with write access, third-party integrations authorized by employees who left years ago, all representing persistent access that bypasses every authentication control you've implemented.
Refresh token security requires different controls than password security:
Expiration policies: Configure refresh tokens to expire after reasonable periods (30-90 days) rather than persisting indefinitely.
Rotation on use: Some OAuth implementations issue a new refresh token each time one is used, invalidating the previous token. This limits the window for stolen refresh tokens to be abused.
Revocation on suspicious activity: When behavioral analytics detect anomalous token usage, automated revocation should target both access and refresh tokens.
Lifecycle tracking: Maintain inventories of which refresh tokens exist, what access they grant, when they were issued, and when they last generated new access tokens.
For incident responders, the critical question becomes: when you respond to a breach, do you revoke tokens or just reset passwords? Most IR playbooks focus heavily on credential resets while giving minimal attention to token revocation. This gap allows attackers to maintain persistent access through the hidden layer of OAuth tokens and API credentials that function independently of user authentication.
Exploring OAuth security best practices provides deeper technical guidance for securing token lifecycles.
Why Traditional Security Tools Miss MFA Bypass Attacks
The detection gap for MFA bypass attacks stems from a fundamental mismatch between what traditional security tools monitor and where these attacks actually occur. Most security infrastructure focuses on the authentication layer, while token-based attacks operate in the post-authentication API layer.
SIEM platforms excel at collecting and correlating authentication logs. They alert on failed login attempts, impossible travel scenarios, unusual authentication patterns, and credential stuffing attacks. But when an attacker uses a valid OAuth token to access your SaaS applications' APIs, there are no failed logins to detect. The authentication already succeeded when the token was originally issued. What appears in logs is legitimate API activity using valid credentials.
SIEM correlation rules look for anomalies in authentication events: multiple failed attempts followed by success, logins from blacklisted IP addresses, authentication from impossible geographic combinations. Token replay attacks generate none of these signals. The API calls use valid bearer tokens, come from the integration's expected infrastructure, and perform actions within the token's authorized scopes.
Identity and Access Management (IAM) tools monitor authentication events and enforce policies at the login layer. They verify MFA completion, check device compliance, evaluate risk scores, and grant or deny authentication based on policy. But OAuth tokens bypass this entire control plane. Once issued, tokens authenticate API requests directly with the SaaS application without consulting your IAM infrastructure.
When an attacker uses a stolen OAuth token, your IAM tools see nothing. There's no authentication request to evaluate, no MFA challenge to verify, no device to check for compliance. The token itself is the authentication mechanism, and it's presented directly to the SaaS application's API.
Cloud Access Security Brokers (CASBs) provide visibility into user activity within SaaS applications by proxying or API-connecting to monitor data access and enforce policies. But most CASBs focus on user-driven activity: files accessed through the web interface, emails sent by users, documents shared through collaboration tools.
SaaS-to-SaaS lateral movement through backend integrations often bypasses CASB visibility entirely. When a compromised OAuth token at a third-party vendor accesses your Salesforce data through API calls, that traffic doesn't flow through your CASB proxy. It's backend communication between two SaaS platforms, invisible to tools that monitor user-facing activity.
SaaS Security Posture Management (SSPM) tools provide valuable configuration auditing and compliance checking. They identify misconfigurations, overprivileged users, and policy violations. But SSPM tools typically provide static point-in-time data; snapshots of your current configuration and user permissions.
What SSPM tools miss is behavioral context. They can tell you that a service account has admin permissions. They can identify that an OAuth integration has write access to sensitive data. But they cannot tell you whether those credentials are currently being abused by an attacker. They show inventory, not behavior.
The fundamental limitation across all these traditional tools is that they monitor authentication events and configuration state, not the behavioral patterns of credential usage. When attackers abuse valid credentials, whether OAuth tokens, API keys, or service accounts, they operate in the gap between authentication monitoring and behavioral detection.
Behavior vs inventory represents the critical distinction. Static inventories show what tokens exist and what permissions they hold. Behavioral detection shows how those tokens are actually being used: which APIs they're calling, what data they're accessing, from which IP addresses, with what velocity, following which patterns.
A comprehensive approach to detecting token abuse requires:
API activity monitoring: Visibility into actual API calls made using OAuth tokens and service accounts, not just authentication events.
Behavioral baselining: Understanding normal patterns for each token: typical API endpoints accessed, data volumes transferred, access times, source IPs.
Anomaly detection: Identifying deviations from established baselines; unusual data exports, access from unexpected ASNs, velocity spikes, new API endpoints being called.
Relationship mapping: Correlating token activity back to identity context through a Knowledge Graph that understands which users authorized which integrations, what access those integrations inherited, and how they connect across your SaaS environment.
Toxic combination identification: Finding high-risk scenarios where stale tokens have admin permissions, inactive integrations retain write access, or forgotten service accounts hold elevated privileges.
Without these behavioral detection capabilities, organizations remain blind to the hidden layer where MFA bypass attacks actually occur. Your authentication controls are strong, your MFA implementation is solid, your IAM policies are well-designed, but attackers are operating in a different layer entirely, using valid credentials that bypass all those controls.
MFA Bypass Prevention: Beyond Traditional Controls
Implement Token Lifecycle Management
Preventing MFA bypass attacks requires treating tokens as first-class credentials with explicit lifecycle management policies. Most organizations have mature password policies: complexity requirements, expiration periods, rotation schedules, but lack equivalent governance for OAuth tokens and API keys.
Set expiration policies on refresh tokens. Configure your SaaS applications to issue refresh tokens with defined expiration periods rather than indefinite validity. A 90-day expiration policy forces periodic re-authorization, limiting the window for stolen tokens to be abused. While this creates some operational friction for legitimate integrations, it dramatically reduces persistent access risk.
Revoke tokens when employees leave or change roles. Your offboarding procedures should explicitly include OAuth token revocation. When an employee departs, identify all integrations they authorized, all service accounts they created, and all API keys they generated. Revoke these credentials as part of standard offboarding, not as an afterthought discovered during the next security audit.
Role changes require similar attention. When an employee moves from a privileged role to a standard user role, their previously authorized OAuth tokens may retain the elevated permissions from their former role. These tokens should be reviewed and either revoked or re-authorized with appropriate scopes for the new role.
Audit stale tokens with elevated permissions. Regularly identify OAuth tokens and service accounts that haven't been used recently but retain admin-level access. These toxic combinations(stale plus overprivileged) represent high-value targets for attackers. A service account created three years ago for a one-time data migration that still has admin write access to your production Salesforce environment is a breach waiting to happen.
Implementing effective token lifecycle management requires visibility you may not currently have. Can you answer these questions about your SaaS environment:
● Which OAuth tokens are currently active across all your SaaS applications?
● What permissions does each token hold?
● When was each token last used to make an API call?
● Which tokens were authorized by employees who no longer work for your organization?
● Which service accounts have admin permissions but haven't been used in 90+ days?
Without comprehensive visibility into your integration inventory, token lifecycle management remains theoretical. You need continuous discovery of OAuth authorizations, service accounts, and API keys across your SaaS environment, not point-in-time snapshots that become outdated the moment they're generated.
Monitor for Token Abuse, Not Just Authentication Failures
Traditional security monitoring focuses on detecting authentication failures, the signals that indicate someone is trying to break in. But MFA bypass attacks use valid credentials. They don't fail authentication; they bypass it entirely. Detection requires monitoring for anomalies in how valid credentials are being used.
Behavioral analytics provide the foundation for detecting token abuse. Establish baseline patterns for each OAuth token and service account: which API endpoints they typically access, what data volumes they normally transfer, which IP addresses they originate from, what time of day they're active, what velocity of API calls they generate.
When actual usage deviates from these baselines, behavioral analytics generate alerts:
Unusual data exports: A token that normally reads small amounts of data suddenly exports gigabytes. This could indicate data exfiltration by an attacker who compromised the token.
IP and ASN deviations: A service account that always makes API calls from your cloud infrastructure's IP range suddenly appears from a residential IP address in a different country. This suggests credential theft and replay from an attacker's infrastructure.
Access pattern changes: An OAuth integration that typically calls read-only endpoints suddenly starts making write and delete API calls. This could indicate scope expansion after compromise or misuse of overprivileged tokens.
Velocity anomalies: API call rates that spike dramatically beyond normal patterns, potentially indicating automated data harvesting by attackers.
User-Agent attribution adds another detection dimension. Most legitimate integrations use consistent User-Agent strings that identify the integration platform and version. When the same OAuth token suddenly appears with different User-Agent strings, it may indicate the token has been exfiltrated and is being replayed from different tools or scripts.
ASN (Autonomous System Number) analysis helps identify when credentials are being used from unexpected network infrastructure. A token issued to a cloud-based integration should originate from that cloud provider's ASN. If it suddenly appears from a residential ISP's ASN or a VPN provider's network, that's a strong indicator of compromise.
For incident responders, behavioral detection answers the critical question: is this valid credential being used legitimately, or is it compromised and being abused? Static analysis cannot answer this question. A stolen OAuth token looks identical to a legitimate one in your integration inventory. Only behavioral context reveals the difference.
Reduce OAuth Scope Creep
Overprivileged permissions represent one of the most common security gaps in SaaS environments. Integrations request broad OAuth scopes during initial authorization, often far exceeding what they actually need to perform their intended function. Users approve these requests without careful review, and the overprivileged access persists indefinitely.
Audit integrations for overprivileged access. Review the OAuth scopes granted to each third-party integration. Compare the authorized permissions against the integration's actual usage patterns. An analytics tool that only needs read access to generate reports shouldn't have write and delete permissions. A notification integration that only sends alerts shouldn't have admin access to modify configurations.
Enforce least privilege for third-party app authorizations. Implement approval workflows that require security review before users can authorize OAuth applications requesting sensitive scopes. Admin-level permissions, write access to production data, or broad API access should trigger mandatory review rather than allowing individual users to grant these permissions unilaterally.
Identify integrations with admin access that only need read permissions. These represent opportunities to reduce scope without impacting functionality. Re-authorize these integrations with read-only scopes, eliminating the risk that a compromised token could be used for destructive actions.
OAuth scope governance requires ongoing attention, not one-time cleanup. New integrations are authorized continuously as users adopt new productivity tools and business applications. Without automated discovery and continuous monitoring, your carefully curated least-privilege model degrades within months as scope creep accumulates.
Continuous Integration Visibility
The foundation for all these prevention measures is comprehensive visibility into your SaaS integration landscape. You cannot manage what you cannot see. Most organizations discover they have 40-60% more OAuth authorizations than they believed existed when they first implement continuous integration monitoring.
Discover all OAuth authorizations across SaaS apps. Traditional discovery methods (asking teams to document their integrations, reviewing app marketplace installation lists, checking admin consoles) capture only a fraction of the actual integration landscape. Users authorize OAuth applications directly without IT involvement. Shadow integrations proliferate as teams solve business problems with SaaS tools that never go through formal procurement.
Comprehensive discovery requires API-level visibility into each SaaS application's OAuth authorization database. Which third-party applications have users authorized? What scopes do those applications hold? When were they authorized? By whom? Are they actively making API calls or sitting dormant with persistent access?
Map which tokens have access to which data. Understanding the blast radius of a compromised token requires knowing not just what permissions it holds, but what data those permissions grant access to. An OAuth token with "read contacts" scope in Salesforce might access millions of customer records. Another token with the same scope in a different Salesforce org might only access a few hundred internal contacts. The scope is identical; the data exposure is vastly different.
Detect shadow integrations created without security review. When a vendor breach notification arrives announcing that a third-party service was compromised, can you immediately answer whether any of your users authorized that service? How many tokens does it hold? What access do those tokens grant? Which SaaS applications are affected?
Without continuous visibility, this question triggers a manual investigation: searching through admin logs, querying each SaaS application's OAuth settings, asking users if they've authorized the compromised service. By the time you complete this investigation, attackers have had days or weeks to abuse any stolen tokens.
Knowledge Graph technology provides the relationship mapping required to answer these questions instantly. By correlating OAuth authorizations, user identities, SaaS applications, data access patterns, and integration relationships, a Knowledge Graph reveals the hidden connections that create SaaS supply chain risk.
When a vendor breach occurs, you can immediately identify: which users authorized integrations from that vendor, which tokens those integrations hold, what SaaS applications they access, what data they can reach, and what the blast radius would be if those tokens were compromised. This transforms vendor breach response from a multi-day investigation into an immediate, data-driven assessment.
Understanding how AI agents introduce new OAuth authorization patterns helps organizations extend visibility to emerging integration categories.
How Obsidian Security Detects MFA Bypass Attacks
Obsidian Security's approach to detecting MFA bypass attacks focuses on the hidden layer where these attacks actually occur: the behavioral patterns of OAuth token usage, service account activity, and API-level access that bypasses traditional authentication controls.
Behavioral monitoring of OAuth token activity provides the foundation. Rather than monitoring authentication events that tokens bypass entirely, Obsidian tracks actual API calls made using each token. This visibility reveals how credentials are being used in practice, not just what permissions they theoretically hold.
When an OAuth token's behavior deviates from its established baseline, Obsidian generates alerts. A token that normally makes 50 API calls per day suddenly making 5,000 calls triggers investigation. A service account that typically accesses data during business hours appearing at 3 AM from an unexpected IP address indicates potential compromise. An integration that always reads data suddenly executing delete operations suggests either scope abuse or attacker activity.
The Knowledge Graph correlates token usage back to identity context, answering critical questions that static inventories cannot address:
● Who authorized this OAuth application?
● What relationship does this service account have to other identities in the environment?
● Which SaaS applications can this token access through integration chains?
● What data inheritance occurs when this token accesses connected applications?
● Has this token's behavior changed since a recent security event?
This correlation transforms isolated behavioral anomalies into contextualized security insights. An unusual API call pattern becomes actionable when you understand which employee authorized the integration, what data it can access, and how it connects to other SaaS applications in your environment.
Detecting anomalies requires multiple analytical dimensions working together:
IP and ASN attribution: Obsidian tracks the network infrastructure from which each token makes API calls. When a token that always originates from AWS infrastructure suddenly appears from a residential ISP, that deviation indicates potential credential theft and replay.
Unexpected API calls: Monitoring which specific API endpoints each token accesses reveals when compromised credentials are being used for actions outside their normal pattern. A token that only called read endpoints suddenly accessing bulk export APIs suggests data exfiltration.
Velocity changes: Sudden spikes in API call frequency or data transfer volumes indicate automated abuse that differs from legitimate integration behavior.
User-Agent analysis: Changes in the User-Agent strings associated with a token's API calls can reveal when credentials have been exfiltrated and are being replayed from different tools or environments.
Identifying toxic combinations addresses a critical risk category that static tools miss entirely. A service account with admin permissions isn't necessarily high-risk if it's actively used by a legitimate automation process. But a service account with admin permissions that hasn't made an API call in 180 days represents a toxic combination of stale plus overprivileged, a high-value target that provides persistent access if compromised.
Obsidian automatically identifies these risk combinations:
● Stale integrations with write or delete permissions
● Inactive service accounts retaining admin access
● OAuth tokens authorized by departed employees
● Third-party applications with overprivileged scopes that only use read APIs
Breach impact analysis becomes critical when vendor breach notifications arrive. When Salesloft disclosed their breach, affected organizations needed to immediately understand: do we use Salesloft? Which of our SaaS applications did Salesloft integrations access? What data exposure occurred? How many accounts are affected?
Obsidian's Knowledge Graph answers these questions instantly by mapping the integration relationships across your SaaS environment. When a third-party vendor is compromised, you can immediately identify which OAuth tokens that vendor holds, what SaaS applications those tokens access, what data they can reach, and what the complete blast radius looks like across your environment.
This visibility transforms vendor breach notification response from a manual investigation into an immediate, data-driven risk assessment. Instead of spending days trying to determine whether you're affected, you know within minutes and can begin targeted remediation.
For SecOps teams investigating potential account takeover or lateral movement scenarios, Obsidian provides the behavioral context that traditional tools lack. You can see exactly how an attacker moved through your SaaS environment using compromised tokens, which data they accessed, what API calls they made, and how they leveraged trusted connections to extend their access across integrated applications.
The platform facilitates response by identifying which specific tokens need revocation, which integrations should be re-authorized with reduced scopes, and which service accounts require immediate credential rotation. This targeted remediation is far more effective than broad password resets that leave the actual attack vector (compromised tokens) completely untouched.
Exploring SaaS supply chain security in the context of real breaches like CircleCI demonstrates how behavioral detection catches what traditional controls miss.
Conclusion
Multi-factor authentication remains an essential security control, but it is not sufficient for protecting modern SaaS environments. The uncomfortable truth is that MFA bypass techniques have evolved to exploit the fundamental architecture of SaaS integrations, where OAuth tokens, API keys, and service accounts grant persistent access that bypasses authentication controls entirely.
The real exposure in your SaaS environment is not the front door that MFA protects. It's the side doors; the OAuth tokens riding trusted connections between applications, the service accounts operating 24/7 with elevated privileges, the API credentials that authenticate without ever triggering your SSO or MFA infrastructure. This is the hidden layer between your SaaS applications where attackers operate, one integration away from your most sensitive data.
Prevention requires moving beyond authentication monitoring to behavioral detection. Static inventories show what tokens exist; behavioral analytics reveal which tokens are compromised. Traditional security tools monitor login failures; effective SaaS security monitors how valid credentials are actually being used.
For IR and SecOps teams, this demands new visibility, new detection capabilities, and new response procedures:
Visibility into OAuth authorizations, service accounts, and API keys across all SaaS applications, not just the ones IT formally manages.
Behavioral monitoring of token usage patterns to detect when valid credentials are being abused by attackers.
Token lifecycle management that treats OAuth tokens and API keys as first-class credentials requiring explicit governance.
Incident response procedures that include token revocation, not just password resets, when investigating potential compromises.
The Salesloft-Drift and CircleCI breaches proved that the risk is not theoretical. Attackers are actively exploiting the gap between authentication controls and post-authentication access. Organizations that rely solely on SSO and MFA while ignoring the hidden layer of tokens and integrations will continue discovering breaches where "all our security controls were in place" yet attackers maintained persistent access for months.
Behavioral detection catches compromised tokens that static tools miss. Understanding the changing relationships between your SaaS applications, monitoring for toxic combinations of stale and overprivileged access, and maintaining continuous visibility into your integration landscape; these capabilities transform MFA bypass from an undetectable attack vector into a behavioral anomaly you can identify and remediate.
The question for security teams is no longer whether MFA is important. It is. The question is: what protects the layer that MFA doesn't reach?
