In today's threat landscape, passwords alone are no longer sufficient to protect access to cloud systems. Enter Multifactor Authentication (MFA): a security mechanism that requires users to present two or more independent validation factors—typically something you know (e.g. password), something you have (e.g. a mobile authenticator or hardware key), or something you are (e.g. biometric data)—before granting access. MFA dramatically strengthens protection against credential-based attacks, reducing the risk of unauthorized access even if passwords are compromised.
Way back when, Azure Active Directory (Azure AD) was at the time Microsoft’s cloud-based identity and access platform introduced native MFA capabilities in, marking a significant step up in enterprise-grade security. This initial offering enabled organizations to require users to validate their identity through phone calls, SMS one-time codes. Subsequently the Microsoft Authenticator app became a thing. Over time, Azure AD expanded its MFA feature set to offer more secure and user-friendly methods, including FIDO2 security keys, certificate-based and passkey (phishing-resistant) authentication.
The initial solution was enabled by the acquisition of PhoneFactor in 2012. This was developed in the the "Active Authentication" MFA product. Initially MFA was a standalone service with its own licensing etc. and there was an on-premises MFA server that could be deployed. Then in 2013 MFA was bundled into Office 365 (prior to the Microsoft 365 product). Note that initially only administrators could use MFA, and it was in 2014 when MFA support for all users went GA. App Passwords also became a thing at this point, so users who were still on Office 2010 had a solution that was compatible (kind of) with MFA. An App Password is a 16-character randomly generated password that can be used with an Office client application as a way of increasing security in lieu of the second authentication factor.
Support was added for Modern Authentication in Office 2013 , and the world rejoyced! Though having to enable the ADAL library and deal with Modern Auth and Outlook Autodiscover was not always fun...
In July 2023, Microsoft strategically rebranded Azure AD to Microsoft Entra ID, aligning it under the broader Microsoft Entra identity suite. Microsoft has continued to invest in MFA.
Well, that's a brief review of the last 10+ years of Azure AD/Entra ID! With all that said, we need to move with the times and move to Conditional Access, Zero Trust and the new authentication method policies in Entra ID.
The days of per-user MFA set with a MSOL PowerShell cmdlet are drawing to a close.
Retirement of Authentication Methods in Legacy MFA & SSPR Policies
As announced in March 2023, the ability to manage authentication methods in the legacy policies is being removed.
Retirement of managing authentication methods in legacy Multifactor Authentication (MFA) & Self-Service Password Reset (SSPR) policy
Beginning September 30, 2024, we will no longer allow authentication methods to be managed in the legacy MFA and SSPR policies. Organizations should migrate their methods to the converged authentication methods policy where methods can be managed centrally for all authentication scenarios including passwordless, multi-factor authentication and self-service password reset. Learn more at Manage authentication methods for Azure AD.
This update is also in the Entra portal and M365 Message Centre. For example under MC678069.
Note that the timing on the depreciation was changed. The current value of 30th September 2025 is the date of the final extension. Migration should be completed will in advance of this date. The process to migrate is straightforward, and is documented in the Migration between policies section and also has a dedicate page :
You will need to map the existing MFA methods to new authentication methods using this table:
And the legacy SSPR methods using this table:
Please read the aforementioned documentation for all of the details on the migration process.
Update: a wizard was added to help with the migration.
Tips
Some thoughts and items that may assist with this process. This list will grow over time as we approach September 2025.
- Security Questions are still managed in the legacy portal as of today. Eventually they will be migrated.
- Ideally you use MFA to perform SSPR rather than rely on weak questions.
- Initially you could scope an authentication method to individual users. That was removed and groups must be used.
- Streamline the number of groups added to an authentication policy as there is limited space available. If the authentication methods policy exceeds 20 KB then you may run into an issue.
- Allow time for the settings to propagate in the back end. DO NOT rapidly move from Pre-Migration, to Migration in Progress and selecting Migration Complete. Allow at least 5 minutes for settings to propagate at each stage of the migration process. This happens organically in production, well typically, but in a lab don't go too fast. Let the settings propogate.
- Ensure you review how your users are currently using MFA. Look at the MFA reports in Entra. For example, users may be using Microsoft Authenticator as a guest account in a different tenant. Also consider if software OATH or hardware OATH tokens are is use.
- You may chose a particular all authentication method for all users. Then rein it back afterwards.
- Ensure you review the settings under the configure option for each authentication method.
- For SMS there is an option to use SMS for sign-in. Note that this is a particular use case, as the user will use the phone number to sign in. No password no second factor. Even with that option disabled users can still use SMS as the second factor. Sure a MFA requirement in Conditional Acccess will block this, but why have it enabled to start with? I can imaging that's going to trip people up. Think of this as an option for front line workers that only have a phone. Not intented for the an Information Worker persona.
Legacy MFA Portal
For posterity, this is an example of how Azure AD used to look in the year 2015. Note that we are on the service settings tab, yes it is there and hidden in plain sight!
Legacy MFPA portal can be accessed at: https://entra.microsoft.com/#view/Microsoft_AAD_IAM/MultifactorAuthenticationConfig.ReactView/tabId/users
By default users could generate app passwords, there were no trusted IPs entered and all of the four MFA options were enabled. These MFA options operate at the tenant level. The option is either enabled for all users or no users. There is no granularity.
While it may look like there are trusted IPs entered, that is just a sample to show you the notation. When you click into the box the CIDR examples disappear.
Zooming into the MFA options we can see that the telephony methods have been disabled for all users in this tenant. By default all were enabled.
If we change to the users tab, then we can perform the per-user MFA enablement. This was a thing pre-conditional access. Realistically we should be using conditional access policies nowadays. They offer so much more control and flexibility.
Note that Lisa is enabled for per-user MFA.
If we use the option to enable a user, the UI would look like this. The user would then complete the MFA registration process.
Then if we were then to enforce MFA for that user the following would be presented:
Note that the dashboard has a filter to only show users that have per-user MFA enforced’.
Legacy MFA Portal Makeover
While none of the functionality in the legacy MFA portal was changed, it did get a cosmetic makeover. This made it look less like a 10 year old portal.
Cheers,
Rhoderick
