TL;DR

Traditional MFA — SMS OTPs, push notifications, and TOTP authenticator codes — is no longer a security control; it is a latency layer that adversary-in-the-middle (AiTM) phishing kits reliably defeat in seconds. The Tycoon 2FA, EvilProxy, and Caffeine kit families, and the OAuth 2.0 device-code phishing track exposed in Microsoft's May 4, 2026 research, collectively prove this point at scale. The only MFA that survives a proxied session hijack is FIDO2/passkey authentication, which binds credentials cryptographically to the origin server — making relay attacks physically impossible.

This playbook is the operational guide security teams need to migrate from legacy MFA to phishing-resistant passkeys in 30, 60, and 90 days without breaking productivity or creating recovery nightmares. It covers the threat model, platform-specific rollout, conditional access hardening, detection coverage during transition, and the five most common failure modes enterprises hit mid-migration.

---

Background: Why Traditional MFA Is Losing

The story of multi-factor authentication in 2026 is one of a control that was brilliant in 2012 and is now structurally outpaced by the commodity tooling available to any ransomware affiliate with a $200/month PhaaS subscription.

How AiTM works in practice. An AiTM phishing kit — EvilProxy, Evilginx3, Modlishka, or a custom variant — operates as a transparent reverse proxy between the victim's browser and the legitimate identity provider (Microsoft Entra, Google Workspace, Okta). The victim clicks a convincing lure (a shared document notification, a code-of-conduct policy notice, an IT security alert), lands on the proxy, and is relayed in real time to the actual login page. Every credential and every MFA code the victim enters is captured and replayed to the IdP on the attacker's side. The IdP returns a valid session token — the proxy captures that token too. The victim sees a successful login. The attacker now holds a live, fully authenticated session cookie that works until it expires or is revoked.

What this defeats: SMS OTP (trivially relayed). TOTP codes from authenticator apps (relayed within the 30-second window). Push notification approvals (victim approves the real prompt, adversary captures the token). Email-based OTPs. Even hardware tokens generating TOTP (the same 30-second window applies).

Device-code phishing is a parallel track that avoids the proxy architecture entirely. The attacker requests a device authorization code from the IdP, sends the user-facing URL to the victim in a phishing lure, and waits for the victim to authenticate on a legitimate IdP page. The OAuth 2.0 Device Authorization Grant flow then delivers an access token and refresh token directly to the attacker's polling client. No proxy, no SSL inspection bypass required. Microsoft tracked an active campaign using this technique in May 2026, targeting global enterprises with "code of conduct policy" lures delivering Teams messages that triggered device authorization flows.

Scale: Tycoon 2FA alone was documented targeting over 1,000 organizations in Q1 2026. The PhaaS market now offers AiTM kits with 24/7 support, Telegram-based C2, and real-time credential streaming dashboards. The barrier to running a sophisticated session-hijacking campaign is approximately equivalent to setting up a Shopify store.

What survives: Only two MFA categories are cryptographically immune to session relay:

1. FIDO2 / WebAuthn (hardware security keys like YubiKey, platform authenticators like Windows Hello / Touch ID, and cloud-synced passkeys)

2. Certificate-Based Authentication (CBA) using smart cards or device-bound certificates

FIDO2's immunity is architectural. During authentication, the FIDO2 authenticator signs a challenge that includes the relying party ID (the origin domain, e.g., login.microsoftonline.com). If the user is talking to a proxy domain (login.m1cros0ft-secure.com), the FIDO2 assertion will fail — the origin doesn't match. The attacker cannot relay a valid FIDO2 response, because they cannot forge the cryptographic binding to the legitimate domain.

---

Technical Analysis: The Three Migration Tracks

Track 1: Microsoft Entra ID + Windows Hello for Business / FIDO2 Keys

Microsoft's phishing-resistant MFA path offers two mechanisms: Windows Hello for Business (WHfB), which uses the TPM chip to store a device-bound private key, and FIDO2 security keys (Yubico, HID, Feitian, etc.) for scenarios where WHfB doesn't fit (shared devices, Linux/Mac endpoints, VDI).

Phase 1 (Days 1-30): Baseline and pilot

