Phishing-Resistant MFA: FIDO2 and Passkey Deployment at Scale

TOTP shared secrets are phishable by definition: anything the user can type into a real site can be typed into a fake one. Push-based MFA adds a usability problem (push fatigue, documented in the Uber 2022 breach) and still loses to AiTM because the push approval grants a session cookie that the proxy harvests. Number matching, introduced in Microsoft Authenticator in 2023, mitigates fatigue but does nothing against evilginx; the user types the number into the real Microsoft Authenticator app while the attacker's proxy holds the corresponding session. Voice call and SMS are out of scope; SS7 interception and SIM swap have been weaponized since at least 2017. The only categories that resist AiTM are platform authenticators bound to a device (Windows Hello for Business, Apple platform passkeys, ChromeOS device-bound), roaming FIDO2 authenticators (YubiKey, Feitian, Token2), and certificate-based authentication tied to a TPM. Treat anything else as a stepping stone. Set a hard deadline (12 to 18 months) after which all interactive sign-in must use one of these factors and write the deadline into your identity policy now so procurement and HR can plan around it.

YubiKey 5 series (5C NFC, 5Ci, 5 Nano) supports FIDO2, PIV smartcard, OATH-TOTP, OpenPGP, and static password. The multi-protocol support is useful if you also need smartcard logon for legacy Windows or PIV for federal contracts, but it costs roughly $50 to $75 per token. FIDO2-only keys from Token2 (i3-PIN-Plus, around $20) or Feitian (BioPass, around $40) are sufficient for pure WebAuthn use cases and let you afford two tokens per user (primary plus backup), which is the only sane operational model. For users with managed devices, platform passkeys are essentially free: Windows Hello for Business backed by TPM 2.0, Apple platform passkeys synced through iCloud Keychain (or device-bound via managed Apple ID with Advanced Data Protection considerations), and Android device-bound passkeys via Google Password Manager. Mix the inventory: hardware keys for admins, contractors without managed endpoints, and break-glass; platform passkeys for the general workforce. Order keys with the firmware version that supports FIDO2 CTAP 2.1 minimum, which is required for enterprise attestation in Entra ID.

In Entra ID, navigate to Protection > Authentication methods > Policies and enable Passkey (FIDO2). Set Enforce attestation to Yes if you want to restrict to a known AAGUID list (collect the AAGUIDs of your purchased keys; Yubico publishes theirs at yubico.com/support/aaguids). Set Enforce key restrictions to Yes and paste the allowed AAGUIDs. Disable Self-service registration for non-pilot users initially and use Temporary Access Pass (TAP) to bootstrap registration; TAP is a time-limited single-use code that you generate via the admin portal or the Microsoft Graph API endpoint /users/{id}/authentication/temporaryAccessPassMethods. In Okta, go to Security > Authenticators and add WebAuthn; under FastPass, enable device-bound enrollment and require Touch ID or Windows Hello at the device level. Create an Authentication Policy that requires Possession factor: Hardware protected and User presence for all admin app assignments. For both IdPs, disable security questions and SMS as recovery factors; replace recovery with a helpdesk-issued TAP or Okta Verify push to a previously enrolled device with a 24 hour validity.

Legacy auth protocols (SMTP AUTH, IMAP, POP3, MAPI over HTTP with basic auth, ActiveSync with basic auth, legacy SharePoint, legacy Skype for Business) do not support modern auth and therefore cannot enforce MFA at all. In Entra ID, run the sign-in log query: SigninLogs | where ClientAppUsed in ('Other clients','IMAP4','POP3','SMTP','Exchange ActiveSync','Authenticated SMTP') | summarize count() by UserPrincipalName, ClientAppUsed, AppDisplayName for the last 30 days. Expect surprises: scan-to-email multifunction printers, Salesforce data loader connectors, custom Python scripts, line-of-business apps with embedded credentials. Build a remediation backlog by service owner with a 90 day deadline. For each, the fix is one of: migrate to OAuth2 with a service principal and certificate auth, move to Microsoft Graph with application permissions, or retire. Once the backlog is below 5% of identified accounts, set the Conditional Access policy: Users = All, Cloud apps = All, Client apps = Other clients, Grant = Block. Stage the rollout by department and use report-only mode for two weeks before enforcement. Disable SMTP AUTH at the mailbox level with Set-CASMailbox -SmtpClientAuthenticationDisabled $true.

Sequence the deployment in five waves. Wave 1: Global Admins, Privileged Role Administrators, and break-glass accounts. Issue two hardware keys per admin (stored in separate physical locations), enforce FIDO2 in Conditional Access for the AzureAD/Microsoft Admin Portals app group, and document recovery for the break-glass accounts (two keys in two safes, monitored for sign-in events). Wave 2: Tier 0 service operators (AD admins, identity engineers, security operations). Wave 3: developers and engineers with production access. Wave 4: finance, legal, and executives (high-value BEC targets). Wave 5: general workforce. For each wave, run a two-week enrollment window with TAP-based self-service, then flip the Conditional Access policy from report-only to enforce. Build an exception process for users who legitimately cannot use FIDO2: shared workstations in manufacturing, kiosks, accessibility constraints. Document the compensating control (typically certificate-based auth via TPM with strict device compliance) and review exceptions quarterly. Keep the exception list under 2% of the workforce; if it grows beyond that, the problem is process, not technology.

Attackers who cannot phish through FIDO2 will try to enroll their own authenticator on a compromised account, or downgrade the user to a weaker factor. In Entra ID sign-in logs, hunt for AuthenticationDetails containing authenticationMethod = 'Password' followed within minutes by a successful authenticationMethod = 'Mobile app notification' from a previously unseen device. Build a Sentinel analytics rule on AuditLogs for OperationName in ('Update user', 'User registered security info', 'Admin reset user password') where the actor is the user themselves and the IP is foreign or anonymizer. Alert on any Conditional Access policy modification (OperationName = 'Update conditional access policy') outside of change windows. Monitor the StrongAuthenticationMethods attribute via Microsoft Graph for users where the method count drops; legitimate users add factors, attackers remove them. In Okta, watch System Log events user.authenticator.update and user.mfa.factor.deactivate with a query in the Okta Workflows or a Splunk Okta TA. Pipe all of this into your SIEM with a 12 month retention floor; BEC investigations routinely look back 6 to 9 months for initial access.