Can Multi-Factor Authentication Be Bypassed?

Multi-factor authentication is one of the most effective ways to protect user accounts.

If an attacker obtains a password through phishing, password reuse or another data breach, MFA can prevent that password from being enough to access the account.

However, simply displaying an MFA screen does not guarantee that every route into an application is properly protected.

Consider this example:

1. A user enters a valid username and password.
2. The application asks for a one-time code.
3. The application has already created a partially authenticated session.
4. A protected page or API trusts that session without checking whether MFA was completed.

The visible login process appears secure. The user cannot reach the dashboard through the intended journey without entering the code.

But if the application does not consistently enforce the second factor, an attacker may be able to access protected functionality directly.

The important question is:

Does every route into the application require MFA, or only the most obvious login journey?

What does MFA actually protect?

Multi-factor authentication requires a user to provide evidence from at least two different types of authentication factor.

These factors usually fall into three categories:

• Something the user knows, such as a password
• Something the user has, such as a phone, authenticator or security key
• Something the user is, such as a biometric characteristic

Two passwords do not constitute MFA because they both belong to the same factor type.

Common MFA methods include:

• Authenticator application codes
• Push notifications
• Hardware security keys
• Passkeys
• SMS codes
• Email verification codes
• Recovery codes

These methods do not all provide the same level of protection.

One-time codes can be entered into a convincing phishing page and immediately relayed to the genuine application. Push notifications may be approved accidentally or after repeated prompts. SMS messages may also be exposed through weaknesses affecting the user’s mobile account.

Properly implemented passkeys and hardware security keys generally provide stronger protection against phishing because authentication is linked to the genuine application or website.

Any form of MFA is normally better than relying on a password alone, but the method and implementation both matter.

MFA bypass is often an application logic problem

Bypassing MFA does not usually require an attacker to break cryptography or predict a one-time code.

More often, the application fails to enforce the authentication workflow correctly.

Examples might include:

• Accessing a protected page before MFA is completed
• Calling an API after entering only the password
• Reusing a session created during partial authentication
• Using a password-recovery route that does not require MFA
• Manipulating a parameter that records MFA completion
• Switching to an older authentication endpoint
• Reusing a trusted-device token from another session
• Accessing a mobile or administrative interface with weaker controls

The application may implement the visible MFA step correctly while failing to apply the same requirement elsewhere.

This makes MFA testing part of both authentication testing and business-logic assessment.

The tester needs to understand the application’s intended sequence, identify the states created during that sequence and then determine whether those states are enforced consistently.

Direct access to protected functions

A penetration tester should not assume that users must follow the journey presented by the application.

The intended login sequence might be:

1. Submit a username and password.
2. Complete the MFA challenge.
3. Receive access to the account dashboard.

A tester will investigate what happens if the dashboard is requested immediately after the first step.

They may also test direct access to:

• Customer information
• Administrative pages
• File downloads
• Profile and security settings
• Payment functions
• Reporting features
• Data exports
• API operations

The application must check the user’s complete authentication state whenever it authorises a protected request.

Hiding a link until MFA has been completed is not sufficient. An attacker does not need to click the link if they can request its destination directly.

The same principle applies to buttons and interface controls. Disabling a payment button in the browser does not protect the underlying payment request if the API will still accept it.

Authorisation decisions must be enforced on the server.

Incomplete authentication workflow enforcement

Applications often have more authentication states than simply logged in and logged out.

A user might be:

• Unauthenticated
• Password accepted
• Waiting for MFA
• Fully authenticated
• Required to reset their password
• Enrolling an MFA method
• Recovering their account
• Using a remembered device
• Required to complete additional verification

Weaknesses can occur when the application does not distinguish reliably between these states.

A user whose password has been accepted is not necessarily fully authenticated. If MFA is required, the pre-MFA session should have very limited permissions.

Testing should examine:

• Whether workflow steps can be performed out of order
• Whether steps can be skipped
• Whether previous steps can be replayed
• Whether the browser controls the authentication state
• Whether changing a request parameter affects MFA enforcement
• Whether the same rules apply across different components
• Whether MFA enrolment can be deferred indefinitely
• Whether an interrupted workflow can be resumed insecurely

The server should decide whether MFA has been completed. It should not rely on a hidden form value, client-side script or cookie that the user can modify.

A partially authenticated session should be allowed to perform only the actions necessary to complete authentication. It should not inherit the permissions of a fully authenticated user.