• Audit your Conditional Access policies. Identify every policy that accepts "any MFA" — these are your AiTM exposure surface. Tag them.
• Enable the Microsoft Entra ID Authentication Methods Policy API to get a per-user MFA method breakdown.
• Pilot WHfB on a cohort of 50-100 IT staff and power users. WHfB requires Azure AD joined or Hybrid AAD joined devices. For FIDO2 key pilot: enable Authentication Method: FIDO2 Security Key in the Entra portal, configure self-service registration.
• Enforce Phishing-Resistant MFA Strength in a Conditional Access policy scoped to the pilot group. This auth strength accepts only FIDO2, WHfB, and CBA — rejecting all TOTP/push paths.
• Run parallel coverage with existing MFA for non-pilot users.

Phase 2 (Days 31-60): Broad rollout

• Deploy WHfB via Intune for all corporate-managed Windows devices. Policy: Windows Hello for Business > Enable Windows Hello for Business = Yes, TPM Required = Yes, Use enhanced sign-in security = Enabled.
• Address the cloud-only vs. hybrid trust model. Hybrid environments may need the WHfB on-premises key trust or certificate trust track — audit domain controller KDC certificate requirements first.
• For Mac/Linux endpoints and BYOD: mandate FIDO2 hardware keys for all administrative roles. For non-admin staff on non-Windows platforms, evaluate platform passkeys (Apple Passkeys via Authenticator, Google Passkeys).
• Begin migrating Conditional Access policies to require phishing-resistant MFA for all cloud apps with sensitive data (M365, Salesforce, HR systems). Leave legacy apps on grandfathered policies with a sunset date.
• Disable SMS and voice OTP for Entra at the tenant level (Authentication Methods Policy). Disable legacy MFA per-user settings in favor of CA-driven methods.

Phase 3 (Days 61-90): Full enforcement and monitoring

• Remove "any MFA" from all remaining Conditional Access policies. Every access requiring MFA must now specify phishing-resistant strength.
• Enable Token Protection in Conditional Access (Preview as of late 2025, expanding to GA in 2026) — this binds access tokens to the device that authenticated, blocking stolen token replay even from a compromised session cookie.
• Enable Continuous Access Evaluation (CAE) to revoke sessions in near-real-time when risk signals fire.
• Audit service principal and app registration OAuth grants — device-code flow should be blocked for user-facing flows via Block Device Code Flow in authentication flows policies.

---

Track 2: Okta + FIDO2 / FastPass

Okta FastPass provides a device-bound, phishing-resistant authenticator for managed endpoints (Windows, Mac, Linux, iOS, Android). It functions similarly to WHfB but across Okta's identity fabric.

Key configuration points:

• FastPass requires device management (Jamf, Intune, or Okta Device Trust). Establish device trust policies before enabling FastPass in production.
• Enable phishing resistance in FastPass: in the Okta Admin Console, navigate to Security > Authenticators > FastPass > Edit > require user verification + origin binding enforcement.
• Create an Authentication Policy in Okta that requires FastPass or FIDO2 for all application access tiers.
• Block authenticator downgrade: configure the policy to deny access if the user falls back to push/TOTP. Defenders frequently miss this — if FastPass fails (device not enrolled), the default fallback is push notification, which is AiTM-bypassable.
• Session duration control: reduce access token lifetime for high-privilege apps to 4-8 hours. Shorter windows limit the dwell time of any stolen session token.

---

Track 3: Google Workspace + Passkeys / Titan Keys

Google's Advanced Protection Program (APP) is the gold standard for high-risk users (executives, finance, IT admins). APP mandates FIDO2 security keys for all sign-ins and blocks app passwords — consider it mandatory for privilege tiers.

For general workforce:

• Enable Passkeys in Google Admin Console (Apps > Google Workspace > Google Account settings > Passkeys: Allow users to skip passwords using passkeys).
• Enforce 2-Step Verification: Security Key Required for admin and sensitive data groups.
• Block password reuse and legacy app passwords via Admin Console > Security > Less secure apps.
• Google's Context-Aware Access (BeyondCorp) is the CA equivalent — scope it to require verified device + FIDO2 for Drive, Gmail, and Admin Console access.

---

Five Migration Failure Modes (And How to Avoid Them)

1. Breakglass account lockout. The moment you enforce phishing-resistant MFA exclusively, teams forget that their 2-3 emergency/breakglass accounts have no FIDO2 registered. When an Entra outage or passkey sync failure hits, no one can recover the tenant. Fix: Pre-register at least two FIDO2 hardware keys per breakglass account. Store one key in a physical safe. Document the recovery procedure. Test it quarterly.

