Wesley Swann November 4, 2026 0 Comments

SMS codes were a reasonable second factor ten years ago. Today they are the weakest method most tenants still allow, open to SIM swapping, phone number porting and simple phishing pages that ask for the code. Moving users to Microsoft Authenticator number matching is the fastest practical upgrade, and it sets you up for the real destination: passkeys.

This article explains why SMS should go, how number matching changes the picture, and a step-by-step plan for shrinking SMS down to a small, controlled exception group.

Why SMS and voice should be your last resort

Text message codes have three problems:

  • The phone number isn’t really yours. A determined attacker can convince a carrier to port or swap a number, and then receives every code.
  • Codes are easy to phish. A fake sign-in page simply asks for the code and replays it instantly.
  • Delivery is unreliable. Roaming, poor signal and carrier filtering cause failed sign-ins and helpdesk calls.

Microsoft’s own system-preferred MFA ranks telephony methods (SMS and voice) at the bottom of the list of second factors. That ordering is a strong hint about where you should be heading.

What number matching does

Push notifications used to ask “Approve or Deny?”. Attackers learned to send dozens of them until a tired user tapped Approve, a technique known as MFA fatigue. With number matching, the sign-in screen shows a two-digit number and the user has to type that number into Microsoft Authenticator. Someone who didn’t start the sign-in doesn’t know the number, so blind approvals stop working.

Number matching is now the standard behavior for Authenticator push notifications. You can add two optional extras in the Microsoft Authenticator settings of the Authentication methods policy: showing the application name and showing the geographic location of the sign-in. Both help users spot a request they didn’t make, and I turn both on in most tenants.

Be clear-eyed about the limits. Number matching defeats fatigue attacks, but an adversary-in-the-middle phishing page can still show the user the real number. That is why number matching is the stepping stone, and passkeys are the goal.

Where your users are today

Before changing anything, measure. In the Microsoft Entra admin center, go to Entra ID > Authentication methods > Activity. The registration details show which methods each user has registered and what their default method is. In the tenants I review, the common pattern is a majority on Authenticator, a sizeable group still defaulting to SMS, and a handful with no method at all.

Sort users into four buckets:

Bucket Situation Action
Ready Authenticator registered and set as default No action; candidates for passkeys
Nudge Authenticator registered, SMS still default System-preferred MFA will usually fix this automatically
Move SMS or voice only Registration campaign for Authenticator
Exception Genuinely can’t use an app (no smartphone, policy reasons) Hardware OATH token or security key

Step-by-step: shrinking SMS to an exception group

  1. Confirm you are on the Authentication methods policy. Since September 30, 2025, methods can’t be managed in the legacy MFA and SSPR settings pages. If your migration status isn’t Complete, finish it first, and make sure the legacy method boxes are cleared so old settings don’t linger.
  2. Enable Microsoft Authenticator for all users in Entra ID > Authentication methods > Policies > Microsoft Authenticator. Turn on application name and geographic location in the Configure tab.
  3. Enable system-preferred MFA. It prompts users with the strongest method they have registered rather than whatever they chose as default years ago. For many users this alone moves them off SMS.
  4. Run a registration campaign. The Authentication methods policy includes a registration campaign setting that nudges users to set up Authenticator at sign-in. Allow a limited number of snoozes, then make it required.
  5. Create an SMS exception group. Name it something like AuthMethods-SMS-Allowed. Change the SMS and Voice call methods so they target only this group.
  6. Tell the users in the Move bucket first. Give them a date, a one-page guide and a drop-in session. Then remove SMS for everyone outside the exception group.
  7. Check SMS sign-in. The SMS method has a separate “use for sign-in” option that lets a phone number act as the username and first factor. Turn it off unless you have a specific frontline scenario that needs it.
  8. Review the exception group monthly. Each member should have a reason and an owner. Move them to a hardware OATH token or security key where you can.

If you’d rather have this run for you, our MFA enablement service covers the measurement, communication and policy changes. Deploying Authenticator to company phones is straightforward with Intune for iOS and iPadOS and Intune for Android.

Don’t forget password reset

Self-service password reset often keeps SMS alive after you’ve removed it from sign-in. If SSPR still accepts mobile phone as a method, an attacker who controls the number can reset the password and then try to register their own MFA. Line SSPR up with the same methods: Authenticator notification or code, plus a second method such as email to a personal address, and protect security info registration with Conditional Access.

Beyond number matching: the path to passkeys

Once most users are on Authenticator with number matching, the next step is phishing-resistant authentication. Microsoft Authenticator can hold a device-bound passkey, so users keep the same app they now know. A sensible order:

  • Admins on hardware security keys, enforced with the Phishing-resistant MFA authentication strength.
  • Finance, HR and executives on Authenticator passkeys.
  • Everyone else, department by department.

Microsoft documents the full behavior of number matching in Authenticator push notifications, including same-device sign-in on mobile.

Communicating the change to staff

Most resistance to leaving SMS comes from habit, not from any real problem with the app. A short, plain message works better than a long policy document. I usually send three things:

  • Why: two sentences on SIM swapping and code phishing, written for non-technical readers.
  • What to do: install Microsoft Authenticator, open the security info page, add the app, and set it as the default sign-in method. Include screenshots for iPhone and Android.
  • When: the date SMS stops working for them, and where to get help if they are stuck.

Send a reminder three days before the cutoff, and ask managers to mention it in team meetings. People who travel often or work part time are the ones most likely to miss the message, so contact them directly. On the cutoff day, keep someone available to issue Temporary Access Passes for anyone who gets stuck, so a missed email never turns into a lost morning of work.

Frequently asked questions

Is number matching enough on its own?

It stops MFA fatigue attacks, which is a big improvement over plain approve or deny. It doesn’t stop real-time phishing proxies, which can show the user the correct number. Treat it as a stepping stone to passkeys, not the finish line.

What should users without a smartphone use?

A hardware OATH token or a FIDO2 security key. Both work without a phone. Security keys are phishing resistant, so for most cases they are the better buy.

Will removing SMS lock people out?

Only if they have no other method registered. That is why you measure first, run the registration campaign, and keep a monitored exception group. A Temporary Access Pass gets anyone who is stuck back in so they can register Authenticator.

Still relying on text message codes? Book a free Microsoft 365 security assessment and we’ll show you exactly who depends on SMS today, and how to move them to stronger methods without disruption.