Back to Blog
Understanding Multi-Factor Authentication: How It Works, How It Fails, and How to Defend It
PublishedSeptember 11, 20267 min readBeginner

Understanding Multi-Factor Authentication: How It Works, How It Fails, and How to Defend It

Learn what Multi-Factor Authentication (MFA) is, how attackers attempt to bypass it, and how security analysts detect MFA-related attacks.

Cyber SecurityCybersecuritySecurity Operations
Written byAbdul Muqeet Tabraiz

For decades, passwords were the primary gatekeepers of corporate networks and personal accounts. But relying solely on passwords creates a single point of failure. Users reuse passwords across multiple sites, choose easy-to-guess phrases, or fall victim to phishing attacks where they willingly hand over their credentials to fake login pages.

To address this weakness, organizations rely heavily on Multi-Factor Authentication (MFA). While MFA significantly improves identity security, it is not an invincible security control. Attackers have adapted their techniques to bypass or trick users during the authentication process.

Understanding how MFA works, where different implementation methods fail, and how security teams detect authentication anomalies is a fundamental skill for anyone entering security operations.


What is Multi-Factor Authentication?

Authentication is the process of proving who you are to a computer system. Multi-Factor Authentication (MFA) requires a user to present two or more distinct types of evidence (factors) before access is granted.

Authentication factors fall into three core categories:

  1. Something You Know (Knowledge): Information only the user should know, such as a password, a PIN, or answers to security questions.
  2. Something You Have (Possession): A physical or digital item in the user’s possession, such as a smartphone running an authenticator app, a hardware security key, or a physical smart card.
  3. Something You Are (Inherence): Biometric characteristics unique to the individual, such as a fingerprint, facial scan, or retina scan.

To qualify as true multi-factor authentication, the login mechanism must combine factors from different categories. Using two separate passwords is two-step verification, but it is not multi-factor authentication because both factors belong to the “something you know” category.

       +-------------------------------------------------+
       |           Authentication Categories            |
       +--------------------+----------------------------+
       | Knowledge          | Password, PIN              |
       | Possession         | Authenticator App, Key     |
       | Inherence          | Fingerprint, Face ID       |
       +--------------------+----------------------------+

The Core MFA Flow

In a standard enterprise login scenario, the identity provider—a centralized server managing user identities, such as Microsoft Entra ID or Okta—handles authentication in structured steps:

  1. Primary Authentication: The user enters their username and password. The identity provider checks the credential store. If incorrect, access is denied immediately.
  2. Challenge Trigger: If the password is correct, the system recognizes that the account requires a secondary factor. It initiates a secondary verification request.
  3. Secondary Verification: The user presents their second factor. This might mean typing in a six-digit Time-based One-Time Password (TOTP) from an authenticator app or tapping “Approve” on a mobile push notification.
  4. Token Issuance: Once the secondary factor is verified, the server issues a session token (such as a HTTP cookie or JSON Web Token) to the user’s browser, granting access to the system without requiring them to re-authenticate for every page refresh.

Comparing Common MFA Types

Not all MFA implementations offer the same level of security. Choosing the right method involves balancing user convenience against security strength.

1. SMS and Voice Calls

The system sends a text message or voice call containing a short code to the user’s phone number.

  • Pros: Easy to set up, requires no specialized app.
  • Weaknesses: Highly vulnerable to SIM swapping (where an attacker convinces a mobile provider to transfer a victim’s phone number to a new SIM card under the attacker’s control) and SMS interception.

2. Time-Based One-Time Passwords (TOTP)

An authenticator app (such as Google Authenticator or Microsoft Authenticator) generates a temporary 6-digit code that changes every 30 seconds based on a shared secret key stored on the phone and the current clock time.

  • Pros: Works offline, not reliant on cellular carriers.
  • Weaknesses: Users can still be tricked into typing the 6-digit code into a phishing site.

3. Mobile Push Notifications

The user receives a pop-up alert on their smartphone asking them to approve or deny the login request.

  • Pros: Fast and user-friendly.
  • Weaknesses: Susceptible to user fatigue and accidental approvals.

4. Hardware Keys (FIDO2 / WebAuthn)