2. FIDO2 defeating itself via account recovery. The passkey is only as strong as the account recovery flow. If a user can reset their Entra account via SMS OTP "forgot password" and then bypass FIDO2 entirely, your AiTM resistance is theater. Fix: Enforce Temporary Access Pass (TAP) only for recovery — revocable, time-limited, admin-issued — and disable self-service password reset for privileged roles. Review SSPR registration campaigns for phishing surface.

3. Legacy protocol blindspot (SMTP AUTH, IMAP, POP3). Legacy mail clients that use basic auth or legacy protocol bridges bypass MFA entirely — no FIDO2, no push, nothing. AiTM is irrelevant here because no MFA challenge fires at all. Fix: Block legacy authentication in Conditional Access (condition: Client Apps = Legacy auth clients → Block). Use Entra's Sign-in logs filtered by "Legacy authentication" to identify residual users before blocking.

4. Shared/kiosk device UX collapse. Passkeys are device-bound by default. In shared workstation environments (call centers, clinical settings, manufacturing floors), WHfB/FastPass creates a UX disaster — every user needs their own enrolled device or hardware key. Fix: For kiosk scenarios, evaluate FIDO2 roaming authenticators (hardware keys that users carry) rather than platform passkeys. Yubico's YubiKey Bio with fingerprint verification provides a phishing-resistant kiosk-friendly flow. Deploy via managed key distribution.

5. Conditional Access policy complexity drift. Enterprises accumulate CA policies over years. A new phishing-resistant requirement in Policy A can be silently defeated by an older Policy B that still accepts TOTP for the same user + app + platform combination. Fix: Use Microsoft Entra's What If tool and Insights & Reporting to simulate which policy fires for a given user/app/device/IP combination. Audit quarterly using the Entra CA workbook. Remove or consolidate legacy policies aggressively.

---

Detection Coverage During Transition

The migration window is the most dangerous moment — legacy MFA is partially disabled, new passkeys are partially enrolled, and monitoring may not yet cover the new auth paths. Key detections to have live throughout the transition:

| Detection | Source | Priority |

|---|---|---|

| Sign-in from unfamiliar location with TOTP auth | Entra / Okta Sign-in logs | High |

| Device-code authorization grant for non-device-registered app | Entra Audit / Graph API | Critical |

| Impossible travel (successful auth, two countries <4hr) | UEBA / SIEM | High |

| Refresh token usage from new IP within 1hr of session creation | Entra Sign-in logs | High |

| User re-registering MFA methods after recent successful phish | Identity Protection | Critical |

| Session persistence beyond policy-defined max age | Entra CAE events | Medium |

| Legacy auth sign-in (post-block period) | Entra Sign-in logs | High |

| FIDO2 registration from unmanaged device | Entra Audit | Medium |

KQL (Microsoft Sentinel) for Device Code abuse detection:

SigninLogs
| where AuthenticationProtocol == "deviceCode"
| where ResultType == 0  // Successful
| where DeviceDetail.isManaged == false
| summarize Count = count() by UserPrincipalName, IPAddress, AppDisplayName, bin(TimeGenerated, 1h)
| where Count >= 1

---

IOCs / Threat Indicators

While passkey migration is defensive in nature, defenders should monitor these phishing-kit behavioral indicators throughout the transition window:

• Evilginx3 / Modlishka reverse proxy fingerprints: Response headers with atypical X-Forwarded-For patterns; session cookies with atypical domain scope.
• Tycoon 2FA infrastructure (Q1-Q2 2026): Phishing pages hosted on Cloudflare Workers with .workers.dev apex, often using bulk-registered lookalike domains (e.g., login-m1cros0ft-secure[.]com, 0365securelogin[.]net).
• Device-code phishing lure domains (May 2026 campaign): Lures delivered via compromised Teams accounts; URLs pointed to microsoft.com/devicelogin (legitimate) — the adversary social-engineers the code entry, not the URL. No IOC on the domain itself; detection must be behavioral.
• Caffeine PhaaS: Known for Google and Microsoft proxy pages; typically uses .live, .cloud, .online TLDs with typosquatted brand names.
• EvilProxy API endpoints: C2 typically resolves through legitimacy-laundering CDNs; look for anomalous Referer chains in proxy logs.

---

Lyrie Take

