Under the Hood: Why MFA Still Fails — and How It Actually Works

The Uncomfortable Truth About Business Security

Multi-Factor Authentication (MFA) is not a new concept. Banks have been using it since the early 2000s. Security professionals have championed it for years. Regulatory frameworks across industries — from HIPAA to PCI-DSS — have increasingly mandated it. And yet, according to Microsoft's 2023 Digital Defense Report, over 99% of compromised accounts did not have MFA enabled.

Read that again.

Despite being one of the simplest, most cost-effective security measures available, MFA remains widely unadopted. The question isn't whether businesses know about MFA. Most do. The real question is: why aren't they using it?

What Is MFA, and Why Does It Matter?

At its core, Multi-Factor Authentication requires users to verify their identity using two or more independent factors before gaining access to a system. These factors fall into three categories:

• Something you know — a password or PIN
• Something you have — a phone, hardware token, or smart card
• Something you are — biometrics like a fingerprint or facial recognition

The logic is straightforward: even if a cybercriminal steals your password, they still can't access your account without the second factor. According to Google's own research, MFA blocks 100% of automated bot attacks, 99% of bulk phishing attacks, and 66% of targeted attacks.

The technology works. The adoption doesn't.

How MFA Actually Works — A Technical Deep Dive

For the engineers and security professionals reading this, understanding the cryptographic and protocol-level mechanics of MFA is essential for making informed implementation decisions. Not all MFA is created equal, and the differences matter enormously from a security standpoint.

TOTP — Time-Based One-Time Passwords (RFC 6238)

The most widely deployed software MFA method is TOTP, used by Google Authenticator, Microsoft Authenticator, Authy, and most enterprise SSO platforms. Here's how it works at the protocol level:

Shared Secret Provisioning

During setup, the server generates a cryptographically random shared secret — typically 160 bits — and transmits it to the authenticator app, usually via a QR code. This secret is stored on both the server and the device, and it never travels across the network again after initial setup.

OTP Generation

Every 30 seconds, both the server and the authenticator app independently compute:

TOTP = TRUNCATE(HMAC-SHA1(secret, floor(unix_time / 30)))

The HMAC-SHA1 operation produces a 20-byte hash. Truncation extracts a 4-byte dynamic binary code from a specific offset within that hash (determined by the last nibble), which is then reduced to a 6-digit decimal number via modulo 10^6.

Because both parties share the same secret and use the same Unix timestamp window, they derive the same code without ever communicating it. This is why TOTP codes work even in airplane mode.

Replay Attack Mitigation

Servers maintain a short time-step tolerance window (typically ±1 step, or ±30 seconds) to account for clock drift. They also maintain a used-code cache per user to invalidate replayed tokens within the same window.

Security limitation worth noting: TOTP is vulnerable to real-time phishing attacks. An attacker who tricks a user into entering their code on a fake login page can relay it to the real server within the same 30-second window. This is why TOTP, while significantly better than passwords alone, is not phishing-resistant.

HOTP — HMAC-Based OTP (RFC 4226)

HOTP is the counter-based predecessor to TOTP. Instead of a timestamp, it uses an incrementing counter:

HOTP = TRUNCATE(HMAC-SHA1(secret, counter))

The counter increments on each authentication attempt. Hardware tokens like RSA SecurID tokens traditionally used this model. The challenge with HOTP is counter synchronization — if a user generates codes without authenticating, the server and device counters can drift, requiring resync mechanisms.

TOTP superseded HOTP for most use cases because timestamp-based sync is more predictable, but HOTP remains common in offline hardware token environments.

FIDO2 / WebAuthn — The Phishing-Resistant Standard

FIDO2 (Fast Identity Online 2) is the current gold standard for MFA and the only approach that is fully phishing-resistant by design. It is a W3C/FIDO Alliance specification combining two components: the WebAuthn API (browser/platform-facing) and CTAP2 (Client-to-Authenticator Protocol, for communicating with hardware keys).

How the authentication flow works:

Registration Phase:

