Skip to content

Goodbye legacy SSPR and MFA settings. Hello Authentication Methods Policies!

I’ve got some exciting news to share today. Microsoft has launched a public preview called “Authentication Methods Policy Convergence.” I was part of the private preview program, and I’m very happy to see this feature going public. In this post, I will give you a brief introduction to this new feature and explain why this is such a big deal.

Current situation

A while back, I wrote this post where I explained that the SSPR and MFA settings are very intertwined and how you could tweak the settings to your liking by experimenting with different variations of settings. However, settings are managed in different portals and without comprehensive programmatic control. Let’s see what we have today:

We have the legacy multi-factor authentication portal (, where we can manage the MFA methods and trusted IP’s.

Next, we have the blade in the Azure portal, where we can configure the SSPR methods.

Lastly, we have the newest kid on the block: the Authentication methods policy blade.

So three portals to configure settings for SSPR and MFA. What’s not to like? 🙂

What’s new?

With the Authentication Methods Policy Convergence preview, Microsoft is consolidating the configuration of MFA and SSPR methods into Authentication Methods Policies. That already has two significant benefits:

  1. One portal to rule them all.
  2. More flexibility and granularity.

This public preview will bring a few new methods, and some updates to the existing ones:

PolicyStatusWhat’s new?
SMSUpdatedYou can now manage if users can use SMS for MFA and SSPR. Optionally, you can configure the SMS Sign-in feature.
Microsoft AuthenticatorUpdatedYou can now disable the use of One Time Code on the Microsoft Authenticator app.
Voice CallNewEnable users to use a phone call to a mobile or office phone for MFA and SSPR. Optionally, you can disable the office phone.
Third-party software OATH tokensNewEnable users to use OATH standard-based authenticator apps like Google Authenticator.
Email OTPNewEnable users and guests to use an Email one-time passcode for SSPR.
Temporary Access PassN.A. 
FIDO2 security keyN.A. 
Certificate-based AuthenticationN.A. 

Admins can now define policies based on user groups instead of having a tenant-wide setting. Next, they can also be more specific in what methods and features they allow in their organization.

For example:

  1. Enable SMS for a specific group only.
  2. Disable voice and SMS for administrators, which goes hand in hand with Conditional Access authentication strength (preview)
  3. Enforce the use of the Microsoft Authenticator App and block other authenticator apps like Google Authenticator.
  4. Configure different SSPR and MFA methods for specific personas in your organization.
  5. Limit the use of the TOTP feature in the Microsoft Authenticator app.

As you can see, this feature brings a whole new set of flexibility.

Call for action

In January 2024, the legacy multifactor authentication and self-service password reset policies will be deprecated, and you’ll manage all authentication methods using the new authentication methods policies.

Good to know: the new Authentication Methods policies are evaluated in addition to legacy MFA and SSPR policies (both will be evaluated with OR condition).

Therefore, a new control is introduced where you can migrate your existing policies to the new blade at your own pace. By default, all legacy policies are respected, and the new policies are used for authentication only. During migration, you can use the policies for both SSPR and MFA, while still respecting the legacy policies and finally move over to the other side where legacy policies are ignored.

There is new documentation available on how to migrate your existing legacy policies to the new authentication methods policy. How to migrate to the Authentication methods policy – Azure Active Directory – Microsoft Entra | Microsoft Learn

Ensure you have also enabled the combined registration portal for SSPR and MFA before using the new policies. Microsoft should have already enabled this feature, starting Sept. 30th, 2022, but I still see tenants where this is disabled.

Legacy MFA and SSPR settings

In this private preview, you can disable (almost) all authentication methods from the legacy portal and move over to the new policies.

If you are using Hardware OATH tokens on your tenant, ensure you don’t disable the “Verification code from mobile app or hardware token” from the legacy MFA portal.

“Verification code from mobile app or hardware token” controls 3 authentication methods:

  • Hardware OATH Tokens;
  • Verification code from 3rd party authenticator apps like Google Authenticator;
  • Verification code as part of the Microsoft Authenticator app.

At the time of writing, the public preview doesn’t include Hardware OATH Token policy support. Customers using Hardware OATH tokens on their tenants must not disable “Verification code from mobile app or hardware token” as this will result in users not being able to use hardware tokens.

For the legacy SSPR portal, only Security Questions will continue to be managed on the SSPR blade. A control for Security questions is coming soon, but personally I recommend not to use security questions for password reset.

Once you move to “Migrated”, the SSPR methods required to reset the password can be changed downward, but not upward. If you want to change it later on, you need to move to “Migration In Progress” again before it accepts changes.

“Number of methods chosen is less than number of methods required to reset”

Example – Allow 3rd party Authenticator Apps for a specific group only

To show you how this new feature works, we’ll see if we can limit the use of a 3rd party app to a specific group only. Assuming that you have enabled this feature now, this is a two-step tutorial:

  1. Configure the Third-party software OATH tokens policy.
  2. Disable the method on the legacy MFA portal.

We will start with enabling the Third-party software OATH tokens policy, adding the Allow_Software OATH tokens_3rdPartyApps group to the policy. Now add your test user to the group.

Debra is a member of my test group.

Next, we need to disable the tenant-wide setting. Uncheck the box “Verification code from mobile app or hardware token”.

Now, when Debra tries to register for MFA or SSPR, she can select a 3rd party app, while Megan, who is not a member of the group, cannot.

Since Debra is a member of the Allow_Software OATH tokens_3rdPartyApps group, she can register a third-party app

Megan is not part of the Allow_Software OATH tokens_3rdPartyApps group, so she can only register the Microsoft Authenticator App

Be aware that it can take up to 15 minutes before changes are reflected.

Wrap things up

This preview is a first good step into central management of all SSPR and MFA related methods, which is a welcome new feature. The current situation can be confusing, and is not very flexible. Please reach out to the documentation on Microsoft Learn for more guidance:

How to migrate to the Authentication methods policy – Azure Active Directory – Microsoft Entra | Microsoft Learn
Manage authentication methods – Azure Active Directory – Microsoft Entra | Microsoft Learn

Stay tuned for more news and improvements!

13 thoughts on “Goodbye legacy SSPR and MFA settings. Hello Authentication Methods Policies!”

  1. This is great news – thanks for the post. I’m surprised I haven’t seen any mention of this from MS on either Twitter or the Tech Community blogs yet though.

  2. Pingback: Azure MFA, SSPR, Authn methods – Jacques Dalbera's IT world

  3. Pingback: Goodbye legacy SSPR and MFA settings. Hello Authentication Methods Policies – blog by @janbakker_ – 365forall

  4. Excellent writeup…In your example, you have asked to Uncheck the box “Verification code from mobile app or hardware token”. However, the Microsoft and this article is saying
    “you are using Hardware OATH tokens on your tenant; ensure you don’t disable the “Verification code from mobile app or hardware token” from the legacy MFA portal”
    I’m little confused.

  5. Pingback: Break glass accounts and Azure AD Security Defaults -

  6. New policy makes a lot of noise… After migration, all potentially usable methods work for both: MFA & SSPR. When SSPR requires 2 methods (still set in legacy SSPR policy) then Authenticator with enabled OTP doesn’t satisfy SSPR requirements. From all other available methods for SSPR only SMS makes some sense. But ten SMS will satisfy MFA too. To exclude SMS from MFA we have to create a new Conditional Access policy considering Auth Strength (remember to add to the same policy TAP, WHfB, Aythenticator… otherwise have fun). And MSFT docs don’t provide all the details.
    Not to mention that having a legacy SSPR policy that require 2 methods but no one is checked – looks like misklick rather than expected state of the quite important security policy in the tenant.

  7. Wait, this is supposed to make things simpler? My head is spinning trying to understand this new migration and concurrent mixing of methods. Microsoft loves to confuse and makes things complex.

    1. Tell me about it! Something that was relatively straight forward has now been made difficult. Also from experience it caused me lots of issues for my systems during the migration process. I really don’t like it when MS make things more complicated than it should be which can lead to mistakes.

  8. Pingback: Get started with passkeys in Microsoft 365 -

Leave a Reply

Your email address will not be published. Required fields are marked *