Can the API bypass the MFA screen?

Modern web applications frequently use APIs behind the visible interface.

The browser might display an MFA challenge, but the underlying API could still accept requests using a token or session issued after the password stage.

Potentially affected components include:

• REST API endpoints
• GraphQL queries and mutations
• Mobile application APIs
• Legacy API versions
• Administrative APIs
• File download endpoints
• Export functions
• Reporting services
• Single-page application back ends

A tester can compare requests made at different stages of the login journey.

They might examine:

• Whether the token changes after MFA
• Whether session permissions change
• Which claims record MFA completion
• Whether a pre-MFA token can access protected endpoints
• Whether the API validates authentication assurance consistently
• Whether different API versions apply the same rules

A secure user interface does not automatically mean that the API is secure.

The interface may simply stop displaying protected functions until authentication is complete. If the API does not independently enforce the same requirement, an attacker may call it directly.

This type of weakness can be difficult to identify through ordinary user testing because the application appears to behave correctly when used as intended.

Password recovery and account recovery

Account recovery provides an alternative way to prove ownership of an account.

It is essential for users who lose their phone, replace a security key or otherwise cannot complete the normal MFA process. However, the recovery process can undermine MFA if it provides an easier route into the account.

Potential weaknesses include:

• Resetting a password and receiving immediate access without MFA
• Disabling MFA through an email recovery link
• Replacing the registered MFA device without sufficient verification
• Predictable or reusable recovery tokens
• Recovery codes that remain valid after use
• Support processes based on easily obtained personal information
• Changing the recovery email during partial authentication
• Existing sessions remaining active after recovery
• Recovery links that do not expire promptly
• MFA being removed automatically during a password reset

The underlying principle is simple:

Account recovery should not provide an easier route into the account than the normal authentication process.

If an attacker can bypass MFA by selecting “I have lost my device” and answering questions based on publicly available information, the protection offered by the second factor is significantly weakened.

Testing should consider both automated recovery features and manual support processes.

The organisation also needs a secure and practical way to assist genuine users. A recovery process that is too weak is dangerous, but one that is impossible to complete can lead staff to create unsafe exceptions under pressure.

Remembered and trusted devices

Many applications allow users to select an option such as:

Remember this device

This can improve usability by avoiding an MFA challenge at every login. However, the remembered-device function creates another credential that must be protected.

The feature may rely on:

• A persistent cookie
• A signed token
• A device identifier
• A server-side trust record
• A long-lived session

A penetration test should investigate:

• Whether the token is unpredictable
• Whether it is cryptographically protected
• Whether it is tied to the correct user
• Whether it can be copied to another browser
• How long it remains valid
• Whether it survives a password change
• Whether it remains valid after MFA is removed or replaced
• Whether users can view and revoke trusted devices
• Whether administrators can invalidate trusted devices
• Whether sensitive actions still require fresh authentication

A remembered-device token effectively becomes an alternative route around the MFA challenge.

If an attacker steals that token, the application may treat the attacker’s browser as trusted even though they have never completed MFA.

Remembered-device functionality should therefore be treated as a security-sensitive feature, not simply a convenience setting.

Session handling before and after MFA

Correct session management is essential to MFA enforcement.

The application may create a session when the user first visits the login page, update it when the password is accepted and then elevate it again after MFA is completed.

A tester should examine whether:

• The session identifier changes after password authentication
• The session changes again after MFA completion
• A pre-MFA session can access post-MFA functionality
• Logout invalidates the session on the server
• Password changes invalidate existing sessions
• MFA changes invalidate remembered devices
• Sessions expire after an appropriate period
• Users can view and revoke active sessions
• Sensitive actions require recent authentication

Session fixation is one relevant risk.

In a session-fixation attack, an attacker attempts to control or obtain the identifier for a session that later becomes authenticated by the legitimate user. If the application does not rotate the identifier at the correct stages, the attacker may be able to reuse that session.

MFA cannot protect an account if an attacker can steal or reuse an already authenticated session.

This is why phishing campaigns increasingly focus on session tokens as well as passwords and one-time codes. Once the legitimate user has completed authentication, a stolen session may allow the attacker to act as that user without repeating the MFA process.

Enabling, disabling and replacing MFA

Authentication settings are among the most sensitive functions within an account.

A tester should determine whether a password-only or partially authenticated session can:

