MFA Types, FIDO2, and Phishing-Resistant Authentication

Why MFA exists

Passwords alone are a failed security model. Not because they're a bad idea in principle, but because of how people actually use them: reused across dozens of services, discovered in data breaches, guessed through credential stuffing, phished through convincing fake login pages. The credential breach pipeline is industrial in scale. Billions of username/password combinations are actively traded, and automated tools test them against every major service continuously.

Multi-factor authentication adds a second requirement beyond the password — something that changes, something physically in your possession, or something tied to your biometrics. The idea is that a stolen password alone is no longer sufficient. The attacker also needs the second factor.

That idea is sound. But not all implementations of it provide equal protection. The differences between MFA types matter significantly more than most people realize.

The three authentication factors

Authentication factors fall into three categories:

Something you know — a password, a PIN, a security question answer. Anything memorized.

Something you have — a physical device, a cryptographic key, a phone receiving a code. Anything in your possession.

Something you are — biometrics. A fingerprint, a face scan, a retinal pattern.

MFA means combining at least two of these. Most implementations combine something you know (a password) with something you have (a phone or hardware key). The second factor is the variable — and that is where the real security differences live.

SMS codes

How it works: when you log in, the service generates a random six-digit code and texts it to your registered phone number. You enter the code to complete authentication. The assumption is that only you have access to your phone number.

The problem is that assumption is fragile in several distinct ways.

SIM swapping is the most common attack. An attacker calls your mobile carrier, impersonates you using personal information gathered from data breaches or social media, and convinces the carrier to transfer your phone number to a SIM card they control. Your phone loses service. Their phone starts receiving your calls and texts — including your authentication codes.

This is not theoretical. Twitter's CEO Jack Dorsey had his account compromised via SIM swap in 2019. Thousands of Coinbase customers lost funds when attackers bypassed SMS 2FA through the same method. Cryptocurrency exchanges have been targeted repeatedly because the financial reward justifies the social engineering effort.

SS7 vulnerabilities affect the 40-year-old Signaling System No. 7 protocol that telecom networks use to coordinate call and message routing. Attackers with access to the SS7 network — nation-state actors and sophisticated criminal groups — can redirect SMS messages without touching the carrier. The subscriber never knows.

Real-time phishing is the third failure mode, and it applies to SMS and several other MFA types. An attacker builds a convincing fake login page. The victim enters their credentials. The attacker's server immediately replays those credentials to the real site. The real site sends an SMS code to the victim's phone. The fake site asks the victim to enter the code. The victim enters it. The attacker relays it within seconds. Authentication succeeds.

SMS MFA stops attackers who have your password but not your phone. It does not stop SIM swappers, SS7 attackers, or anyone running a real-time phishing relay. NIST deprecated SMS-based OTP as a primary authentication mechanism in their SP 800-63B guidelines. Use it only as a last-resort fallback when better options are unavailable.

TOTP: time-based one-time passwords

TOTP (defined in RFC 6238) is the MFA type behind Google Authenticator, Authy, 1Password codes, and most authenticator apps.

How it works: when you enable TOTP on a service, you scan a QR code that encodes a shared secret known to both the service and your authenticator app. From that point, both your app and the service's server independently compute the same six-digit code using a formula that combines the shared secret with the current timestamp divided into 30-second windows. Because they both know the secret and both know the time, they arrive at the same code independently without any communication. The code changes every 30 seconds, and most services allow a 90-second grace window for clock drift.

What TOTP fixes: SIM swapping does not work because your codes are not flowing through the telecom network. SS7 attacks do not work for the same reason. The shared secret lives in your authenticator app. This is a meaningful upgrade from SMS.

What TOTP does not fix: real-time phishing. The same relay attack that works against SMS codes works against TOTP codes. Your 30-second window is more than enough time for an automated relay to pass the code from the fake site to the real site. The technical term is AiTM — Adversary-in-the-Middle. Phishing toolkits specifically designed to defeat TOTP in real time (Evilginx2, Modlishka, and others) are openly documented and widely used. TOTP is substantially better than SMS. It is not phishing-resistant.

The authenticator apps

Google Authenticator

The most widely recognized TOTP app. It works correctly and requires no account. The original limitation was significant: secrets were stored only on the device with no backup. Lose your phone, lose every TOTP code you had set up, with no recovery path except calling each service individually.

Google added optional cloud sync in 2023. The implementation drew criticism from security researchers: secrets were initially transmitted without end-to-end encryption, meaning they were readable to Google's infrastructure. Google has since added E2E encrypted sync as an option, but the default remains unencrypted unless you opt in. For personal use, Google Authenticator is adequate. For enterprise contexts or high-value accounts, there are better options.

