Entra ID – Authentication methods

First, a little background information of what I`m doing here. Starting from September 30th, 2025 (and as you get from the date, we are not in any hurry here), the existing multifactor authentication and self-service password reset policies will no longer be supported. Instead, you’ll handle all authentication methods through the authentication methods policy.

From the Entra portal we can now start the process of moving from the “old ways” to set this to the new and shiny (not that new, but in this scenario, it is new 🙂) Authentication methods overview and settings. This new page gives us full control of all authentication methods that are available for the users. We can for example easily deactivate for example SMS or Third-party software OATH tokens for all users of for some users.

This portal will also give us flexibility to start testing and proof-of-concepting new authentication features that you may not have started to use yet.

When we go over to the “Authentication methods” portal we get migration help as well and this control allows you to smoothly transition from the older policies to the new, unified policy. It’s essential to stay informed about this change and manage your migration effectively.

As I mentioned earlier, we are not in a hurry here, but hey – why not just do it and transition over to the new unified policy right away.

By doing it you gain more flexibility and only one place to configure these settings. Before we migrate, we have several places where we need to do changes for authentication methods if we are to do any changes. I highly recommend migrating to the new unified policy if you are planning to do changes already.

So where are we managing these settings today?

  • Authentication methods
  • Password reset (SSPR)
  • Legacy MFA Policy (per-user MFA)

Before we start this migration it’s smart to take note of how it’s configured today. Head into each of the settings and take note on how it’s configured. If you already have migrated away from per-user MFA, then you only need to take note of Password reset (SSPR) and of course if you are not using Password reset but per-user then take note of per-user MFA settings insted.

per-users mfa settings: https://account.activedirectory.windowsazure.com/UserManagement/MfaSettings.aspx?tenantId=681e41cd-3aea-474d-9e84-92c95cba16c1&culture=en-us&requestInitiatedContext=users

password reset: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/PasswordResetMenuBlade/~/AuthenticationMethods/fromNav/

Now that we have taken note of the settings here – we can change the migration setting from the Authentication Methods and from here we have three options available.

  • Pre-migration
  • Migration in Progress
  • Migration complete

There is no automation here, so we need to change the migration stage our self as we go along with the migration.

So, what we do know is that we set the migration state to “Migration in Progress” and start matching all settings so that we are covering all settings within the Authentication methods.

So now we see that I’m supporting all methods there where active in the two settings that we took notes from and therefore I’m now ready to complete the migration process and fully rely on the Authentication methods settings that are set in this unified policy. Before we can set the migration process to “Complete” we need to disable the settings within legacy MFA policy (Per-user MFA) and within the Password reset (SSPR) settings. When that’s done the last step is to complete the migration process by moving the state over to “Migration complete”.

What I now have achieved is that there is less complexity regarding the authentication methods that earlier where set all over the place – but now I manage them from one place. So easy for me as an administrator and also so easy for the helpdesk or enterprise support team to be able to see what settings are set and so on.