Another deadline, another deep dive! Legacy MFA authentication methods deprecation.

In the realm of Multi-Factor Authentication (MFA) within Entra ID, numerous modifications have been implemented and announced as incoming changes. The topic of this post is by itself not a new announcement, but it can be very confusing to understand how it works and what the consequences are as this depends heavily on your current setup.

The change:

On September 30 2025 the legacy multifactor authentication and self-service password reset policies will be forcefully deprecated and replaced with Authentication methods policies. This means that you will have a unified policy to control the authentication methods available for your users. The details can be found here.

Did that make sense to you? Don’t worry if it didn’t. I needed to read it at least twice before I understood what they meant. So the short summery is:

These settings from Self-Service Password Reset (SSPR) and legacy MFA service (per-user MFA).

Will be converged into this list of policies under “Authentication Methods” in Entra.

❗It also looks like all new tenants are now provisioned with this migration completed and without the option to roll back to pre-migration. This made it slightly harder for me to to proper testing of this procedure for this blog post. Your user experience may differ slightly as some settings may not have reached all tenants yet.

The important details:

You’ve all heard the saying “The devil is in the details” and this change is no different. One important detail is that it is only the settings for authentication methods which will be deprecated and replaced by authentication method policies. So in the legacy MFA portal, you will still be able to set a per-user MFA (disabled/enabled/enforced) and you can allow app passwords, exclude MFA from certain IPs and remember MFA for X number of days. These are settings to avoid, as frankly they are horribly outdated! Both Microsoft, myself (and many others) strongly recommend to adapt the Zero Trust framework in your MFA design, and the settings just mentioned do not fit the Zero Trust framework at all.

Which MFA method can do what?

Below is a table of all methods and where they can be used.

What about Per-User MFA?

In the legacy MFA portal you can set MFA individually on a per-user basis to either disabled, enabled or enforced.

• Disabled – Default state, no MFA protection
• Enabled – The user can choose to enroll MFA methods on his/her account. No MFA required
• Enforced – The user must perform MFA (and app password for apps using legacy protocols)

This was the way to implement MFA protection before Conditional Access was a thing, and this is a manual protection without any evaluation of the login. Just a flat and unconditional MFA requirement. Do yourself a favor: Don’t use these settings, leave them at disabled and let Conditional Access handle MFA requirements. I’m curious if these setting will affect the risk-evaluation (in Identity Protection) of the user sign-in into Entra ID and how, but I haven’t found any information specific to this scenario.

What about Trusted IPs?

This is one of the settings I wish didn’t exist (and it kinda doesn’t if you read below). The Trusted IPs list lets your specify networks for skipping Multifactor Authentication all together. Setting up “hard exceptions” like this from your MFA protection in M365 is a huge security risk and it is absolutely not something you should enable just because “it’s more convenient”.

In some rare circumstances you may need to exclude MFA, but it should always be for specific accounts under specific circumstances and these accounts should always have alternative security features enabled. Excluding for networks like this must be a LAST resort when all other security measures fail.

A very interesting observation: In my two test-tenants this setting was removed from the portal after I completed the migration to authentication policies, and it did not return when I reversed the migration back to SSPR/per-user MFA again.

What about “remember MFA on this device”?

This setting brings up this additional option on the MFA screen when a user logs in:

This setting makes me cringe! To remember MFA on certain devices does not belong at all in identity security in my opinion, and I am quite frankly disappointed that the people in Microsoft have not removed this feature yet. Trusting devices so you can skip MFA for X number of days is the polar opposite of Zero Trust!

In short: If you value security in your M365 environment, DO NOT USE!

Authentication Methods policy vs Conditional Access policy

I know these settings in Entra seem similar and I know some people have them confused, so I will try to highlight the difference:

• Authentication methods (link) determine which authentication methods are available for the end-user. So if you for example disable SMS in Authentication Methods, then no users in the tenant can register or use SMS as an MFA method for their account.

• Conditional Access (link) determine which requirements should be applied to any login to the tenant. For example: Should user be required to perform MFA, and if so which MFA methods do we allow?

This means that these settings must align!! If you are not careful, you could put users into the situation where they are unable to log in. Imagine if users are required, from Conditional Access, to perform MFA using a specific method like FIDO2, but FIDO2 is unavailable to the same users because it is not enabled in Authentication methods. The users will not be able to perform the MFA method Conditional Access requires, locking them out of the tenant.

Migrating to Authentication method policies

Prepare

First of all you need to gain an overview over which methods are available for MFA and SSPR in the legacy portals and make sure the same methods are available in the “Authentication Methods” portal.

Migrate

This step has undergone some big changes very recently! Earlier you needed to manually de-select all methods in the per-user MFA and SSPR, which are encircled in the picture above. But in my test-tenants I no longer need to do this before I continue with the migration. So now it seems you can simply switch over manually to complete the migration (“A” in the screenshot below). Also there’s a new option in the portal: “Begin automated guide” (“B” in the screenshot below) which automates this process for you instead of doing it manually. Not that this was a difficult task, but an automated guide is nice regardless.

The Automated guide provides link to Microsoft’s article of the migration, enables the methods in the new portal for you automatically (based on your settings in the legacy portals), and you can customize these settings if you wish. They also throw in recommendation to use Passkeys 😍.

The status should be changed to “Complete” and then you’re done.

Combining the old and the new

Since the old settings, apart from authentication methods, are still valid you may wonder: How do these settings work when combined with Conditional Access policies after the migration has been completed? That’s a great question which made me sit down and do some testing.

So my quick testing gave the following results:

• Per-User MFA (legacy portal): Enforced – Users with status “Enforced” will always be prompted for MFA regardless of what Conditional Access policies say. As mention the consequences are unknown to me, as how this affects the machine learning tools at Microsoft and their risk assessment.
• Trusted IPs – In my testing this setting was overruled by Conditional Access policies, and as mentioned: This option completely disappeared after completing the migration (in my test-tenants at least).
• Remember multi-factor authentication on trusted device – This setting still allows the end-user to skip MFA on their logins for the specified number of days. MFA requirements from Conditional Access policies are overruled.

Conclusion

The September 30, 2025, deadline may seem distant, yet it’s approaching swiftly, bringing with it the necessity for migration. I recommend everyone to get started as soon as possible to avoid last-minute rushes and ensure one less concern on your list.

Take this chance to streamline your security settings. Eliminate individual MFA configurations, trusted IPs, and particularly the “remember multi-factor authentication on trusted devices” feature. In the realm of M365, safeguarding identity is paramount, and MFA stands as your primary line of defense.

Thank you everyone for reading this post. Keep an eye out for upcoming blog entries from us at agderinthe.cloud, and remember you can subscribe so you don’t miss any new posts from us.