1Password

1Password handles TOTP as one of its stored item types, alongside usernames and passwords. Two things make it meaningfully better than a standalone authenticator app.

First, integration. 1Password fills your TOTP code automatically alongside your password in the same autofill action. You do not switch apps, read a code off your phone screen, and type it manually. The code appears in the browser extension in the same moment as the password. For users, this removes the friction that causes people to disable or bypass MFA.

Second, storage. Your TOTP secrets are end-to-end encrypted, backed up, and synced across all your devices. Lose a phone, lose nothing. Get a new device, instant setup.

The theoretical objection — that storing TOTP in the same vault as your password technically reduces from two factors to one — is valid in principle. In practice, a 1Password user with TOTP enabled is substantially more secure than one who abandons MFA because the friction is too high. 1Password also stores passkeys natively, making it the most practical cross-platform passkey manager currently available.

Microsoft Authenticator

The natural choice for Microsoft-centric organizations. It handles TOTP for any compatible service, but its primary value is as the push notification and passwordless authentication method for Microsoft Entra ID.

Its key security feature: number matching. When a push notification is sent, the login screen displays a two-digit number the user must enter into the Authenticator app before approving. This nearly eliminates push bombing attacks — more on why in the next section. Microsoft Authenticator also supports passkey authentication and passwordless phone sign-in for Entra ID. If your organization runs Microsoft 365, this app is standard issue.

Okta Verify

The enterprise equivalent of Microsoft Authenticator for Okta-centric organizations. Push notifications with rich context — the service, device, and location of the login attempt — TOTP generation, and Okta FastPass, a passwordless mechanism using a device-bound cryptographic key.

Okta Verify integrates with Okta's device trust signals: the app can attest whether the device is enrolled in MDM, meets minimum OS version requirements, and has disk encryption enabled. Okta's conditional access policies can require these signals before granting authentication. If your identity provider is Okta, Okta Verify is the companion app to deploy.

JumpCloud Protect

JumpCloud's authenticator app for JumpCloud-managed accounts. Push notification approval, TOTP generation, and integration with JumpCloud's conditional access and device trust infrastructure. Everything surfaces in the same admin console, the same user lifecycle workflows, and the same device trust policies you're already managing. If your directory is JumpCloud, JumpCloud Protect is the natural companion — and the standard configuration RSystems implements for JumpCloud clients.

Push notifications: better UX, new attack surface

Push-based MFA replaces code-typing entirely. You attempt to log in, the service sends a push notification to the registered app on your phone, you tap Approve or Deny, and authentication completes or fails.

What push fixes: no code to type means no code to steal. An AiTM phishing relay can capture your username and password but cannot intercept a push notification sent to your phone. The notification includes contextual information — the service requesting access, your IP location, the device — that helps you detect suspicious requests.

What push introduces: MFA fatigue attacks, also called push bombing. The technique is simple. The attacker has your credentials. They attempt to log in repeatedly, generating a continuous stream of push notifications to your phone. Users receiving unexpected authentication requests will often eventually approve one to make it stop — especially late at night, or if they assume it is a technical glitch.

In 2022, Uber was compromised via exactly this method. The attacker had an employee's credentials, sent push notifications repeatedly, then sent a WhatsApp message pretending to be Uber IT, explained the requests were legitimate, and asked the employee to approve. The employee approved. The attacker was in.

Number matching is the primary mitigation. The login screen displays a two-digit number the user must enter into the authenticator app before approval is granted. An attacker triggering push notifications cannot know what number appears on the legitimate login screen. A user receiving an unsolicited push with a number field and no corresponding number on their screen knows immediately something is wrong. CISA specifically recommends number matching as a requirement for all push-based MFA deployments.

Push MFA with number matching is meaningfully more secure than TOTP. It is not phishing-resistant in all scenarios, but it raises attack complexity significantly.

FIDO2, WebAuthn, and hardware keys

FIDO2 is the authentication standard that achieves something the previous methods cannot: cryptographic phishing resistance. Not improved resistance. Structural impossibility.

How it works: when you register a FIDO2 credential with a service, your authenticator — a hardware key or your device's secure enclave — generates a public/private key pair specifically for that service's domain. The public key is sent to and stored by the service. The private key never leaves your authenticator. It is generated on the hardware and cannot be exported.

