Phishing-Resistant MFA: FIDO2, Passkeys, and Hardware Keys

Multi-factor authentication has long been the most impactful security control an organization can deploy. But not all MFA is created equal. The 2022 Twilio breach, the Uber hack, and the MGM Resorts intrusion all demonstrated that SMS OTPs and authenticator app codes can be bypassed through real-time phishing attacks — a technique attackers have operationalized at scale.

Phishing-resistant MFA eliminates this vulnerability by cryptographically binding the authentication to the origin — the specific website or application being authenticated. A credential that works on bank.com cannot be replayed on bank-login-secure.com, regardless of how convincing the phishing site looks.

Why Traditional MFA Fails Against Phishing

SMS OTP (One-Time Password):

The attack is straightforward. The attacker:

1. Sets up a phishing page that proxies the real site
2. Victim enters their username and password on the phishing site
3. Attacker's proxy submits the credentials to the real site in real time
4. Real site sends an SMS OTP to the victim's phone
5. Phishing site asks the victim to enter the OTP
6. Victim enters the OTP; attacker's proxy submits it before it expires
7. Attacker is now logged in

This is an Adversary-in-the-Middle (AiTM) attack. The timing window is a few seconds — automated toolkits like Evilginx2 make this trivial.

TOTP (Time-Based OTP — Google Authenticator, Authy):

Same attack applies. The 30-second TOTP window is sufficient for a real-time proxy. Additionally, TOTP seeds can be phished directly if users are tricked into entering their setup QR codes.

SMS has additional weaknesses:

• SIM swapping — attacker convinces carrier to transfer victim's number
• SS7 attacks — telecommunications network vulnerabilities allow call/SMS interception
• Voicemail-to-text — OTPs delivered to voicemail can be accessed if voicemail is unsecured

FIDO2 and WebAuthn: The Technical Foundation

FIDO2 is an authentication standard developed by the FIDO Alliance and W3C. It consists of two specifications:

• WebAuthn (Web Authentication) — Browser API for authenticating using public key cryptography
• CTAP2 (Client-to-Authenticator Protocol) — Protocol for communicating between browser/OS and an authenticator (hardware key, platform authenticator)

How it provides phishing resistance:

During registration, the authenticator generates a credential — a public-private key pair — bound to the Relying Party ID (the origin: login.example.com).

During authentication:

1. The server sends a challenge
2. The browser signs the challenge using the credential's private key
3. The signature includes the origin — the actual URL in the browser bar
4. The server verifies the signature and checks the origin matches the registered RP ID

If the user is on login.evil.com (even if it looks identical to login.example.com), the authentication will fail because the origin does not match login.example.com. The phishing site cannot proxy a valid FIDO2 authentication — the binding is cryptographic.

Passkeys: FIDO2 for Everyone

Passkeys are FIDO2 credentials stored in the user's platform (iCloud Keychain, Google Password Manager, Windows Hello) and synced across devices.

Advantages over hardware keys:

• No hardware to carry, lose, or buy
• Automatic backup and recovery via cloud sync
• Fingerprint/face recognition as the user verification method
• Consistent experience across devices

Disadvantages compared to hardware keys:

• Dependent on cloud sync (if iCloud is compromised, so are all passkeys)
• Not suitable for the highest-security scenarios (government, financial institution employees)
• Recovery procedures are cloud-provider-specific

Implementation with WebAuthn (server-side):

import { generateRegistrationOptions, verifyRegistrationResponse,
         generateAuthenticationOptions, verifyAuthenticationResponse } from '@simplewebauthn/server';

// Registration
const registrationOptions = await generateRegistrationOptions({
  rpName: 'My App',
  rpID: 'myapp.com',
  userID: user.id,
  userName: user.email,
  attestationType: 'none',
  authenticatorSelection: {
    residentKey: 'required',    // Discoverable credential (passkey)
    userVerification: 'required' // Biometric or PIN required
  }
});

// Store challenge in session
session.currentChallenge = registrationOptions.challenge;

// After browser completes registration gesture:
const verification = await verifyRegistrationResponse({
  response: registrationResponse,
  expectedChallenge: session.currentChallenge,
  expectedOrigin: 'https://myapp.com',
  expectedRPID: 'myapp.com',
  requireUserVerification: true
});

if (verification.verified) {
  // Store verification.registrationInfo.credential in database
}

Client-side (browser):

import { startRegistration, startAuthentication } from '@simplewebauthn/browser';

// Registration
const attResp = await startRegistration(registrationOptionsFromServer);
await sendToServer('/api/auth/register', attResp);

// Authentication (passwordless)
const authResp = await startAuthentication(authOptionsFromServer);
await sendToServer('/api/auth/login', authResp);

Hardware Security Keys

Hardware security keys (YubiKey, Google Titan Key, FEITIAN) store FIDO2 credentials on a tamper-resistant physical device. Private keys never leave the device.

When hardware keys are necessary:

• Highly privileged accounts (system administrators, executives, finance team)
• Employees in high-risk roles (legal, HR with sensitive data)
• Regulatory environments requiring hardware-backed credentials (FIPS 140-2)
• Service accounts and CI/CD systems (non-human actors)

YubiKey form factors:

• USB-A/USB-C — Plug in and tap to authenticate
• NFC — Tap phone to YubiKey for mobile authentication
• Lightning — iOS-compatible (less common now with USB-C iPhones)

YubiKey beyond FIDO2:

YubiKeys also support:

• PIV (smart card) — For certificate-based authentication
• OpenPGP — Email signing and encryption
• TOTP — For legacy apps that do not support FIDO2 yet
• Static passwords — For systems with no other MFA support

Deployment logistics:

• Issue 2 keys per employee (primary + backup). Losing the only hardware key is a lockout.
• Register backup keys before issuing primary — do not wait for a lockout to discover the backup key process does not work.
• Store one backup key in a secure off-site location for each privileged account.

Migration Path to Phishing-Resistant MFA

Most organizations start with TOTP and need to migrate to FIDO2. A practical migration approach:

Phase 1 — Enable FIDO2 alongside existing MFA (Month 1-2)

• Add FIDO2 as a supported MFA method in your IdP (Okta, Entra ID, Duo)
• Allow users to enroll passkeys or hardware keys voluntarily
• Communicate the security benefits and demonstrate the user experience

Phase 2 — Require FIDO2 for privileged accounts (Month 3)

• Mandate phishing-resistant MFA for admin, finance, and executive roles
• Issue hardware keys to privileged users
• Remove TOTP and SMS as options for these accounts

Phase 3 — Migrate all employees (Month 4-6)

• Set a migration deadline
• Provide self-service passkey enrollment via IT portal
• Issue hardware keys to employees who lack compatible devices
• After deadline, disable SMS and TOTP

Phase 4 — Enforce via policy (Month 7+)

• Configure Conditional Access policies (Entra ID) or Sign-On Policies (Okta) to require phishing-resistant MFA for all application access
• Block access from devices without a registered passkey or hardware key

Identity Provider Support

• Entra ID — Passkeys in Authenticator app (GA), FIDO2 security keys (GA), Temporary Access Pass for bootstrap
• Okta — FIDO2/WebAuthn supported, FastPass for Okta-managed apps
• Google Workspace — Security Key enforcement (hardware key or passkey), Titan Key program
• Duo — WebAuthn/FIDO2 supported, hardware key enrollment via Duo Dashboard

The most dangerous authentication configuration is SMS-only MFA on privileged accounts in 2026. If that describes your environment, migrating to passkeys or hardware keys is the single highest-ROI security investment available.