Migrate MFA and SSPR Policies to Authentication Methods Policy in Microsoft Entra ID

On Day 4 of Cybersecurity awareness month, learn to protect your organization from SIM intercept attacks today. Stay tuned for the upcoming blogs in M365 Cybersecurity blog series.   

Is Your Organization Facing SIM Intercept Attacks? 

In our recent assessment, we’ve uncovered a concerning truth: approximately a quarter of the organizations have fallen prey to SIM intercept attacks (SIM swapping attacks). Are you one of those caught in such attacks? It all stems from one root cause – the use of less secure multi-factor authentication methods. 

Upon delving deeper, it became crystal clear that this vulnerability primarily lurked within the legacy MFA and Self-Service Password Reset (SSPR) policies.

What is Legacy MFA and SSPR Policies? 

MFA and SSPR policies represent legacy(old) methods for managing the MFA methods for authentication and password resets.  

• These approaches are like a one-size-fits-all strategy, applied uniformly to all Microsoft 365 users. For example, once a less secure MFA method like SMS or voice call is configured, it is enforced for all users in Microsoft 365.  
• So, they lack the ability to provide granular control, and admins can’t track users’ authentication method usage. 

This limitation opens the door to the heightened risk of SIM intercept attacks, putting organizations in the hands of attackers. 

How to Escape from SIM Intercept Attacks? 

To eliminate these types of attacks on your organization, it’s crucial to adopt strong MFA methods. You might wonder how to achieve this since legacy and SSPR policies can’t configure robust MFA methods or fine-tune MFA settings. However, there’s no need to worry! The solution lies in implementing the “Authentication methods policy”. 

By leveraging the Authentication methods policy, you can introduce modern MFA methods and granular MFA requirement for different users, enhancing security even further. So, it would be better to migrate from legacy MFA and SSPR policies to the Authentication methods policy for enhanced Microsoft 365 security. 

So, let’s dive into the blog to know the steps on how to migrate MFA and SSPR policies to Authentication methods policy in MS Entra ID.  

How to Migrate from MFA and SSPR to Authentication Methods Policy? 

Here’s a concise overview of the MFA migration progress:  

• First of all, admins need to document all the MFA and SSPR settings from their Entra ID carefully. Then, with all these details in hand, admins can proceed to update their authentication methods policy accordingly. Once done, admins can seamlessly manage all MFA methods via the Authentication methods policy itself!. 
   

To gain a clear understanding of the MFA migration process, we’ve provided you with a clear-cut step here. Let’s see every step and how to perform it in detail. 

1. Audit Existing MFA and SSPR Policy Settings 
2. Manage migrating to Authentication methods policy in Azure AD 
3. Update the MFA settings in Authentication methods policy 
4. Finish Migration from the MFA and SSPR policy to Authentication Method Policy 

Check Existing MFA and SSPR Policy Settings 

Why is it crucial to review each policy, you might ask? While it may seem like an extra step, this stage is necessary, as the entire MFA migration process hinges on it!  

Your task in this step is to assess and document the authentication methods currently active in these policies, along with their specific configurations. This MFA policy assessment is essential because you’ll need to replicate these MFA settings within the Authentication methods policy.  

1. Review the Legacy Multi-factor Authentication Settings 

Microsoft Entra admin center → Users → All users → Per-user MFA → service settings (Appears at the top next to users option) 

Here you need to note down whether the following authentication methods are enabled/ disabled for the users. 

✅ Call to phone 
✅ Text message to the phone 
✅ Notification through a mobile app 
✅ Verification code from the mobile app or hardware token 

2. Review the Self-service Password Reset Policy Settings 

Now that you’re done with noting down the legacy MFA settings, next you can move to review the legacy SSPR policies. 

Microsoft Azure → Microsoft Entra ID → Users → Password reset → Authentication methods. 

Once there, make sure to: 
✅Document the Self-Service Password Reset status (Enabled/Disabled). 

• If it’s enabled, record the specific Microsoft 365 users and groups to which it was applied. 

✅Then, note the number of available password reset methods for users. 
✅Also, check the MFA methods accessible to Microsoft 365 users. 
 

3. Review the Azure AD Authentication Methods Policy 
   
   Note: If you haven’t configured the Authentication methods policy yet, you can skip this step. 
   
    Microsoft Entra admin center → Protection → Authentication methods → Policies 
   
   In this phase, make sure to:  
   
   ✅ Document the configurations of the other MFA methods that were not present in the legacy MFA and SSPR polices.
   ✅ Take note of the M365 users and groups configured for the identified MFA methods. 
   
   

Manage Migration to Authentication Method Policy in Entra ID 

Now that you’ve thoroughly reviewed your authentication methods, it’s time to take the crucial next step of starting the migration process. So, to begin the MFA migration process, navigate to the path below. 

Microsoft Entra admin center → Protection → Authentication methods → Policies → Manage migration. 

On reaching the page, you will see three different migration choices to pick from, they are: 

Pre-migration: When this option is set, the Authentication methods policy handles authentication while respecting legacy policy settings. 

Migration in Progress: This option makes the Authentication methods policy handles authentication and SSPR while respecting legacy policy settings. 