When you authenticate, the service sends a cryptographic challenge. Your authenticator signs it with the private key tied to that specific domain. The service verifies the signature against the stored public key. Authentication succeeds.

Why phishing cannot work: the key pair is bound to the specific origin at the cryptographic level. A FIDO2 credential registered for accounts.google.com will not sign a challenge from accounts.go0gle.com. The authenticator checks the exact domain. This is not a UI warning the user might dismiss. It is a cryptographic operation that fails if the domain does not match. There is no user decision, and therefore no user error.

After Google required hardware security keys for all employees in 2017, they had zero successful phishing-based account compromises across their workforce. Not reduced — zero. The architecture does not permit it.

YubiKey is the most widely deployed FIDO2 hardware authenticator. A small USB or NFC device, a YubiKey stores credentials on secure hardware. Tap it to a USB port or to an NFC reader on your phone and authentication completes. The private keys generated on a YubiKey cannot be extracted from the hardware — even if someone takes the physical key, the credentials inside are not readable. YubiKeys are the appropriate choice for privileged accounts and high-security requirements.

Passkeys: FIDO2 for everyone

Passkeys are FIDO2 credentials that live in software rather than dedicated hardware — specifically, in your device's secure enclave (Apple's Secure Enclave, Android's StrongBox, Windows Hello's TPM) or a credential manager like 1Password.

The cryptographic mechanism is identical to a hardware key. The difference is portability and usability.

A passkey stored in iCloud Keychain is available across all your Apple devices. A passkey stored in 1Password is available on every device where you use 1Password — Mac, Windows, iOS, Android — regardless of platform. This matters because native platform passkey implementations are platform-locked: iCloud Keychain passkeys do not work on Windows, and Google Password Manager passkeys do not work on iOS. 1Password passkeys work everywhere 1Password works, making it the most practical path to broad passkey adoption in mixed device environments.

Device-bound vs. synced passkeys: a passkey on a hardware key exists only on that physical device. A passkey in iCloud Keychain exists across all your Apple devices. Synced passkeys trade a degree of isolation for significant usability. Whether synced passkeys in E2E encrypted storage meet your organization's requirements is worth evaluating explicitly.

The user experience: you never create, remember, or type a password for a passkey-protected service. Authentication is a biometric confirmation — Face ID, Touch ID, Windows Hello — and you are in. Phishing-resistant by design. Simpler than a password. Better security and better UX simultaneously. This is why every major platform and most major services are actively adopting passkeys.

The security hierarchy

Weakest to strongest, and why:

SMS codes — stops naive credential stuffing. Vulnerable to SIM swap, SS7, and real-time phishing. Use only as fallback.

TOTP authenticator codes — removes telecom attack surface. Still vulnerable to AiTM phishing. Correct choice when FIDO2 is unavailable.

Push notifications without number matching — better UX, same phishing vulnerability plus push bombing risk. Insufficient without number matching.

Push notifications with number matching — substantially mitigates push bombing. Still not cryptographically phishing-resistant but raises attack complexity significantly.

FIDO2 hardware keys — phishing-resistant by design. Correct for privileged accounts, administrators, and executives. Requires physical device management.

Passkeys — same cryptographic guarantee as hardware keys, better usability, platform-synced. The emerging standard for all accounts.

Why phishing-resistant is becoming the requirement

The most sophisticated attacks today specifically target MFA. Evilginx2, one of the most documented AiTM frameworks, is openly available and designed to relay TOTP codes and session tokens in real time. The baseline attack — credentials plus TOTP code via phishing relay, then session token theft — bypasses SMS and TOTP completely. The session persists even after the code expires.

The US government's response has been explicit. CISA's binding operational directive specifies that SMS and TOTP are no longer considered sufficient for federal systems and that phishing-resistant MFA is the required standard for privileged access. Enterprise cyber insurance applications increasingly ask which MFA types are deployed and whether phishing-resistant authentication is enforced. The industry is moving in this direction not because of principle but because non-phishing-resistant MFA is failing at scale.

The practical roadmap for most organizations:

Ensure MFA is required for all accounts — any MFA is substantially better than none. Move from SMS to TOTP or push-based MFA. Require number matching on all push deployments. Deploy passkeys or hardware keys for privileged access, administrators, and executives. Adopt passkeys as the standard for all users as platform support matures — which it is doing rapidly.

1Password, JumpCloud, Microsoft, Okta, and Google all support passkeys today. The path exists, the tooling exists, and the attacks against weaker methods are only becoming more automated and accessible. The question is when to require phishing-resistant authentication, not whether it is viable.