Passkeys and Phishing-Resistant MFA: Why Your Authenticator App Isn’t Enough Anymore

Let me start with the part that matters most, because I do not want it buried: if you have multi-factor authentication turned on, leave it on. Nothing in this article is an argument for switching anything off. Microsoft’s research has consistently found that multi-factor authentication blocks more than 99% of automated account-compromise attempts, and that has not changed for the automated attacks it was measured against.

What has changed is the attacker who is aiming at you specifically. The bulk, automated attacks that MFA stops are still stopped. Targeted phishing has moved past it, and the technique is now packaged, sold, and used against small businesses — not just banks and government agencies. We have worked incidents where the client did everything they were told to do, had MFA on every account, and still ended up with an attacker reading their mailbox.

Here is how that happens, and what actually stops it.

How Attackers Get Past the Prompt

The old approach was to trick you into typing your code into a fake page. That still happens, but it is fragile: codes expire in seconds, and a decent fake page is work.

The modern approach does not want your code. It wants your session token — the small piece of data your browser receives after a successful login that tells the service “this browser is signed in, stop asking.” It is the reason you do not re-authenticate every time you open your email.

The attack, called adversary-in-the-middle, works like this:

• You click a link in a convincing email — a shared document, a voicemail notification, a message from a real contact whose account was already taken over.
• The link lands on a server the attacker controls. That server does not host a fake login page. It relays the real one: it fetches every screen from the genuine Microsoft or Google login and passes it to you, and passes everything you type back to the genuine site.
• You see the real login, because it is the real login, with a middleman in the path. Everything looks right — the branding, the wording, your own company logo if your tenant is customized.
• You enter your password. The real service issues a real MFA challenge. Your phone buzzes. You approve it, because you did just try to sign in.
• The real service issues a session token. The middleman captures it in transit and loads it into a browser of its own.

The attacker is now signed in as you, without your password and without needing another code. Worse, changing your password does not necessarily evict them, because the stolen session can remain valid until it is explicitly revoked.

Notice which factor failed. Not a weak one. A six-digit app code and a push approval both fail identically here, because the human approved a login that really was happening. The prompt was not a lie.

What follows is depressingly routine: a mailbox rule that quietly files messages from your bookkeeper into an obscure folder, a few weeks of reading, and then a payment-details email sent from your real address in the middle of a real thread. If you want the wider picture of why mailboxes are the target, why hackers love small business email covers it.

Two related techniques are worth naming. MFA fatigue, where an attacker with your password fires off approval prompts repeatedly until someone taps approve to make it stop. And token theft by malware, where information-stealing software on a computer copies session cookies directly out of the browser, skipping the login entirely.

What “Phishing-Resistant” Actually Means

The industry term for the fix is phishing-resistant MFA. It is not marketing language; it describes a specific property.

A phishing-resistant credential — a passkey, or a hardware security key, both built on the FIDO2 and WebAuthn standards — is a cryptographic key pair created for one specific website. The private half never leaves your device. Two properties do the work:

It is bound to the real domain. When a site asks you to sign in, your device checks which domain is actually making the request and will only sign a challenge from the exact domain the credential was created for. A relay server sitting in the middle is, by definition, a different domain. The device simply declines. There is no code to read out and no approval to tap, so there is nothing for a person to get wrong under pressure.

Nothing reusable crosses the wire. What gets sent is a one-time signature over a challenge, not a secret. Intercepting it gains the attacker nothing.

The important part for a non-technical reader: the check that catches the fake site is performed by software, and software cannot be persuaded that this one time it is probably fine. That is the entire advantage over training a human to inspect a URL at 4:45 on a Friday.

Passkeys come in two flavors. Device-bound credentials live in one place — a hardware security key on a keychain, or the security chip in a laptop or phone unlocked with a fingerprint or face. Synced passkeys are stored in an account or password manager and follow you across your devices, which is far more convenient and slightly less contained. For most staff, synced passkeys are the practical choice. For administrators, hardware keys are worth the extra friction.