• Disable MFA
• Change the registered telephone number
• Register a new authenticator application
• Generate recovery codes
• View existing recovery codes
• Add a passkey
• Add a security key
• Mark a device as trusted
• Change the recovery email address

These operations should normally require strong reauthentication.

A user who has left their computer unlocked, for example, should not automatically allow somebody else to disable MFA or register a new authentication method.

The application should also notify the legitimate user when important authentication settings change.

Relevant notifications might include:

• A new MFA method was registered
• MFA was disabled
• Recovery codes were generated
• A new device was trusted
• A passkey or security key was added
• The recovery email address changed
• An account-recovery process was completed

Notifications do not prevent the change, but they can help the user identify and report unauthorised activity quickly.

One-time code implementation weaknesses

Time-based and single-use codes need to be implemented carefully.

Potential weaknesses include:

• Codes can be reused
• Codes remain valid for too long
• Submission attempts are not rate-limited
• Rate limiting applies only to the browser interface
• A code issued for one account works against another
• Several active codes remain valid
• Requesting a new code does not invalidate the previous one
• Codes appear in URLs or logs
• Verification responses reveal useful information
• Concurrent requests allow the same code to be accepted more than once

A six-digit code has a limited number of possible combinations. Its security depends on short validity periods, controlled submission attempts and correct association with the user and authentication session.

Rate limiting also needs to be applied consistently.

Blocking repeated attempts from one browser may not be effective if an attacker can distribute requests across multiple sessions or submit codes directly to an API endpoint.

Testing must be carefully controlled to avoid locking accounts, generating excessive messages or disrupting external SMS and email services.

The objective is to confirm that appropriate protections exist, not to exhaust every possible code.

Push notifications and MFA fatigue

Push-based authentication allows a user to approve or reject a login request through an application on their phone.

It is convenient, but it can be weakened if an attacker who knows the password repeatedly triggers approval requests.

The user may approve one:

• Accidentally
• To stop the repeated notifications
• Because they assume it relates to their own activity
• After being contacted by someone impersonating IT support
• Because the prompt provides insufficient context

This technique is sometimes referred to as MFA fatigue or push bombing.

Applications and identity providers can reduce this risk through:

• Number matching
• Clear information about the login
• Geographic and device context
• Rate limiting
• Suspicious-login detection
• Alerts for repeated requests
• Phishing-resistant authentication methods

Number matching requires the user to enter or select a number shown in the original login session. This makes accidental approval more difficult because the person needs to interact with both sides of the authentication process.

User experience matters here. An authentication prompt that clearly explains which service, location and device generated the request helps the user make a more informed decision.

Alternative login routes

An application may support more than one authentication method.

These might include:

• Standard web login
• Mobile application login
• Single sign-on
• Social login
• Legacy authentication
• API authentication
• Administrative portals
• Support portals
• Partner portals
• Customer portals

The strongest MFA control is undermined if another supported route accepts only a password.

An organisation may add MFA to its main web portal while overlooking an older mobile API or administrative interface. The protected interface is then not the only route into the account.

Testing should identify every authentication entry point and determine whether equivalent policies apply to each one.

Legacy routes deserve particular attention. They may remain active to support older applications even though the primary login process has been modernised.

If an authentication method is no longer required, removing it is usually safer than attempting to maintain it indefinitely.

Single sign-on and federated authentication

Applications frequently rely on Microsoft Entra ID or another identity provider to authenticate users.

In this model, MFA may be enforced by the identity provider rather than by the application itself.

This can provide strong and consistent authentication, but the application still has responsibilities.

Testing should consider:

• Whether local application accounts remain available
• Whether alternative identity providers enforce equivalent controls
• Whether the application correctly interprets authentication claims
• Whether older authentication methods remain enabled
• Whether authentication claims can be replayed or trusted incorrectly
• Whether sensitive functions require an appropriate assurance level
• Whether the application protects its own session correctly

A local administrator account may bypass the organisation’s otherwise strong SSO policy. A test environment may also use a separate identity provider with weaker controls.

The application must validate the authentication result, confirm that it was issued by a trusted provider and ensure that the user satisfies the required security policy.

It should not simply assume that every successful SSO response represents the same level of authentication assurance.

How a penetration tester assesses MFA

Testing MFA requires a structured approach and agreed test accounts.

Map every authentication route

The tester identifies web, mobile, API, SSO, administrative and recovery journeys.

