MFA is a critical, if not essential, line of defence for you and your organisation – and Microsoft suggested in 2019, and reinforced that stance in 2023, that this one simple change to user authentication can prevent up to 99.9% of account-based attacks.
With the planned retirement of these legacy policies, it’s time to ensure that the Entra ID Authentication policies have had everything relevant migrated from the legacy policies to ensure the user experience remains consistent throughout.
While this service has been running side-by-side with the modern Entra ID (formerly Azure AD) Authentication Method policies for the last few years and, depending on how long you’ve been invested in the Azure ecosystem, you may be using one or both policy types in your organisation.
Although these policies can co-exist, doing so can add confusion over which policy “wins” in a conflict and risks inconsistent experiences across your users. With this retirement, authentication methods are centralised into Entra ID.
Other MFA implementations to consider, such as Microsoft Security Defaults and Conditional Access (which requires an Entra ID P1 or better license), will apply either a Microsoft standard configuration or your curated bespoke configuration accordingly.
Whilst both configurations will trigger authentication prompts, only Conditional Access will honour your selected authentication method policy.
Past
Previously, you would have had to configure “Per-user MFA” and configure MFA for each user as necessary. You would onboard them gradually onto MFA, initially as optional, and then finally onto enforced.
Depending on how many users are in your organisation, this roll-out could take some time.
You would also need to configure whether to allow app passwords for legacy apps, any trusted IP ranges that waive the requirement for MFA, the verification options available to users such as SMS, voice calls, or app notifications, and the length of time between repeat MFA requests.
Present
Today, in Entra ID, this has been streamlined and improved with a focus on consistency and inclusivity.
No more individual user configurations; it’s now tenant-wide by default – ensuring each account receives a consistent authentication experience when MFA is triggered based on the service MFA has been invoked by (Microsoft Security Defaults, Conditional Access) and that services associated authentication methods.
In addition, the modern policy supports group-based exclusions for almost every setting.
If you need to exclude an account from a particular setting or authentication method, you can do so.
For example: for each method in Authentication method policies you can specify whether it’s enabled at all, whether it’s available to all users or to specific groups of users, in addition to configuration settings that are bespoke to the method selected.
Not only is this more comprehensive in the list of authentication methods compared with the legacy MFA policy, it also is much simpler to configure yet more granular in its configuration.
Many more scenarios are now either far easier to implement, or simply possible where they were not before.
Future
As previously mentioned, both policies can co-exist – but the differences in functionality that we’ve really only just scratched upon in this article means that migrating to Entra ID Authentication Methods will grant you a much more modern, improved, and complete MFA solution than ever before.
Once migrated to Entra ID Authentication Methods, you can start to take advantage of more advanced, secure, phishing-resistant, and password less options such as Windows Hello, Passkeys (FIDO2), and “passwordless” (Microsoft Authenticator) app sign-in.
Some important dates that relate to MFA are as follows: From 15th October 2024, MFA will no longer be optional when accessing Microsoft Entra admin centre, Microsoft Azure portal, and the Microsoft Intune admin centre.
THERE WAS AN OPTION TO POSTPONE THIS UNTIL MARCH 2025 WHICH PROVIDED ADDITIONAL TIME TO IMPLEMENT CONDITIONAL ACCESS. HOWEVER, THIS NEEDED TO HAVE BEEN REQUESTED BY 15TH OCTOBER 2024.
FOR MORE INFO, PLEASE SEE: MANDATORY MICROSOFT ENTRA MULTIFACTOR AUTHENTICATION (MFA) - MICROSOFT ENTRA ID
- In early 2025, this enforcement of MFA will extend to additional Azure services such as Azure CLI, Azure PowerShell, and Infrastructure as Code (IaC) tooling.
- From 30th September 2025, the legacy MFA and SSPR authentication methods will be deprecated.
IMPORTANT: Migrate AHEAD of this date to ensure there is no impact to your user experience.
Closing thoughts
For now, let’s just consider a “lift and shift” migration. What do you need to consider?
A like for like migration is straight forward and, although there is a wizard available to help you take your existing configuration and put it into Entra ID, we'd start with reviewing your existing legacy MFA and SSPR configuration to ensure that the migration is reflective of the legacy configuration.
With these settings noted, it’s simple to either manually re-create this configuration in Entra ID Authentication – or just to perform the automated migration and perform a review of the suggested configuration.
For those tenants that have been around some time, and likely had multiple MFA configurations over its lifetime, it would be wise to review the combined configuration of MFA throughout the Microsoft cloud.
Some questions to start you off:
- Do you have security defaults enabled, or do you use conditional access policies?
- Do you have an existing configuration in Entra ID that you will need to consolidate?
- Does Entra ID Authentication offer scenarios that were not possible before?
With these findings in-hand, you can now decide what your next steps are to strengthen authentication across the Microsoft cloud.