Physical USB or NFC devices (such as YubiKeys) that require the user to touch the device to approve a login.

  • Pros: Immune to standard phishing attacks because the authentication request is cryptographically bound to the legitimate website domain name.
  • Weaknesses: Physical key distribution costs and risk of lost hardware.

How Attackers Bypass MFA

Understanding defensive security requires knowing how adversaries bypass controls. Attackers rarely break the underlying cryptography of MFA; instead, they target human behavior and session management.

1. MFA Fatigue (Prompt Bombing)

If an attacker obtains a valid user password, they can trigger dozens of push notification requests in rapid succession—often late at night or early in the morning. The goal is to frustrate or confuse the victim into tapping “Approve” simply to stop the continuous notifications.

2. Adversary-in-the-Middle (AiTM) Phishing

Instead of hosting a simple static form, modern phishing frameworks act as a proxy between the target user and the actual login page.

  1. The user visits a malicious link in a phishing email.
  2. The attacker’s server proxies the request to the real login page and serves the actual page back to the user.
  3. The user enters their password and their MFA code into the fake interface.
  4. The attacker’s server forwards these credentials to the legitimate service and completes the login process.
  5. The legitimate service sends back a session cookie. The attacker captures this session cookie, allowing them to impersonate the user directly without needing to log in again.
+------+          +-------------------+          +---------------+
| User | -------> | Attacker Proxy    | -------> | Real Auth     |
|      |          | (Phishing Site)   |          | Service       |
+------+          +-------------------+          +---------------+
                    Captures Credentials
                    & Session Tokens

Spotting MFA Anomalies in Logs

Security analysts monitor authentication events in a Security Information and Event Management (SIEM) platform—a centralized tool that collects and analyzes log data from systems across an enterprise network.

When investigating suspicious MFA activity, analysts look for patterns rather than isolated events.

Example Log Analysis: MFA Fatigue Pattern

Below is a simplified example of identity provider logs showing a potential MFA fatigue attack:

Timestamp: 2026-09-11 02:14:10 UTC
User: john.doe@company.com
Client IP: 198.51.100.22 (Location: Foreign Region)
Event: Primary Authentication
Status: Success (Password Valid)

Timestamp: 2026-09-11 02:14:15 UTC
User: john.doe@company.com
Event: MFA Push Sent
Status: Denied (User rejected push notification)

Timestamp: 2026-09-11 02:14:30 UTC
User: john.doe@company.com
Event: MFA Push Sent
Status: Denied (User rejected push notification)

Timestamp: 2026-09-11 02:15:02 UTC
User: john.doe@company.com
Event: MFA Push Sent
Status: Success (User approved push notification)

Key Technical Indicators to Watch:

  • Time Delays: A password attempt followed by rapid, repeated MFA failures, ending with a single approval within minutes.
  • Geographic Anomaly: The password entry originates from an IP address in a country where the user does not reside, while the MFA notification is received by the user’s physical device in their actual home location.
  • Off-Hours Activity: Bursts of authentication prompts sent outside of standard working hours.

Defensive Recommendations

Security operations teams use practical configuration controls to mitigate MFA bypass techniques:

  1. Implement Number Matching: Instead of a simple “Approve/Deny” button, push notifications display a double-digit number on the web login screen. The user must type that specific number into their mobile phone app to complete authentication. This stops prompt bombing because an attacker cannot see the number displayed on the victim’s web browser.
  2. Enforce FIDO2 Security Keys for High-Risk Users: Enrolling high-privilege accounts (such as system administrators) in hardware token programs prevents Adversary-in-the-Middle phishing.
  3. Restrict Telemetry Blind Spots: Ensure secondary factor failures and rejections are logged and alerted on, not just successfully completed logins.
  4. Conditional Access Policies: Require devices to be corporate-managed or located within trusted network ranges before accepting MFA responses.

Key Takeaways

Multi-Factor Authentication remains one of the most effective security controls available, but it is not absolute. Attackers continue to adapt by targeting human factors through fatigue attacks and technical proxies like AiTM phishing.

Defenders must view MFA as one part of a defense-in-depth strategy: enforcing phishing-resistant methods like number matching or FIDO2 keys where possible, while actively monitoring authentication logs for abnormal verification patterns.