The identity layer is now the primary attack surface for enterprise intrusions. The playbooks that worked in 2018 — strong passwords + TOTP + IP allowlisting — are insufficient in 2026. FIDO2 and passkeys represent the only MFA category with a structural cryptographic guarantee against session relay, and the enterprise identity vendors (Microsoft, Okta, Google) have all reached the maturity point where full deployment is operationally feasible.

The risk is not technical — it is organizational inertia. Most breaches documented in the last six months that originated via phishing had phishing-resistant MFA available to the victim organization but not enforced, because the migration felt "too disruptive." AiTM kit operators have mapped exactly this gap.

The 90-day playbook above is aggressive but achievable. Phased by privilege tier, with careful recovery account planning and detection coverage throughout, a mid-size enterprise (2,000-20,000 users) can complete the core migration within a single quarter. The marginal disruption cost of that migration is substantially smaller than a single AiTM-sourced breach.

Lyrie's cyber protection platform detects session anomalies, AiTM proxy behavioral patterns, and device-code phishing flows continuously — independent of whether the underlying identity platform has completed its FIDO2 rollout. Detection and migration are parallel workstreams, not sequential ones. Don't wait to finish the migration before enabling behavioral monitoring; the transition window is exactly when adversaries look hardest.

---

Defender Playbook (30/60/90 Summary)

Day 1-30: Audit and Pilot

• [ ] Export per-user MFA method inventory from all IdPs
• [ ] Identify all Conditional Access / Authentication policies accepting legacy MFA
• [ ] Block device-code flow for all user-facing OAuth apps
• [ ] Deploy WHfB/FastPass/platform passkeys to IT and admin cohort (50-100 users)
• [ ] Enforce phishing-resistant MFA strength for pilot group via CA policy
• [ ] Enable Sentinel/SIEM detection for device-code phishing and impossible travel
• [ ] Register FIDO2 keys for all breakglass / emergency access accounts

Day 31-60: Broad Rollout

• [ ] Push WHfB via MDM to all managed Windows devices
• [ ] Distribute FIDO2 hardware keys for Mac/Linux/BYOD admin roles
• [ ] Extend phishing-resistant CA policies to all sensitive apps
• [ ] Disable SMS and voice OTP at tenant level
• [ ] Block legacy authentication (SMTP AUTH, IMAP basic auth) via CA
• [ ] Enforce self-service recovery via TAP only (not SMS SSPR) for privileged users

Day 61-90: Full Enforcement

• [ ] Remove all "any MFA" Conditional Access conditions
• [ ] Enable Token Protection (Entra) for high-value app tiers
• [ ] Enable Continuous Access Evaluation org-wide
• [ ] Audit all service principal OAuth grants; revoke device-code grants
• [ ] Run CA "What If" audit for all privilege tiers
• [ ] Tabletop: simulate FIDO2 device loss / account recovery scenario
• [ ] Document and test quarterly recovery procedure for breakglass accounts

---

Sources

1. Microsoft Security Blog — "Breaking the code: Multi-stage 'code of conduct' phishing campaign leads to AiTM token compromise" (May 4, 2026): https://www.microsoft.com/en-us/security/blog/2026/05/04/breaking-the-code-multi-stage-code-of-conduct-phishing-campaign-leads-to-aitm-token-compromise/

2. SpyCloud — "Device Code Phishing: The AiTM Attack That Bypasses MFA" (May 8, 2026): https://spycloud.com/blog/device-code-phishing-the-new-aitm-attack-bypassing-mfa/

3. Microsoft Entra Documentation — "Plan a phishing-resistant passwordless authentication deployment" (updated March 2026): https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-deploy-phishing-resistant-passwordless-authentication

4. FIDO Alliance — Enterprise Passkey Deployment Resources: https://fidoalliance.org/passkey-use-case/enterprise/

5. StartupDefense.io — "Adversary-in-the-Middle Phishing: How AiTM Bypasses MFA" (April 16, 2026): https://www.startupdefense.io/blog/adversary-in-the-middle-phishing-mfa-bypass

6. WorkOS — "How attackers are bypassing MFA using AI in 2026" (April 2, 2026): https://workos.com/blog/how-attackers-are-bypassing-mfa-using-ai-in-2026

7. A Guide to Cloud — "MFA Methods — Phishing Resistance Ranked" (May 3, 2026): https://www.aguidetocloud.com/mind-maps/mfa-methods/

---

Lyrie.ai Cyber Research Division — Senior Analyst Desk