MFA Bypass
detect, understand, remediate
MFA bypass is the class of weaknesses that lets an attacker defeat or skip the second authentication factor. It spans adversary-in-the-middle phishing kits that steal the post-MFA session, push notification fatigue, SIM swap of the SMS factor, backup-code abuse, helpdesk-driven enrolment reset, consent phishing against OAuth, and design flaws that let the second-factor step be skipped or replayed.
No credit card required. Free plan available forever.
What is MFA bypass?
MFA bypass is the class of weaknesses that allows an attacker to authenticate as a user despite the presence of a second authentication factor. It is not a single bug. It is a category that spans phishing kits that proxy the login page in real time and capture the post-MFA session, push notification flooding that wears the user down until they approve, SIM swap of the SMS factor, abuse of backup recovery codes, helpdesk-driven enrolment reset, consent phishing against OAuth, and application-layer flaws that let the second-factor step be skipped, replayed, or downgraded. The canonical CWE root is CWE-308 (Use of Single-Factor Authentication), with neighbouring CWE-287 (Improper Authentication), CWE-303 (Incorrect Implementation of Authentication Algorithm), CWE-304 (Missing Critical Step in Authentication), CWE-305 (Authentication Bypass by Primary Weakness), and CWE-345 (Insufficient Verification of Data Authenticity) carrying the more specific failures. OWASP groups these findings under A07:2021 Identification and Authentication Failures.
The category matters because MFA has become the default control identity teams point to when describing their account-takeover defence, and the threat landscape has adapted. Public threat intelligence from CISA, Microsoft, Mandiant, and Cisco Talos has reported MFA bypass as the dominant access vector against enterprise identity providers (Microsoft Entra ID, Okta, Google Workspace) over the past three years. Most of the high-profile incidents that targeted SaaS platforms in 2023 and 2024 did not break MFA cryptography; they walked around it through one of the patterns this page covers.
MFA bypass overlaps with broken authentication, authentication bypass, and session fixation, but it is not the same finding. Broken authentication covers the wider login-flow weakness class, authentication bypass covers the cases where the first factor is skipped or defeated, and session fixation covers a specific session-handling defect. MFA bypass is the post-first-factor surface where the second factor either does not block the attacker or is never enforced. Treating the four findings as separate records keeps the remediation specific and the audit trail honest.
How MFA bypass works in practice
The eight techniques below are the patterns most often observed against enterprise identity providers and application-layer MFA. Each technique has a different mechanism, a different detection signal, and a different fix path. A defensible remediation plan reads against the whole list rather than only the technique that surfaced first.
Adversary-in-the-middle (AiTM)
A reverse-proxy phishing kit (Evilginx, Modlishka, EvilProxy, Tycoon 2FA) sits between the user and the real login. The user enters credentials and the second factor on a page that looks correct; the kit replays the values to the real identity provider, captures the resulting session cookie, and hands it to the operator. The cookie is valid until expiry, and the attacker logs in without retriggering MFA.
MFA fatigue / push bombing
The attacker holds valid credentials (from a previous breach, infostealer log, or password spray) and triggers repeated push approval prompts. The user, worn down or confused, eventually taps approve. The 2022 Uber, Cisco, and several large-scale Lapsus$ incidents used this pattern. Number matching, geographic context, and approval throttling close the path.
SIM swap
The attacker convinces the mobile carrier to port the victim number to an attacker-controlled SIM. SMS-delivered one-time codes arrive at the attacker. NIST SP 800-63B has discouraged SMS as a restricted factor for high-assurance use cases since 2017 and recommends migrating privileged accounts off SMS entirely.
Pass-the-cookie / session token theft
An infostealer (Lumma, RedLine, Vidar, Raccoon), browser exploit, malicious extension, or supply-chain compromise harvests session cookies from the victim browser profile. The cookie carries the post-MFA assertion and the attacker imports it into their own browser. The session bypasses MFA because the second factor already succeeded in the legitimate session.
Consent phishing (OAuth)
The attacker registers a malicious OAuth application and tricks the user into granting it scopes such as mail.read or files.read. The user completes MFA against the identity provider, the OAuth flow returns the token, and the attacker now holds an offline refresh token that grants API access without ever prompting for MFA again.
Application-layer step skipping
The application implements MFA as a navigation step rather than a server-side check on every protected route. The attacker authenticates with the first factor, then navigates directly to a post-MFA URL, manipulates a step parameter, or replays a state cookie that the server trusts without verifying the second factor.
Backup code and recovery abuse
Recovery codes and SMS fallback paths are weaker than the primary factor and are often retained indefinitely. An attacker who phishes one recovery code, recovers it from a password manager export, or convinces the helpdesk to issue a new code bypasses MFA without ever interacting with the authenticator app.
Helpdesk-driven enrolment reset
Social engineering against the IT helpdesk or identity team to clear the existing MFA enrolment and enrol an attacker-controlled device. The Lapsus$ group used this pattern repeatedly. Helpdesk verification scripts, voice-callback to a known number, in-person verification for privileged accounts, and a documented enrolment-reset runbook close the path.
Why the factor type changes the bypass story
NIST SP 800-63B groups authenticators by assurance level, and the bypass profile changes sharply as the factor strength rises. A remediation plan that treats every MFA factor as equivalent will leave a phishable factor in place against a phishing-led threat. The four bands below frame the realistic resistance of each factor type against AiTM and adjacent attacks.
SMS and voice OTP
Restricted factor under NIST SP 800-63B. Vulnerable to SIM swap, SS7 interception, and AiTM proxy because the code is replayable. Acceptable for low-risk accounts as a fallback only; discouraged for privileged roles.
TOTP authenticator app
Stronger than SMS, no carrier dependency, but still phishable through AiTM because the code can be replayed inside the kit window. Acceptable for the majority of workforce accounts when paired with conditional access and short session lifetimes.
Push approval with number matching
Resists fatigue and push bombing when number matching, geographic context, and approval throttling are enforced. Still phishable through AiTM unless the push includes verifier hostname binding. Useful for workforce accounts when configured correctly.
FIDO2 / WebAuthn / passkeys
Phishing-resistant under NIST SP 800-63B AAL3 when used with hardware authenticators or platform passkeys. The private key never leaves the device, the assertion is bound to the verifier origin, and AiTM proxies cannot replay the credential. The recommended target factor for privileged roles, administrative accounts, and SaaS access to crown-jewel platforms.
Common causes
Phishable factor left in place for privileged accounts
Administrative and other privileged accounts still enrolled in SMS or TOTP without a parallel push to phishing-resistant authenticators. The privileged user has the same MFA posture as the front-line employee against an AiTM phish.
Push prompts without number matching or throttling
Push approval configured with a single-tap accept and no per-user rate limit. An attacker holding valid credentials triggers approval flood until the user taps. Microsoft, Okta, and Duo now ship number matching by default on new tenants; older tenants often still have the legacy flow.
MFA implemented as a navigation step rather than a server check
The application stores the MFA-passed state in a client-side flag or trusts a step parameter in the URL. Direct navigation to a post-MFA route, a step-parameter manipulation, or a state-cookie replay reaches the protected resource without verifying the second factor.
Session cookies survive longer than the threat model assumes
Session tokens with multi-day lifetimes, no idle timeout, no rotation on privilege change, and no binding to the originating device. An infostealer that captures the cookie once retains access for the full lifetime, defeating the MFA prompt the user originally completed.
OAuth consent without re-authentication or risk-based prompt
OAuth applications can request high-impact scopes (mail.read, files.read, Sites.Read.All) and receive an offline refresh token without triggering an admin consent prompt or a step-up re-authentication. Consent governance, app verification, and publisher-attested app allow-lists close the path.
No helpdesk script for enrolment reset
The helpdesk can reset a user MFA enrolment after a short verbal verification (date of birth, employee number, manager name). An attacker with social-engineering preparation completes the reset in minutes. A documented script, voice-callback to a known number, and in-person verification for privileged accounts close the path.
How to detect MFA bypass
Detection runs across two surfaces. Active testing produces signals an authenticated scanner and a code scanner can read against the application implementation, and identity-provider telemetry surfaces the runtime evidence that AiTM, push bombing, consent phishing, and impossible travel are happening against live accounts. A defensible MFA posture runs both halves and records each finding on the canonical engagement record.
Active testing signals
- SecPortal authenticated scanning probes the second-factor flow for step skipping by attempting to reach post-MFA URLs after the first factor, manipulating the step parameter, replaying expired verification codes, and verifying that the server enforces the second factor on every protected route rather than trusting a client-side flag.
- External scanning identifies password-only login surfaces on the verified perimeter that should require a second factor, including legacy SSO endpoints, password-only API authentication routes, basic-auth-protected admin interfaces, and authentication endpoints that respond to credential-only requests.
- Code scanning runs Semgrep rule packs against connected repositories for verification-step bypass patterns (a single boolean controlling MFA enforcement, an environment flag that disables MFA in production, a fallback path that accepts a hard-coded backup code, OAuth scope grants without re-authentication, and missing server-side enforcement after the second factor succeeds).
- Findings management records the CWE-308 / CWE-287 / CWE-304 mapping, the affected authentication surface, the bypass technique observed, the evidence (request and response captures, proof-of-concept), and a CVSS 3.1 vector calibrated for the account tier the bypass reaches rather than the generic base score.
Identity provider and runtime signals
- Review identity provider sign-in logs for the AiTM tell: a successful sign-in from an unfamiliar IP or autonomous system shortly after a phishing campaign indicator, with the MFA claim satisfied because the kit relayed the prompt. Microsoft Entra ID risk detections and Okta ThreatInsight surface the pattern; ingest the alerts into the SOC backlog and onto the engagement record alongside the application-layer findings.
- Monitor for push approval flood patterns: more than a threshold of denied approvals followed by a successful approval inside a short window. Alert on the pattern, force a re-authentication on the next sign-in, and require the user to confirm whether the approval was intentional.
- Audit OAuth application consent grants on a quarterly cadence. Look for over-privileged scopes against publisher-unverified applications, consent grants outside business hours, and consent grants from accounts that do not normally use the granted scope. Revoke and investigate any grant that does not match a documented business need.
- Track helpdesk MFA reset volume and any reset that completes outside the documented script. A reset that bypassed the script is a finding and goes onto the engagement record alongside the application-layer evidence.
How to remediate MFA bypass
Migrate privileged accounts to phishing-resistant MFA
Move administrative, security, finance, executive, and crown-jewel SaaS accounts to FIDO2 / WebAuthn / passkeys backed by hardware authenticators or platform passkeys. The verifier-origin binding closes the AiTM path. Roll out in waves keyed to account risk tier, and treat the legacy factor as the temporary fallback until enrolment is complete.
Enforce number matching, geographic context, and approval throttling on push
Configure the identity provider so the user must enter or confirm a numeric code displayed in the login page, include the source application and location in the prompt, and throttle approval attempts per user per minute. Microsoft enforces number matching for Authenticator by default; verify the setting is on for your tenant.
Remove SMS and voice as a factor for privileged roles
Restrict SMS and voice OTP to break-glass and low-risk fallback use only. NIST SP 800-63B has discouraged SMS as a restricted factor since the 2017 revision. Document the policy, audit enrolment, and migrate privileged users off SMS as a measured project.
Enforce the second factor server-side on every protected route
Treat MFA as a property of the session, not a navigation step. Store the MFA-satisfied claim server-side, bind it to the session, and check it on every protected handler. Reject any request whose session lacks the claim. Promote the session to AAL2 on the second factor and gate sensitive routes against AAL2.
Shorten session lifetimes and rotate on privilege change
Cap session lifetimes against the asset tier the session reaches, force re-authentication on idle timeout, rotate the session identifier on privilege change, and bind the session to a device or token where supported. Pair-the-cookie attacks lose value when the cookie expires before the attacker can use it widely.
Add conditional access against impossible travel, unfamiliar device, and risky sign-in
Configure the identity provider conditional-access policies so a risky sign-in (unfamiliar IP, unfamiliar device, impossible travel, unmanaged endpoint) prompts a step-up MFA challenge or blocks the sign-in. Pair the policy with a sign-in risk feed (Entra ID Identity Protection, Okta ThreatInsight) so the policy reads against current threat data.
Tighten OAuth consent governance
Disable user consent to high-impact scopes, require admin consent for unverified publishers, maintain an allow-list of approved applications, and review consent grants quarterly. Step-up re-authentication before scope grant where the platform supports it.
Document the helpdesk enrolment-reset runbook
Write the verification script the helpdesk runs before any MFA enrolment reset: voice-callback to a known number on file, identity question that is not in the public record, manager confirmation for privileged roles, and in-person verification for executive and administrative accounts. Treat any reset that completes outside the script as a finding.
Verify closure with a follow-up exercise
A MFA bypass finding moves to closed only when a fresh test scenario (a controlled AiTM exercise, a controlled push flood, a controlled step-skip attempt) demonstrates the fix on the affected surface. Closure on documentation alone accumulates into reopen rate; closure on demonstrated resistance produces durable closures.
How SecPortal records and tracks MFA bypass findings
SecPortal is not an identity provider, is not a SIEM, and does not enforce MFA on your applications. It is the workspace where every MFA bypass finding lands on the engagement record alongside source-level findings, external attack-surface findings, and authenticated DAST findings so severity, ownership, evidence, fix, and retest stay on one canonical record per bypass path. The flow looks like this on the platform.
Run authenticated scanning behind login
Authenticated scanning probes the second-factor flow for step skipping, replay of expired verification codes, direct access to post-MFA URLs, and missing server-side enforcement after the second factor succeeds. Findings land on the engagement record with the bypass technique, the affected surface, and the captured evidence.
Run external scanning across the verified perimeter
External scanning identifies password-only login surfaces that should require a second factor, MFA-optional flags on privileged user roles, and authentication endpoints that respond to credential-only requests. Findings land with the SSL Checker, Headers Checker, and probe-module evidence on the engagement record.
Run code scanning across connected repositories
Code scanning executes Semgrep rule packs against connected GitHub, GitLab, and Bitbucket repositories for verification-step bypass patterns, hard-coded backup-code fallbacks, MFA-skip feature flags shipped to production, and OAuth scope grants without re-authentication. Findings carry the file path, line number, and matched rule on the engagement record.
Record findings with the CWE and OWASP mapping
Findings management captures CWE-308, CWE-287, CWE-304, the OWASP A07:2021 mapping, the affected authentication surface, the bypass technique observed, the evidence, and a CVSS 3.1 vector calibrated for the account tier the bypass reaches rather than the generic base score.
Use SecPortal MFA on the workspace itself
The workspace running the security programme should not be the weak link. SecPortal supports TOTP enrolment per user and workspace-enforced MFA that promotes the session to AAL2; owners enable workspace MFA from Settings and members enrol on next login. The workspace is the source of truth for the engagement record, and the MFA control matches the standard the page is recommending.
Capture the activity log as the workspace audit chain
Activity log records every workspace decision (engagement scope, finding triage, severity override, status transition, exception approval, retest closure) with the acting user and timestamp, exports to CSV, and gives the GRC team an audit-grade record of how MFA bypass findings moved through the programme.
Map findings against multi-framework compliance
Compliance tracking maps MFA bypass findings against OWASP ASVS V2 (Authentication), PCI DSS v4 Requirement 8 (Identify Users and Authenticate Access), ISO 27001 Annex A.5.17 (Authentication information) and A.8.5 (Secure authentication), SOC 2 CC6.1 (Logical Access Controls), NIST SP 800-53 IA control family, NIS2 Article 21, and NIST CSF 2.0 PR.AA in parallel.
Capture MFA bypass exceptions on the finding record
When a bypass path cannot be remediated immediately (a third-party SaaS without phishing-resistant factor support, a legacy integration with no FIDO2 path, a regulated workflow with a longer migration plan), the exception lives on the finding through the override pattern with named owner, compensating controls, residual-risk rationale, review cadence, and expiry rather than in a meeting note.
Verify closure through retesting workflows
The retesting workflow pairs the retest to the original finding so closure means a fresh AiTM exercise, push flood, or step-skip attempt demonstrates the fix on the affected surface. The verified_at and resolved_at timestamps preserve the audit chain of when the change shipped and who confirmed it.
What SecPortal does not do
Honesty on capability matters when the topic is identity defence. SecPortal is not an identity provider (Microsoft Entra ID, Okta, Ping, Auth0, Google Workspace), is not a SIEM (Splunk, Sentinel, QRadar, Chronicle), is not an identity threat detection and response platform, does not federate against your identity provider, does not parse identity provider sign-in logs, does not run conditional-access policy, does not host an OAuth consent governance console, does not block AiTM phishing in real time, and does not integrate with Jira, ServiceNow, Slack, PagerDuty, Opsgenie, or any ticketing or paging system through a packaged API surface. Programmes that need real-time identity-provider telemetry, conditional-access enforcement, OAuth consent governance, or 24/7 identity SOC operations run a dedicated identity provider plus a SIEM and ITDR layer, and land the resulting MFA bypass findings on the SecPortal engagement record through bulk finding import. The platform value is the consolidated record where every bypass finding (whether it came from native authenticated scanning, external scanning, code scanning, bulk import from an outside identity review, a tabletop exercise after-action, or a manual finding entry against a helpdesk-reset gap) lives alongside the rest of the security backlog with the same lifecycle, the same role-based access control, the same activity log, and the same evidence trail.
Related vulnerabilities and recommended reading
MFA bypass sits in the wider identification and authentication failure cluster. The pages below cover adjacent finding shapes, the frameworks that map control evidence against authentication posture, and the programme workflows that hold the MFA backlog across detect, triage, prioritise, route, remediate, and verify.
- Broken authentication the wider login-flow weakness class that MFA bypass extends past the first factor.
- Authentication bypass the sibling finding where the first factor is skipped or defeated rather than the second factor.
- Session fixation the session-handling defect that lets an attacker reuse a session token across the MFA boundary.
- JWT vulnerabilities the token-format failures that let a captured post-MFA assertion be replayed or forged.
- OAuth misconfiguration the consent and redirect URI weaknesses that let an attacker land a long-lived refresh token without an MFA prompt.
- Insecure cookie attributes the cookie-flag gaps that make pass-the-cookie attacks easier on captured session tokens.
- Username enumeration the reconnaissance step that lets an AiTM operator target the right account list before launching the phish.
- Password reset poisoning the recovery-flow defect that lets an attacker bypass MFA by resetting the credential rather than authenticating.
- OWASP ASVS Chapter V2 Authentication is the verification standard section that reads against the controls MFA bypass expects.
- ISO/IEC 27001 Annex A.5.17 (authentication information) and A.8.5 (secure authentication) are the ISO mappings for MFA control evidence.
- PCI DSS Requirement 8 covers identification and authentication for the cardholder data environment, including MFA for administrative access.
- NIST CSF 2.0 the PR.AA identity authentication and access control category maps MFA posture to outcomes the GV.OC scope reads against.
- SecPortal multi-factor authentication the feature page covering workspace-enforced TOTP MFA on SecPortal itself for the team running the engagement record.
- Identity threat detection and response explained the operating layer that monitors identity provider telemetry for AiTM, push flood, and risky sign-in patterns at runtime.
- Zero trust architecture implementation guide the wider identity-led architecture pattern that pairs phishing-resistant MFA with conditional access and device posture.
- Non-human identity security guide the adjacent identity surface where machine accounts and service principals lack the MFA layer and require credential-based controls instead.
- Security leadership reporting the workflow that carries MFA bypass posture, phishing-resistant adoption rate, and remediation cadence into the leadership read.
- SecPortal for internal security teams the audience overview for the teams that own MFA posture across the application and identity portfolio.
Compliance impact
OWASP ASVS
V2 Authentication
PCI DSS
Req. 8 Identification and Authentication
ISO/IEC 27001
A.5.17 Authentication, A.8.5 Secure authentication
SOC 2
CC6.1 Logical Access Controls
NIST 800-53
IA Identification and Authentication
NIST CSF 2.0
PR.AA Identity and Authentication
NIS2 Directive
Article 21 Cybersecurity risk-management measures
CIS Controls
Control 6 Access Control Management
Related features
Test web apps behind the login
Vulnerability scanning tools that map your attack surface
Find vulnerabilities before they ship
Vulnerability management software that tracks every finding
Multi-factor authentication on every workspace
Every action recorded across the workspace
Compliance tracking without a full GRC platform
Verify fixes and track reopens on the same finding record
Finding overrides that survive every scan cycle
Run MFA bypass findings on one engagement record
SecPortal pairs the authenticated scan, the external scan, and the code scanner with one findings record per MFA bypass path, with CVSS 3.1 severity, framework mapping, retest pairing, and an append-only activity log. Start scanning for free.
No credit card required. Free plan available forever.