1. The server sends a cryptographic challenge to the browser.
2. The browser calls navigator.credentials.create() with the challenge and relying party (RP) origin.
3. The authenticator (e.g., YubiKey, platform TPM, Face ID) generates a public/private key pair scoped to the RP origin.
4. The private key never leaves the authenticator — ever. The public key is sent back to the server and stored.

Authentication Phase:

1. The server sends a new random challenge.
2. The browser calls navigator.credentials.get().
3. The authenticator signs the challenge (plus client data including the RP origin) with the stored private key.
4. The server verifies the signature using the stored public key.

Why this is phishing-resistant: The RP origin (rpId) is cryptographically bound to the signed assertion. If a user is tricked into authenticating on yourbank-login.evil.com instead of yourbank.com, the signature will be generated for the wrong origin and the server will reject it. The attacker cannot relay a valid assertion from a phishing site because the origin check is built into the cryptographic proof itself.

Authenticator types:

• Roaming authenticators — Hardware keys like YubiKey 5, Google Titan Key (CTAP2 over USB/NFC/BLE)
• Platform authenticators — Built-in TPM chips, Touch ID, Windows Hello, Face ID (device-bound, non-exportable private keys)
• Passkeys — A synced FIDO2 credential stored in a platform keychain (iCloud Keychain, Google Password Manager), offering phishing resistance with cross-device convenience

SMS OTP — Why It's the Weakest Link

SMS-based OTP is technically MFA, but it is the least secure method and is increasingly being deprecated in high-security environments. The attack surface is significant:

• SIM Swapping — An attacker social-engineers a mobile carrier into porting the victim's phone number to a SIM they control. Once successful, all SMS OTPs are redirected to the attacker. This attack has been used to compromise crypto exchange accounts, executive email accounts, and even software engineers at major tech firms.
• SS7 Protocol Vulnerabilities — The Signaling System 7 protocol that underpins global telecommunications was designed in the 1970s with no authentication. Researchers and nation-state actors with SS7 access can intercept SMS messages in transit by exploiting these legacy weaknesses — no device access required.
• Malware interception — Android malware can read incoming SMS messages and forward OTPs to an attacker silently.
• Real-time phishing relay — Because SMS OTPs are entered manually, a phishing site can relay the code to the real server within the validity window.

NIST SP 800-63B deprecated SMS as an authentication method for federal use cases in 2017. If your organization is still defaulting to SMS OTP, it's worth having the architectural conversation about upgrading.

Push Notification MFA — Convenience vs. MFA Fatigue

Push-based MFA (used by Duo, Okta Verify, Microsoft Authenticator) sends an "Approve/Deny" notification to a registered device. It is more user-friendly than TOTP and significantly better than SMS, but introduces a specific attack vector: MFA fatigue (also called MFA prompt bombing).

This attack works by flooding a user with repeated push notifications — sometimes dozens in a row — until the user approves one just to make it stop. This technique was used in the high-profile Uber breach of 2022, where an attacker obtained an employee's credentials, spammed them with push notifications at 1AM, then reached out via WhatsApp claiming to be IT support, convincing the employee to approve the login.

Mitigations against MFA fatigue:

• Number matching — The user must type a number displayed on the login screen into the push notification, not just tap Approve. This is now default in Microsoft Authenticator.
• Additional context — Displaying the requesting IP, geographic location, and application name in the push notification so users can spot anomalies.
• Rate limiting — Locking accounts or requiring step-up authentication after N consecutive push denials.

Hardware Security Keys — The Gold Standard for Privileged Access

For privileged accounts, service accounts, and high-value targets (executives, DevOps engineers, finance teams), hardware security keys implementing FIDO2/WebAuthn offer the strongest available protection:

• YubiKey 5 Series — Supports FIDO2, TOTP, PIV (smart card), OpenPGP, and OATH. Widely considered the enterprise standard.
• Google Titan Key — FIDO2-only, simpler, tightly integrated with Google Workspace.
• Feitian ePass — A cost-effective alternative, FIDO2-certified.

The private key is generated and stored inside a tamper-resistant secure element on the hardware. It cannot be extracted, exported, or cloned — even if the physical key is stolen. Authentication requires physical possession plus user presence (touch) and optionally user verification (PIN).