Where It Does Not Help

Phishing-resistant is a meaningful improvement, not a force field, and I would rather you hear the limits from us:

• Malware already on the device. If an attacker is running code on the computer, they can potentially take the session after you sign in legitimately. Endpoint detection and device health checks still matter — see why EDR replaced antivirus.
• Consent phishing. A prompt asking you to grant an application access to your mail or files does not care how you logged in. Control which third-party apps users may authorize.
• The fallback method. If a user can still fall back to a text message or an app code, an attacker will manufacture the situation that makes them. Fallbacks are the weak link, and they are why the rollout order below matters.
• Help desk social engineering. Someone calls pretending to be an employee with a lost phone and asks for a reset. Whatever your enrollment and recovery process is, that is your real security level. Verify identity out of band before resetting anything.

Where to Deploy It First

You do not need to do the whole company at once, and trying to is how these projects stall. Start with the accounts an attacker would actually pick:

• Anyone who can move money. Accounts payable, payroll, whoever approves wires or changes banking details, and the owner whose name gets impersonated in the fraudulent request.
• Email and identity administrators. Global administrators in Microsoft Entra ID, super administrators in Google Workspace, and anyone who can create accounts, reset MFA, or read other people’s mailboxes.
• IT and vendor accounts with remote access into servers, firewalls, or the backup console. The backup console is the one people forget, and it is the one ransomware operators look for.
• Remote access. VPN and any remote desktop gateway.
• The systems outside your main identity provider. Business banking, payroll portals, the merchant account, the domain registrar. These sit outside single sign-on, most of them now support passkeys or security keys, and they are frequently the highest-value targets in the building.

How the Rollout Actually Goes

1. Add, do not remove. Enroll passkeys or security keys alongside existing methods. Nobody loses a way in.

2. Equip the small group properly. Two hardware keys per administrator — one carried, one in the safe. Buying one key per person is how a lost keychain becomes a lockout.

3. Sort out break-glass access before you tighten anything. Keep at least two emergency administrator accounts that are excluded from the new policy, protected with long unique passwords stored offline, monitored for any use, and tested on a schedule. Skipping this step is the single most common way an identity project locks a company out of its own tenant.

4. Require it for the priority group. Both major platforms let you require a phishing-resistant method for specific roles or applications — Conditional Access authentication strengths in Microsoft Entra ID, which requires Entra ID P1 (included in Microsoft 365 Business Premium), and in Google Workspace either context-aware access on the Enterprise tiers or security-key enforcement in the 2-step verification settings on the Business tiers. Apply it to the list above first.

5. Then narrow the fallbacks for that group, once enrollment is confirmed working. Retire text-message codes for privileged accounts first; they are also exposed to SIM-swap fraud.

6. Shorten what a stolen session is worth. Require compliant or managed devices for administrative access, keep sign-in risk policies on, and make sure your team knows how to revoke sessions rather than only resetting a password. Sign-in risk policies need Entra ID P2; if you do not have it, skip that line. If an account is compromised, revoking sessions is the step that actually ends the intrusion.

7. Then everyone else, at a comfortable pace, with a short explanation of why. Most staff find it faster than what they had, which makes this a rare security change people do not resent.

None of this replaces teaching people what a suspicious message looks like — security awareness training and technical controls cover different failures. And if something does slip through, knowing the first hour of the response matters: what actually happens when a business gets hacked walks through it.

The Short Version

Your authenticator app is not obsolete and should stay exactly where it is. It is simply no longer sufficient for the handful of accounts that an attacker would go after deliberately — the ones that can move money or hand out access. For those, a credential that verifies the website on your behalf closes the gap that a session-stealing proxy walks through, and the hardware costs less than an hour of incident response. For the rest of the company, add passkeys as an option and let convenience do the persuading. Layer it on. Do not swap it in.

Related Questions