Passwords and weak MFA remain the easiest path for credential stuffing, proxy phishing, and MFA fatigue.

Preface

SMS, voice, and basic push approvals are widely bypassed by modern proxy kits. High-assurance environments need phishing-resistant passwordless authentication. The goal is not only to remove the password, but to use an authenticator that cannot be tricked into signing in to the wrong site.

Problem

Standard MFA is not cryptographically bound to the IdP domain, so AiTM proxies can capture successful authentication. Push fatigue can also produce accidental approvals without advanced tooling.

How the attack works in practice

In an adversary-in-the-middle attack, the victim opens a link to a proxy that looks like the Microsoft sign-in page. The proxy relays the username and password to the real Entra ID, relays the MFA prompt back to the user, and relays the code or approval forward. When Entra ID issues the session cookie, the proxy keeps it. The user sees a normal sign-in; the attacker now has a session that already satisfied MFA.

One-time codes, SMS, voice calls and push notifications all fail the same way, because nothing in them ties the approval to the website the user is actually on. Number matching in Microsoft Authenticator reduces fatigue attacks, but it does not stop a real-time relay.

FIDO2 and passkeys work differently. The authenticator signs a challenge with a key that is scoped to the relying party identifier, and the browser supplies the origin. A proxy on a look-alike domain cannot obtain a valid signature for login.microsoftonline.com, so the relay fails. Windows Hello for Business and certificate-based authentication with a smart card offer comparable binding through device-held keys.

Solution

Align with NIST SP 800-63B AAL3 and CIS Microsoft 365 Foundations Benchmark:

  1. Deploy FIDO2 / passkeys (hardware keys or Windows Hello for Business). Hardware security keys and Windows Hello for Business backed by a TPM are device-bound; passkeys in Microsoft Authenticator are also device-bound.
  2. Enforce Entra CBA with smart cards or hardware tokens, where an existing PKI and smart card estate already exists, such as government or defense supply chains. Configure the authentication binding so the certificate is treated as multifactor only when it is on a protected token.
  3. Require phishing-resistant authentication strengths in Conditional Access for admins and high-risk sessions, using the built-in "Phishing-resistant MFA" strength.

Design guidance

  • Choose by population. Administrators and shared or kiosk scenarios suit hardware keys. Knowledge workers on managed Windows devices suit Windows Hello for Business. Mobile-first staff suit passkeys in Authenticator.
  • Enforce attestation and key restrictions for privileged users. An allow list of approved authenticator models (by AAGUID) keeps admins on keys you have evaluated. Check the current state of synced passkey support in your tenant before allowing it for high-assurance roles.
  • Close the downgrade path. If SMS or push remains available, a proxy can simply ask for it. Phishing resistance only exists where Conditional Access requires the phishing-resistant strength.
  • Plan bootstrap and recovery. Use Temporary Access Pass for first registration and for lost-key recovery, issued only after identity verification. Give every administrator two keys, stored separately.
  • Migrate method management. Manage all methods in the converged Authentication methods policy, not the legacy MFA and SSPR settings.

Implementation steps

  1. Inventory current methods per user with the authentication methods activity report, and identify admins still using SMS or voice.
  2. Enable FIDO2 in the Authentication methods policy for a pilot group, with attestation and an AAGUID allow list for privileged users.
  3. Procure keys, distribute them in person or through a verified process, and register using Temporary Access Pass.
  4. Create a Conditional Access policy requiring the phishing-resistant strength for all directory roles, in report-only mode first, then enforce.
  5. Extend to high-risk sign-ins and sensitive applications, then to the general population with Windows Hello for Business or passkeys.
  6. Disable SMS and voice for users who have a stronger method, starting with administrators.

PowerShell: Configure FIDO2 Method Policy

The FIDO2 settings are part of the Authentication methods policy and are updated through the generic method configuration cmdlet. Key restrictions are a nested object rather than a single flag:

Connect-MgGraph -Scopes "Policy.ReadWrite.AuthenticationMethod"
$params = @{
    "@odata.type"                    = "#microsoft.graph.fido2AuthenticationMethodConfiguration"
    State                            = "enabled"
    IsSelfServiceRegistrationAllowed = $true
    IsAttestationEnforced            = $true
    KeyRestrictions = @{
        IsEnforced      = $true
        EnforcementType = "allow"
        AaGuids         = @("<AAGUID-of-approved-key-model>")
    }
}
Update-MgPolicyAuthenticationMethodPolicyAuthenticationMethodConfiguration `
    -AuthenticationMethodConfigurationId "Fido2" -BodyParameter $params

Test key restrictions with a pilot group first. Enforcing an allow list blocks any registered key whose model is not listed, including keys users already rely on.

Monitoring and detection

Measure adoption and find privileged users still signing in with weaker methods. In Microsoft Sentinel:

SigninLogs
| where TimeGenerated > ago(30d) and ResultType == "0"
| mv-expand AuthDetail = todynamic(AuthenticationDetails)
| extend Method = tostring(AuthDetail.authenticationMethod)
| where Method !in ("", "Password", "Previously satisfied")
| summarize SignIns = count(), Users = dcount(UserPrincipalName) by Method
| order by SignIns desc

Join the same data to a watchlist of administrators to list any who completed MFA with text message, voice or push in the period. Also alert on authentication method changes in AuditLogs, such as "User registered security info" and "Admin registered security info". An attacker who briefly holds a session will often try to register their own method for persistence.

Common mistakes

  • Deploying keys but leaving Conditional Access on generic MFA, so users and attackers can still choose a weaker method.
  • Issuing Temporary Access Pass over email or chat without verifying identity.
  • Giving administrators a single key with no recovery plan, then creating permanent exceptions after the first lost key.
  • Allowing any FIDO2 authenticator for privileged roles without attestation.
  • Forgetting break-glass accounts, which should also use dedicated FIDO2 keys held in separate safes.

Where to start

Start with administrators: two hardware keys each, registered via Temporary Access Pass, and a Conditional Access policy requiring the phishing-resistant strength for every directory role. Then deploy Windows Hello for Business or passkeys to the wider workforce, and retire SMS and voice once usage data shows users have moved. That sequence removes the most valuable relay targets first.