In the Microsoft Entra ID environments I work in, a surprisingly large share of users still authenticate with SMS codes or voice calls, and that includes tenants that have enforced MFA for years. Security teams know these methods are no longer good enough. Phishing attacks, SIM-swapping and social engineering make SMS and voice risky by design. Getting everyone onto something stronger like Microsoft Authenticator takes more than flipping a policy setting, though. This is the job of the Entra ID registration campaign, which has been available in every tenant for a while now in the Entra admin center under Protection → Authentication methods → Registration campaign.

The registration campaign prompts users right in the sign-in flow

An email or a Teams announcement is easy to ignore. The registration campaign is different because it sits inside the sign-in flow itself. When a user signs in and hasn't registered a secure method such as Microsoft Authenticator yet, the campaign asks them to set it up on the spot, so you don't have to chase anyone manually. It's polite but it keeps coming back. Users can snooze the prompt a configurable number of times, and you can set a hard deadline after which setup becomes mandatory. You don't need a premium licence for this, so any tenant can use it.

There is one catch. The campaign can only do as much as your authentication methods policy allows. If SMS and voice calls are still permitted, users can stay on those weaker methods forever. For that reason I recommend a phased approach in practice: let the campaign push people to register Authenticator, watch adoption, and only then start disabling SMS in the policy for the users who are ready. The data you need is under Authentication methods → User registration details and Activity.

System-preferred MFA picks the strongest method a user has registered

The second piece is system-preferred multifactor authentication. With this enabled, the platform automatically selects the strongest registered method every time a user signs in. If someone still has SMS or voice configured but also has Authenticator registered, Authenticator is what gets used. That removes a lot of risky fallbacks, and Microsoft's documentation explains it clearly (System-preferred MFA).

In several rollouts I've watched SMS usage drop sharply overnight once system-preferred MFA was switched on, provided most users already had Authenticator set up. Check the Authentication methods section in the admin center to confirm it's enabled. Combined with the registration campaign, it moves things along noticeably.

Combined registration covers MFA and SSPR in a single pass

Users no longer have to register for MFA and self-service password reset (SSPR) in two separate steps. The combined registration experience handles both in one process, so anyone going through the campaign sets up what they need for secure sign-in and account recovery at the same time. In my experience this means less confusion and fewer support tickets. If you're still running the old MFA and SSPR policies, this is a good moment to move to the new authentication methods policy. I've written a hands-on guide for that: Migrating to the Authentication methods policy.

The reports show whether the campaign is actually working

A mistake I run into often is that someone turns on the registration campaign and then never looks at it again. Get into the habit of checking progress in the admin center instead. Authentication methods → User registration details gives you a quick picture of how many users have registered Authenticator or other strong methods. The Activity tab shows which methods people actually use, and that tells you when you can safely start deprecating SMS or voice. If you want to dig deeper, you can export the data.

Pro tip: Look at which departments or business units are behind on Authenticator enrollment. Focus your communication and support on them rather than emailing the entire company.

Microsoft's documentation on the available reports and usage analytics is practical and worth a read: Authentication method activity reports.

SMS and voice should be phased out in stages

Dropping SMS as an MFA method changes how people work, not just how the tenant is configured. This is the sequence that has worked best in my projects:

  • Enable the registration campaign and set Authenticator as the preferred method
  • Review the reports regularly and step in where needed
  • Enable system-preferred MFA
  • Remove SMS/voice from the authentication methods policy bit by bit

Keep in mind that the authentication methods policy is what drives all of this. If passwordless sign-in (passkeys, for example) is on your roadmap, start preparing now. See Passkeys in Microsoft Authenticator: Entra ID preview.

The diagram below shows how the individual steps connect:

graph TD
User["User"] --> Login["Sign-in"]
Login --> Campaign["Registration campaign"]
Campaign -->|"No Authenticator"| Setup["Prompt Authenticator setup"]
Campaign -->|"Snooze"| Login
Setup --> Policy["Authentication methods policy"]
Policy -->|"Remove SMS"| Authenticator["Only strong methods allowed"]
Authenticator --> System["System-preferred MFA enabled"]
System --> Login

Figure: The registration campaign, the policy and modern MFA working together

SMS won't disappear unless you push it out

In tenants without an active campaign, or where SMS gets switched off too abruptly, I see support incidents and user frustration go up. When the campaign, system-preferred MFA and a policy cleanup are used together, nearly all users end up on stronger methods within a few months, with far less friction. Keep an eye on the right reports, adjust as you go, and your security baseline will improve across the tenant fairly quickly.

One more thing: moving to the authentication methods policy also prepares you for options like passkeys later on. I'd make the registration campaign and the modern policy your standard setup. Your users and your security team will both be better off for it.