PKI / Smart Card Authentication

For enterprise environments with existing Active Directory infrastructure, smart card / certificate-based authentication is a mature and highly secure approach. Users authenticate with an X.509 certificate stored on a physical card or in a TPM:

1. The server presents a challenge.
2. The client signs it with the private key inside the card/TPM.
3. The server validates the signature against the public key in the certificate chain.

This is functionally similar to FIDO2 but uses a PKI trust model rather than the FIDO Alliance's. Common in government, defense, and large financial institutions. Microsoft's Windows Hello for Business leverages this model backed by the device TPM.

Common MFA Bypass Techniques Attackers Use

Understanding how MFA gets bypassed is just as important as understanding how it works. The goal of a sophisticated attacker is not to break the cryptography — it's to sidestep the authentication flow entirely.

Adversary-in-the-Middle (AiTM) Phishing: Tools like Evilginx2 and Modlishka act as reverse proxies between the victim and the real website. The victim authenticates for real (including MFA), while the proxy captures the authenticated session cookie. The attacker then uses that cookie directly, bypassing MFA entirely because authentication has already occurred. Microsoft Sentinel and similar SIEM tools can detect AiTM attacks via anomalous session token usage patterns.

Session Cookie Theft / Pass-the-Cookie: Post-authentication session tokens stored in browser cookies are high-value targets. Infostealer malware (Redline, Raccoon Stealer) specifically targets browser credential stores and cookie databases. Once an attacker has a valid session cookie, they can replay it from their own machine — no MFA required.

OAuth/OIDC Consent Phishing: Attackers register a malicious OAuth app and trick users into granting it access to their accounts. Because the user is authenticating through a legitimate identity provider (Microsoft, Google), MFA is satisfied — but the attacker ends up with persistent delegated access via OAuth tokens. This was the vector used in the 2022 Lapsus$ attacks on Microsoft and Okta.

MFA Bypass via Legacy Protocols: Many organizations enable MFA on their primary authentication flows but forget about legacy protocols — SMTP AUTH, IMAP, POP3, and older Exchange Web Services (EWS) endpoints — that don't support modern authentication and will accept just a username and password. Disabling legacy authentication protocols is a critical configuration step that is frequently missed.

Protocol Standards and the Broader Identity Ecosystem

MFA doesn't operate in isolation — it lives within a broader identity and access management (IAM) architecture:

SAML 2.0 (Security Assertion Markup Language): An XML-based federation standard widely used in enterprise SSO. The Identity Provider (IdP) — e.g., Okta, ADFS — performs authentication including MFA, then issues a signed XML assertion to the Service Provider (SP). The SP trusts the assertion without re-authenticating the user.

OpenID Connect (OIDC) / OAuth 2.0: The modern, JSON/JWT-based successor to SAML for web and mobile applications. OIDC adds an identity layer on top of OAuth 2.0, issuing ID tokens (JWTs) containing claims about the authenticated user. MFA is performed at the Authorization Server (AS) level, and downstream applications trust the resulting tokens.

SCIM (System for Cross-domain Identity Management): While not an authentication protocol, SCIM automates user provisioning and deprovisioning across systems, ensuring that when an employee leaves, their accounts are deactivated across all connected services — closing a common MFA bypass gap where orphaned accounts with weak authentication persist.

Adaptive / Risk-Based MFA — The Intelligence Layer

Modern enterprise MFA platforms go beyond static second factors. Adaptive MFA evaluates contextual signals at login time to dynamically adjust authentication requirements:

• Device trust / Device fingerprinting — Is this a managed, enrolled device? Is it compliant with MDM policies?
• IP reputation and geolocation — Is the login coming from a known corporate IP, a residential ISP, a Tor exit node, or a known malicious IP range?
• Impossible travel detection — Did the same account authenticate from New York and Singapore within a two-hour window?
• Behavioral biometrics — Typing cadence, mouse movement patterns, and scrolling behavior can be used as continuous authentication signals.
• Time-of-day and access pattern analysis — Is this user logging into the payroll system at 3AM for the first time?