This includes alternative portals, legacy endpoints and different user roles.

Record each authentication state

Sessions and tokens can be compared:

• Before login
• After password acceptance
• While waiting for MFA
• After MFA completion
• During account recovery
• After a device is remembered

This helps the tester understand how the application represents each state.

Attempt controlled workflow changes

The tester checks whether steps can be skipped, replayed or performed in a different order.

Client-controlled parameters and workflow identifiers can also be reviewed to determine whether they influence authentication decisions.

Test protected functions directly

Sensitive pages and API operations are requested using a partially authenticated session.

The tester verifies that the server rejects these requests rather than relying on the browser to hide the relevant controls.

Assess account recovery

Password resets, replacement devices and recovery codes are examined to determine whether they weaken the main MFA process.

Examine remembered devices

The assessment reviews how trusted-device tokens are created, stored, used and revoked.

Where appropriate, controlled tests can determine whether a token works from another browser or remains valid after a security change.

Review the session lifecycle

The tester examines session rotation, expiry, logout and invalidation following password or MFA changes.

Assess rate limiting

Code and push-notification controls are checked across interfaces, APIs, accounts and sessions.

All testing should be performed using authorised test accounts and within agreed limits. Unnecessary disruption to genuine users and messaging services should be avoided.

Why automated scanners may miss MFA bypasses

Automated scanners can identify some cookie, session and configuration issues.

However, MFA bypasses often depend on understanding:

• The intended login workflow
• Different authentication states
• User roles
• Recovery processes
• Relationships between the interface and API
• The meaning of session tokens
• Business rules API around trusted devices
• Alternative login routes

A scanner may see that the application displays an MFA page without understanding whether a token issued before that page can access an API endpoint.

It may not know that a recovery link disables MFA, that a mobile application uses an older API or that a remembered-device token survives a password change.

Manual testing allows the tester to compare these journeys, understand the intended security model and identify inconsistencies that automated tools may not recognise as vulnerabilities.

What could an MFA bypass mean for the business?

An MFA bypass could allow an attacker with a stolen, reused or guessed password to:

• Take over customer accounts
• Access personal or commercially sensitive information
• Change payment details
• Modify contact information
• Download protected documents
• Perform administrative actions
• Compromise other users
• Circumvent a control presented to customers as a security feature

The consequences may include:

• Data breaches
• Fraud
• Service disruption
• Regulatory exposure
• Contractual consequences
• Customer complaints
• Loss of confidence

The impact may be particularly serious where customers have been told that MFA provides strong protection for their accounts.

If an attacker can avoid the second factor through an alternative API or recovery route, the organisation may have a false sense of assurance.

How can organisations strengthen MFA?

Practical measures include:

• Enforce MFA at every authentication entry point
• Track authentication state securely on the server
• Reject protected requests from partially authenticated sessions
• Apply equivalent controls to interfaces and APIs
• Rotate sessions after password and MFA stages
• Protect recovery processes to an equivalent standard
• Require reauthentication for security-sensitive changes
• Make trusted devices visible and revocable
• Invalidate sessions following password or MFA changes
• Rate-limit code submission and push requests
• Prevent one-time code reuse
• Prefer phishing-resistant methods where practical
• Remove unnecessary legacy authentication routes
• Log and alert on authentication and recovery changes
• Notify users when important security settings change
• Test authentication controls after significant application changes

Developers should define the application’s authentication states clearly and enforce the transitions between them on the server.

Security should not depend on the user following the expected sequence through the interface.

Seeing an MFA prompt is not enough

MFA remains an essential security control. Businesses should enable it wherever practical and prefer phishing-resistant methods for sensitive and privileged accounts.

Its effectiveness, however, depends on consistent enforcement throughout the application.

A penetration test should establish whether:

• MFA is required across every login route
• Partially authenticated sessions are properly restricted
• Protected APIs enforce the same controls as the interface
• Recovery and trusted-device features are secure
• Sessions are rotated and invalidated correctly
• Sensitive account changes require fresh authentication
• Legacy and alternative authentication routes provide equivalent protection

The real test is not whether the application displays an MFA screen.

It is whether there is any route around it.

Does your application protect customer or administrative accounts with multi-factor authentication?

Plainsight Security can assess the complete authentication journey, including APIs, account recovery, trusted devices and session handling. Contact us to discuss a web application penetration test.