Passkeys enabled ≠ phishing-resistant

A few weeks ago I wrote about passkey onboarding in Entra, and at the end of that post I made a promise: “Once users have onboarded with passkeys, the real work begins.” This is that follow-up. Because if you stopped at “we have now implemented passkeys,” congratulations, you’ve just installed a brilliant new front door on a house that still has three unlocked windows and a key under the doormat.

This is a familiar pattern: A security team gets passkeys deployed, leadership celebrates, the project closes, and nobody touches Conditional Access again for six months. Meanwhile, every weak authentication method that was there before is still there. SMS, voice calls, Authenticator push without number match etc. Attackers don’t care that you have a beautiful new phishing-resistant method available. They care which methods you’ll accept. And until you turn the old ones off, those are the ones they’ll target.

Why “we have passkeys now” is not the same as “we are secure”

Passkeys are phishing-resistant. SMS, voice, and basic push are not. That’s not a controversial statement, that’s just the math. The moment you allow both in the same tenant, your effective security posture is the weakest method any account can fall back to, not the strongest method available.

Think of it like this: If you install a high-security deadbolt on your front door but leave the bathroom window permanently unlocked, you don’t have a secure house. You have a bathroom window.

This isn’t theoretical. We have plenty of receipts.

Real stories, real consequences

Uber, September 2022: MFA fatigue (source)

An attacker bought a contractor’s Uber credentials on the dark web. The password got them past step one, but they hit MFA. So instead of giving up, they just started spamming the contractor with push notifications. When the contractor stopped approving, the attacker messaged them on WhatsApp pretending to be Uber IT and said, basically, “Just accept it so the notifications stop.” The contractor accepted. The attacker got in.

Push notifications without number matching, without context, without anything beyond “tap yes” are not MFA in any meaningful sense. They’re a doorbell the attacker keeps ringing until you open the door to make them stop.

MGM Resorts, September 2023: Voice-phishing the helpdesk (source)

Scattered Spider found an MGM employee on LinkedIn, called the IT helpdesk pretending to be that employee, and convinced the helpdesk to reset the account’s MFA. The phone call reportedly lasted ten minutes. Ten minutes to admin privileges on Okta and the Azure tenant. The end result: Roughly $100 million in losses, slot machines down, hotel keys not working, federal lawsuits.

Caesars Entertainment got hit by the same group around the same time and chose to pay a $15 million ransom rather than fight it. Different decision, same root cause: An authentication factor that could be reset by a human being who could be talked into it.

This is the part that bothers me most. The technical control was fine. The process around the technical control was the breach.

AiTM phishing, ongoing: Microsoft’s own data (source)

Microsoft’s Entra team has been publishing increasingly urgent warnings about adversary-in-the-middle phishing for the past couple of years. The attack is simple: A convincing fake login page proxies your real Microsoft login in real time, captures your credentials and your MFA response, and walks away with a valid session token. Every non-phishing-resistant MFA method falls to this. Push, OTP from Authenticator, SMS, voice. All of them.

Passkeys defeat it. The others don’t. That’s the entire argument for what comes next.

What “fallback” actually means in your tenant right now

Before we fix anything, take an honest look at what is currently allowed to sign someone in:

• SMS / text message: Vulnerable to SIM swap, phishable, interceptable. Avoid if you can. If not: Treat as a recovery method at most, never a sign-in method. See how to do this below.
• Voice call: Same problem, avoid if you can! See how to restrict this below.
• Microsoft Authenticator push without number matching: Vulnerable to MFA fatigue. Number matching is on by default for most tenants now, but verify it actually is on for all users in your tenant.
• OATH OTP codes (TOTP): Phishable via AiTM. Better than SMS, still not phishing-resistant.
• Security questions (SSPR only): Not an MFA method, but if you’re still using them for password reset, be aware that the answers are essentially public information for most users. Phase them out.
• Email OTP for guests: Sometimes necessary, but understand what you’re trusting.
• Temporary Access Pass (TAP): Fine as a bootstrap, dangerous as a permanent method. Time-limit it strictly.

If any of these are valid for sign-in (not recovery) on accounts that have also registered a passkey, you have not finished the migration. You’ve just added another method on top.