If risk signals exceed a threshold, the system can require step-up authentication (additional factors), trigger an alert, or block the session outright. Microsoft Entra ID's Conditional Access, Okta's ThreatInsight, and Duo's Trusted Endpoints are implementations of this model.

5 Reasons Businesses Still Haven't Implemented MFA

1. "It Won't Happen to Us" — The False Sense of Security

Many small and mid-sized businesses operate under the assumption that they're not attractive targets for cybercriminals. This is one of the most dangerous myths in cybersecurity today.

The reality? Smaller organizations are often easier targets precisely because they have weaker defenses. The 2023 Verizon Data Breach Investigations Report found that 43% of cyberattacks target small businesses. Attackers don't discriminate based on company size — they target vulnerability.

2. The Friction Problem — User Resistance Is Real

Adding an extra login step is mildly annoying. But modern MFA has evolved dramatically. Push notifications, biometric platform authenticators (Face ID, Windows Hello), and SSO federation mean users often authenticate with MFA less frequently than they think — once per device, per session, or per day depending on policy. The clunky SMS OTP of 2012 is not the state of the art in 2024.

3. IT Complexity and Implementation Fear

For organizations without a mature IAM practice, MFA rollout can feel daunting. But the ecosystem has matured significantly. Identity providers like Okta, Microsoft Entra ID, and Ping Identity handle the heavy lifting. Federation via SAML/OIDC means MFA at the IdP level protects all downstream applications without per-app integration work.

4. Budget Constraints and Misaligned Priorities

The average cost of a data breach in 2023 was $4.45 million (IBM). Many robust MFA solutions cost $3–6 per user per month. For a 100-person company, that's $3,600–$7,200 per year versus millions in breach costs. The ROI case is not ambiguous.

5. No Internal Champion

Without a designated security owner and executive buy-in, MFA stays on the backlog indefinitely. Security is a leadership issue as much as a technical one.

The Regulatory Pressure Is Building

• CISA has listed MFA as a top security measure for all organizations.
• The SEC now requires publicly traded companies to disclose cybersecurity risk management practices.
• Cyber insurance providers are making MFA a prerequisite for coverage.
• SOC 2, ISO 27001, and HIPAA all strongly recommend or require MFA as part of access control policies.
• NIST SP 800-63B provides the authoritative technical framework for digital identity assurance levels, with Level 2 and above requiring MFA.

Implementation Considerations for Technical Teams

Prioritize phishing-resistant MFA for privileged access: FIDO2/WebAuthn for admins, DevOps, and finance teams. The incremental cost of hardware keys for 20 privileged users is negligible versus the breach risk of a compromised admin account.

Disable legacy authentication protocols immediately: In Microsoft 365, this means blocking Basic Auth via Conditional Access. In Google Workspace, disable "Less Secure App Access." Legacy protocols are the most commonly exploited MFA bypass vector.

Implement Conditional Access / Zero Trust policies: MFA should be one signal in a broader access policy engine — not a standalone gate. Combine MFA with device compliance checks, network location, and session risk scoring.

Protect service accounts differently: Service accounts can't use interactive MFA. Instead, rely on managed identities, workload identity federation, short-lived OAuth tokens, and strict IP allowlisting to protect non-human accounts.

Monitor for AiTM and session token abuse: Configure your SIEM to alert on impossible travel, token replay from new IP addresses post-authentication, and anomalous OAuth consent grants.

Test your recovery flows: Backup codes, helpdesk re-enrollment procedures, and break-glass admin accounts need to be documented and tested before you need them — not during an incident.

The Bottom Line

MFA isn't new. It isn't complicated. And it isn't expensive. What it is, however, is one of the single most effective security controls available — when implemented correctly.

The gap isn't awareness. It's execution. And for technical teams, the path forward is clear: move from SMS OTP toward FIDO2, layer in adaptive risk signals, eliminate legacy authentication endpoints, and treat MFA as one component of a Zero Trust access model — not a finish line.

The businesses that treat MFA as "good enough to check a box" will find that attackers have already mapped every bypass. The ones that understand the underlying cryptography and threat model will build something that actually holds.

Is your organization ready to move beyond basic MFA? Contact our team for a security architecture review.

‍