Migration Complete: This option allows the Authentication methods policy to manage both authentication and SSPR, leaving behind the legacy policy settings disabled! 

So, now to kick things off, choose the “Migration in progress” option and proceed to update the Authentication methods policy to match the legacy and SSPR MFA settings. 

Then, proceed to update the Authentication methods policy to match the legacy and SSPR MFA settings.  

Tip: Keep in mind that there might be mismatches between methods in different policies, so make your decisions accordingly 💯.  

Three Possible Cases in the MFA Update Process  

Case 1: If an authentication method is configured in both MFA and SSPR policies 

• In such cases, it’s clear that this method is meant to be used in both scenarios. Therefore, you should enable the MFA method in the Authentication methods policy without any doubt. 

Case 2: MFA method that is not configured in either the MFA or SSPR policy 

• In this case, it’s not designated for any specific authentication or password reset use, so you can exclude it from your policy. 

Case 3: MFA method enabled in only one legacy policy 

• Here, you need to make a decision based on your specific requirements. Keep in mind that if you enable this authentication method, it will be used for both authentication and password reset cases.  

To help you update the policies successfully, we’ve illustrated three scenarios that arise when configuring MS Authenticator within the Authentication Methods policy. 

Update the MFA Settings in Authentication Method Policy 

Here, we have given you some examples of updating the MFA methods in Authentication methods policy. 

Configure SMS and Voice Call MFA in Authentication Methods Policy 

A) If you have enabled SMS and voice calls MFA in legacy MFA settings, you can configure the same in the Authentication methods policy.  

B) But the MFA settings in SSPR are to be taken into consideration. For example, 

1. If you have “Mobile Phones” enabled for MFA in your SSPR Policy: 
   • Action: Configure both SMS and Voice Call MFA methods. 
   • Reason: This setup ensures that users with mobile phones can utilize both SMS and voice call MFA methods for password resets. 

2. If you have “Office Phones” enabled for MFA in your SSPR Policy: 
   • Action: Configure Voice Call MFA method. 
   • Reason: Users with office phones should have the option to use voice call MFA for password resets.  

Configure Microsoft Authenticator MFA in Authentication Methods Policy 

1. If Notification through Mobile App is enabled in legacy MFA policy and SSPR. 

Action in Authentication method policy: Enable Microsoft Authenticator for all users and set it to “Any” to allow either push notifications or passwordless authentication. For added security, you can enable MFA number matching, geographic location display features for users. 

2. If Verification Code from Mobile App or Hardware Token is enabled in legacy MFA policy and SSPR. 

Action in authentication method policy: Enable Microsoft Authenticator for all users and set “Allow use of Microsoft Authenticator OTP” to Yes. 

Finish Migration from the MFA and SSPR policy to Authentication Method Policy 

After updating the MFA methods in the Authentication methods policy, it’s essential to revisit both the legacy MFA and SSPR policies once again.  

If you have ensured that everything was configured perfectly in the Authentication methods policy, you can then proceed to remove the configured MFA methods one by one in the legacy MFA settings.  

• After each removal, it’s important to thoroughly test the configuration to ensure that it functions as expected. 
• Once you are satisfied with the functionality and have confirmed that the new Authentication methods policy is working seamlessly, you can update the Migration status to “Migration complete” as indicated below. 

Benefits of Migrating to Authentication Methods Policy 

Completed the migration process? Then discover the benefits you can gain with the Authentication Methods Policy. 

Tightened Microsoft 365 Security: Rather than requiring less secure MFA methods, you can ensure that users authenticate using a robust combination of MFA methods by utilizing Authentication strength in Conditional Access policies. This granular approach plays a significant role in mitigating MFA attacks within the organization. 

Granular Control: Once an authentication method is configured in MFA and SSPR policy, it is applied universally to all users without granularity. However, the Authentication methods policy is the one where you can fine-tune MFA settings for specific users and groups. 

Centralized Management: The Authentication Method policy eliminates the need to juggle between portals, enabling centralized management of both legacy and SSPR policy settings under a single console. 

Final Deadline for Migration to Authentication Methods Policy is Now September 30, 2025 

Microsoft recommends transitioning to the Authentication methods policy as they plan to deprecate legacy MFA and SSPR policies. Originally, they Microsoft slated the deprecation of legacy MFA and SSPR settings on September 30, 2024.  

However, as per the recent message center news MC678069, Microsoft has planned to deprecate the SSPR and MFA policies by September 30th, 2025. 

This change has left many wondering about the reasons behind it. From my perspective, it appears that this migration hasn’t been adopted by many organizations as a security measure just yet! Given a bit more time can leave a chance to unlock its true worth and commence the migration to the Authentication Methods Policy. What about your thoughts? 
 

Key Takeaway 

Therefore, making the move to the Authentication methods Policy marks a giant leap toward building your organization’s security through modern authentication practices. So, make your best move now and keep the attackers handcuffed! 
 

Security used to be an inconvenience sometimes, but now it’s a necessity all the time 
  -Martina Navratilova 

I hope this blog brings you more information about migrating to the Authentication methods policy. Furthermore, feel free to reach out to us in the comment section for further assistance.