At the end of last year Microsoft has launched a public preview called “Authentication Methods Policy Convergence.”
Current situation
What do we have today? There are multiple portals to manage and setup or tweak your settings.
First, we have the legacy multi-factor authentication portal (https://aka.ms/MFAPortal), where we can manage the MFA methods and trusted IP’s.
Next, we have the blade in the Azure portal, where we can configure the SSPR methods.
Lastly, we have the newest kid on the block: the Authentication methods policy blade.
So three portals to configure settings for SSPR and MFA. Can it be any better?
What’s new?
With the Authentication Methods Policy Convergence, Microsoft is consolidating the configuration of MFA and SSPR methods into Authentication Methods Policies. That already has two huge benefits:
- One portal to rule them all.
- More flexibility and granularity.
| Policy | Status | What’s new? |
|---|---|---|
| SMS | Updated | You can now manage if users can use SMS for MFA and SSPR. Optionally, you can configure the SMS Sign-in feature. |
| Microsoft Authenticator | Updated | You can now disable the use of One Time Code on the Microsoft Authenticator app. |
| Voice Call | New | Enable users to use a phone call to a mobile or office phone for MFA and SSPR. Optionally, you can disable the office phone. |
| Third-party software OATH tokens | New | Enable users to use OATH standard-based authenticator apps like Google Authenticator. |
| Email OTP | New | Enable users and guests to use an Email one-time passcode for SSPR. |
| Temporary Access Pass | N.A. | |
| FIDO2 security key | N.A. | |
| Certificate-based Authentication | N.A. |
Admins can now define policies based on user groups instead of having a tenant-wide setting. Next, they can also be more specific in what methods and features they allow in their organization.
For example:
- Enable SMS for a specific group only.
- Disable voice and SMS for administrators, which goes hand in hand with Conditional Access authentication strength (preview)
- Enforce the use of the Microsoft Authenticator App and block other authenticator apps like Google Authenticator.
- Configure different SSPR and MFA methods for specific personas in your organization.
- Limit the use of the TOTP feature in the Microsoft Authenticator app.
As you can see, this feature brings a whole new set of flexibility.
Get in action, now!
In January 2024, the legacy multifactor authentication and self-service password reset policies will be deprecated, and you’ll manage all authentication methods using the new authentication methods policies.
Good to know: the new Authentication Methods policies are evaluated in addition to legacy MFA and SSPR policies (both will be evaluated with OR condition).
Therefore, a new control is introduced where you can migrate your existing policies to the new blade at your own pace. By default, all legacy policies are respected, and the new policies are used for authentication only. During migration, you can use the policies for both SSPR and MFA, while still respecting the legacy policies and finally move over to the other side where legacy policies are ignored.
There is new documentation available on how to migrate your existing legacy policies to the new authentication methods policy. How to migrate to the Authentication methods policy – Azure Active Directory – Microsoft Entra | Microsoft Learn
Ensure you have also enabled the combined registration portal for SSPR and MFA before using the new policies. Microsoft should have already enabled this feature, starting Sept. 30th, 2022, but there are still tenants where this is disabled. If you cannot see the option, it is enabled!
Legacy MFA and SSPR settings
You can disable (almost) all authentication methods from the legacy portal and move over to the new policies.
If you are using Hardware OATH tokens on your tenant, ensure you don’t disable the “Verification code from mobile app or hardware token” from the legacy MFA portal.
“Verification code from mobile app or hardware token” controls 3 authentication methods:
- Hardware OATH Tokens;
- Verification code from 3rd party authenticator apps like Google Authenticator;
- Verification code as part of the Microsoft Authenticator app.
At the time of writing, the public preview doesn’t include Hardware OATH Token policy support. Customers using Hardware OATH tokens on their tenants must not disable “Verification code from mobile app or hardware token” as this will result in users not being able to use hardware tokens.
For the legacy SSPR portal, only Security Questions will continue to be managed on the SSPR blade. A control for Security questions is coming soon, but personally I recommend not to use security questions for password reset.
Once you move to “Migrated”, the SSPR methods required to reset the password can be changed downward, but not upward. If you want to change it later on, you need to move to “Migration In Progress” again before it accepts changes.
“Number of methods chosen is less than number of methods required to reset”
Example – Allow 3rd party Authenticator Apps for a specific group only
To show you how this new feature works, we’ll see if we can limit the use of a 3rd party app to a specific group only. Assuming that you have enabled this feature now, this is a two-step tutorial:
- Configure the Third-party software OATH tokens policy.
- Disable the method on the legacy MFA portal.
We will start with enabling the Third-party software OATH tokens policy, adding the Allow_Software OATH tokens_3rdPartyApps group to the policy. Now add your test user to the group.
Debra is a member of my test group.
Next, we need to disable the tenant-wide setting. Uncheck the box “Verification code from mobile app or hardware token”.
Now, when Debra tries to register for MFA or SSPR, she can select a 3rd party app, while Megan, who is not a member of the group, cannot.
Be aware that it can take up to 15 minutes before changes are reflected.