How to set SMS to recovery only

Correction: An earlier version of this section incorrectly stated that disabling the “Use for sign-in” toggle removes SMS as an MFA method. That is wrong, and I want to thank the reader who flagged it. The “Use for sign-in” toggle only controls SMS as a first factor sign-in method (where users sign in with just a phone number and SMS OTP, no password). It does not prevent SMS from satisfying an MFA requirement. Below is the correct guidance.

The simplest path: Just turn it off

If you don’t use SMS for SSPR and you don’t want it as an MFA method, the cleanest answer is to disable it entirely in the Authentication methods policy. No SMS for sign-in, no SMS for SSPR, no SMS for MFA. Done.

1. Navigate to Entra admin center → Authentication methods → Policies.
2. Click SMS in the method list.
3. Set Enabled to Off.
4. Click Save.

That’s it. Skip the rest of this section unless you have a reason to keep SMS available for something.

If you want to keep SMS available for SSPR but not MFA

This is the more nuanced scenario, and it requires two separate controls because the Authentication methods policy and MFA enforcement are managed in different places.

1. SMS as a first factor sign-in method

Disabling “Use for sign-in” prevents users from signing in with phone number + SMS OTP as their only credential. This is a niche frontline-worker scenario in most tenants, and disabling it is usually safe.

1. Navigate to Entra admin center → Authentication methods → Policies.
2. Click SMS in the method list.
3. Under the Enable and Target tab, set Use for sign-in to No for the relevant group(s).
4. Click Save.

2. SMS as a method that satisfies MFA

This is what most of you actually want to lock down, and it is not controlled by the Authentication methods policy. It is controlled by Authentication Strength in Conditional Access.

1. Navigate to Entra admin center → Conditional Access → Authentication strengths.
2. Create a new custom Authentication Strength (or use the built-in Phishing-resistant MFA strength if it fits your needs).
3. If you create a new one: Select only the methods you want to accept as MFA, for example Passkeys (FIDO2), Windows Hello for Business, Certificate-based authentication, and Microsoft Authenticator (push with number matching). Deliberately exclude SMS and Voice call.
4. Save the Authentication Strength.
5. In your Conditional Access policies, under Grant, select Require authentication strength and choose the strength you just created. Apply this instead of the generic “Require multifactor authentication” grant control.

✅ Verify: Sign in to aka.ms/mysecurityinfo as a test user who has SMS registered. Attempt a sign-in that requires MFA. SMS should no longer appear as an option. Password reset via SMS should still work.

How to restrict Voice calls

The simplest path: Just turn it off

If you don’t use Voice call for SSPR either, disable it entirely. Same approach as SMS:

1. Navigate to Entra admin center → Authentication methods → Policies.
2. Click Voice call in the method list.
3. Set Enabled to Off.
4. Click Save.

Done. Skip the rest of this section unless you have a reason to keep Voice call available.

If you want to keep Voice call available for SSPR but not MFA

The same principle as SMS applies: The Authentication methods policy controls who can register Voice call (including for SSPR), but it does not control whether Voice call satisfies an MFA requirement. To prevent Voice call from being accepted as MFA, you use Authentication Strength in Conditional Access.

1. Restrict who can register Voice call

1. Navigate to Entra admin center → Authentication methods → Policies.
2. Click Voice call in the method list.
3. Under the Enable and Target tab, set to Select groups and specify only the group that legitimately needs it (for example, a small group of frontline workers without smartphones).
4. Click Save.

2. Prevent Voice call from satisfying MFA

Voice call should not appear in any Authentication Strength you use to enforce MFA. If you have already created a custom Authentication Strength for SMS (see above), the same one applies here. Verify that Voice call is not selected in the list of accepted methods, and that the strength is referenced in your Conditional Access policies under Grant → Require authentication strength.

✅ Verify: Attempt a sign-in with a test account whose only MFA method is Voice call, against a resource protected by your Authentication Strength policy. The sign-in should be blocked or prompt for registration of a stronger method.

What to do this week

These are the things I’d want done in the next 5-7 working days. None of them are heavy lifts:

1. Turn on number matching for Authenticator everywhere. If it isn’t already. This single change kills basic MFA fatigue. Authentication methods → Microsoft Authenticator → Configure → Require number matching for push notifications → Enabled → All users.
2. Audit who can still register SMS or voice as a sign-in method. In Authentication methods policy, scope SMS and Voice to either “disabled” or, at most, a small, named recovery group. Not “all users.”
3. Create an Authentication Strength for phishing-resistant MFA if you haven’t already (I covered this in the February passkey onboarding post). Apply it as a report-only Conditional Access policy first, scoped to admins. See what breaks. Fix what breaks. Then enforce.
4. Lock down your helpdesk MFA reset process. Pick up the phone, call your service desk yourself as a test, see how much friction there is to getting an MFA method reset. If the answer is “ten minutes and a friendly tone,” you have an MGM problem waiting to happen. ⚠️ This one goes beyond IT. Fixing the verification process for MFA resets is a question of policy, governance, and staff training, which means HR and your security responsible need to be in the room. IT can flag the problem and suggest controls, but who is allowed to authorize a reset, under what conditions, and how staff are trained to handle pressure and social engineering: That’s not a decision IT should make alone.
5. Find every break-glass account and confirm it uses FIDO2 keys, stored physically separated, with the credentials documented in a way that doesn’t depend on the same identity system you’re trying to protect.

What to plan for the next 1-3 months

This is the medium-term work. It needs proper change management because it will affect users.

1. Phase out SMS and voice as sign-in methods entirely. Move them to recovery only, then to nothing. Communicate, communicate, communicate. Give users a deadline and a self-service way to register a better method before that deadline.
2. Enforce phishing-resistant MFA on all admin roles first, including Privileged Identity Management activation. Admins should be the canary. If your admins can’t live with FIDO2 only, your end users certainly can’t yet, and you need to know that before you find out the hard way.
3. Apply phishing-resistant MFA to high-value workloads next. Finance systems, HR data, anything that handles regulated information, your tenant management plane, your Purview console. Pick the crown jewels and protect them first.
4. Stand up a Conditional Access baseline you can actually audit. Export your CA policies to a known-good baseline. Review them on a schedule, not on a “when we remember” basis. Silent edits to CA policies are how environments drift back into insecurity over months, which is also why you should set up alerts if any changes to your CA policies takes place.
5. Reduce sign-in frequency for trusted, compliant, passkey-authenticated sessions, not for everyone. This is the carrot. Users who do the right thing should feel a benefit. Otherwise the only thing they’ll associate with passkeys is friction.

What this looks like as an ongoing process

Tightening CA is a posture. The moment you treat it as “done,” it starts decaying.

• Quarterly review of authentication methods policy. Has anyone re-enabled SMS for a special case and forgotten to remove it? Has a new method appeared in the portal that you haven’t evaluated?
• Quarterly review of Conditional Access policies. What’s still in report-only that should have been enforced months ago? What exceptions were added “temporarily” that are still there?
• Monthly sign-in log review for fallback method usage. If nobody has used SMS to sign in for three months, you have evidence to switch it off. If hundreds of users are still using it, you have evidence that your communication plan didn’t land.
• Risk-based CA tuned over time. Identity Protection signals get better the more you feed them. Use them, but verify the policies are still doing what you think they’re doing.
• Tabletop your helpdesk social engineering scenario at least once a year. Pretend to be Scattered Spider (read the MGM example above). See how far you get. Fix what let you get further than you should have.

The gap is where breaches happen

The reason I keep coming back to this is that the gap between “we deployed passkeys” and “we are actually phishing-resistant” is exactly where the breaches happen. Not because passkeys don’t work, they absolutely do, but because the old methods are still standing there, waiting to be the path of least resistance.

Uber’s attacker didn’t beat MFA. They beat push-without-number-matching. MGM’s attacker didn’t beat MFA. They beat a helpdesk process that would reset MFA on request. The AiTM kits Microsoft keeps writing about don’t beat MFA. They beat every method that isn’t phishing-resistant.

Your passkeys are doing their job. The question is whether you’re letting the rest of your tenant undo that job for them.

Start this week with the five quick wins. Plan the next quarter properly. Then keep reviewing, because the attackers absolutely are.

Thank you all, and as always, stay safe out there!