MFA Has a Weight Class: Where Your Users Sit and How to Move Them Up

"Do you have MFA?" is the wrong question. SMS codes, authenticator pushes, and passkeys all let you answer yes, and they do not survive the same attacks. The right question is which tier of MFA each user sits on, because attackers have already moved past the bottom rungs. This post walks the hierarchy from passwords to passkeys, names the attack that defeats each tier, and covers the practical mechanics of moving users up, including the rollout sharp edges Microsoft does not mention.

Tier 0: passwords alone are not a tier#

There is not much new to say about running without MFA, except that plenty of MSPs still have customers in exactly that state. Passwords have always carried the same flaws:

• They are usually weak or easily crackable
• They are not unique
• They are stored insecurely

Password managers fix most of that list, but they do not fix the surrounding exposure:

• Third-party databases get breached constantly, and every vendor that does not integrate with your IdP (Entra) extends your exposure
• Password managers themselves have been breached (LastPass)
• Users still hand credentials to phishing pages

Tier 1: one-time passcodes stop the casual attacker#

One-time and time-based passcodes were the first mainstream second factor. The common delivery methods today:

• SMS or phone call
• Email
• Software tokens and push notifications

It remains remarkable how many services holding genuinely sensitive data, banks and credit card companies among them, still rely on SMS codes. Each delivery method has a known defeat:

• SMS/Phone: SIM swapping, social engineering, lost or stolen devices
• Email: the third-party mailbox receiving the code, often a personal Gmail account, frequently has no MFA of its own
• Software tokens/push: social engineering and MFA fatigue, where the attacker spams prompts until the user approves one

These are the weaker forms of MFA, but weaker MFA still beats none: any form of MFA blocks over 90 percent of the common attacks in circulation.

Tier 2: number matching fixes fatigue, not phishing#

Microsoft added number matching to Authenticator specifically to kill MFA fatigue, and it does that job well. It is still not phishing resistant, for two reasons. First, social engineering survives: an attacker on the phone can read the number off their screen and talk the user into entering it. Second, adversary-in-the-middle frameworks like Evilginx proxy the real Microsoft login page, so the user completes a fully legitimate MFA ceremony while the attacker captures the credentials and the session token that carries the MFA claim.

Tier 3: passkeys are where phishing resistance starts#

FIDO authentication has been around for years and has evolved considerably. Instead of passwords, it relies on passkeys: cryptographic credentials stored securely on a user's device. When FIDO1 launched, the second factor was typically a physical security key plugged into the device. On passkey-enabled services today, users present a biometric (fingerprint, face recognition) or a hardware key, and a cryptographic exchange verifies identity behind the scenes. The user never sees the private key, and nothing typeable exists to steal. Windows Hello is a passkey implementation; YubiKeys remain the most popular hardware option.

Three properties make passkeys phishing resistant:

• Passwordless: there is no password to harvest
• Device-bound gesture: the user must perform an action on the device holding the passkey (Face ID, thumbprint, PIN) for authentication to proceed
• Origin binding: at registration, the passkey records its legitimate origin, and that check defeats lookalike domains

The origin point deserves the detail. An Evilginx-style page might live at login.microsoftonlline.com, a URL different from the real one by a single extra letter that most users will never spot. A passkey registered for Microsoft carries the origin login.microsoft.com. Even if the user clicks the malicious link and lands on the fake page, the passkey refuses to perform the sign-in because the origin does not match. The phish fails without depending on user vigilance.

Example of a passkey prompt on Windows 11:

The upgrade path: passkeys in Microsoft Authenticator#

In early 2024, Microsoft added passkey support to the Authenticator app on iOS and Android. That enables cross-device sign-in, a FIDO2 capability where the phone acts as the roaming source of truth for authentication on other devices. Setup happens in the Authentication Methods settings in Entra:

• How to enable passkeys in Microsoft Authenticator for Microsoft Entra ID (preview) (opens in new tab)
• Register passkeys in Authenticator on Android and iOS devices in MySecurityInfo (preview) (opens in new tab)

From there, Conditional Access authentication strengths are the enforcement lever: instead of accepting any MFA, a policy can require the phishing-resistant tier for admins first, then widen the scope as registration coverage grows. That is the upgrade path in practice, ratcheting the required strength rather than flipping every user at once.

What the passkey rollout does to your helpdesk#

The honest question before enforcing passkeys: if users struggle with the Authenticator app, will they manage passkey registration? They gain freedom from passwords, but setup asks more of them. Plan for these specifics:

Users register passkeys themselves on the My Security Info page:

On iOS, a user who does not follow the instructions exactly can store the passkey in their iCloud Keychain instead of Authenticator:

If passkeys with Authenticator are the only second factor enabled through Conditional Access, sign-in prompts users to scan a QR code:

Enforcing passkeys for all users means every net-new user needs a Temporary Access Pass to reach the security page and add their passkey:

One caveat from hard experience: if Temporary Access Pass is not already enabled as an authentication method, allow roughly 8 hours for the setting to propagate before using a TAP with a user who has no MFA registered. In our testing, moving faster produced unhelpful error messages and a sign-in loop that only resolved after waiting out Microsoft's propagation. Classic.

Lost or replaced phone? The user needs another Temporary Access Pass to establish a new passkey. Annoying, but a simpler recovery flow than a lost YubiKey.

The attack that ignores the whole ladder: pass-the-cookie#

A pass-the-cookie attack starts with a compromised device. The attacker harvests the session cookie from the user's browser and replays it on their own machine to obtain an authenticated session. No login, no MFA prompt, and yes, it bypasses passkeys too, because no new authentication ever happens.

Microsoft's answer is the token protection setting in Conditional Access, which binds tokens to the user's device: Token protection in Microsoft Entra Conditional Access (opens in new tab).

Mind the preview fine print, though. Microsoft's own documentation states: "This preview doesn't currently support access tokens or web cookies." So as of May 2024 you cannot stack token protection on top of passkeys for full coverage, although that combination is the obvious destination. In the meantime, pass-the-cookie exposure is concentrated on devices running active malware, and you can attack it from that side:

• Keep users off personal devices where your security protections are absent; pass-the-cookie tooling often uses Mimikatz, which Microsoft Defender and other EDR/AV vendors detect and block
• Run Safe Links and Safe Attachments policies to protect users in email and documents
• Use strict location continuous access evaluation controls in Conditional Access to cut off replayed sessions

See the whole thing end to end#

A full demo of the methods and rollout mechanics covered here: watch the walkthrough on YouTube (opens in new tab).