I’ve got some exciting news to share today. Microsoft has launched a public preview called “Authentication Methods Policy Convergence.” I was part of the private preview program, and I’m very happy to see this feature going public. In this post, I will give you a brief introduction to this new feature and explain why this is such a big deal.
Current situation
A while back, I wrote this post where I explained that the SSPR and MFA settings are very intertwined and how you could tweak the settings to your liking by experimenting with different variations of settings. However, settings are managed in different portals and without comprehensive programmatic control. Let’s see what we have today:
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. What’s not to like? đ
What’s new?
With the Authentication Methods Policy Convergence preview, Microsoft is consolidating the configuration of MFA and SSPR methods into Authentication Methods Policies. That already has two significant benefits:
- One portal to rule them all.
- More flexibility and granularity.
This public preview will bring a few new methods, and some updates to the existing ones:
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.
Call for action
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 I still see tenants where this is disabled.
Legacy MFA and SSPR settings
In this private preview, 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.
Wrap things up
This preview is a first good step into central management of all SSPR and MFA related methods, which is a welcome new feature. The current situation can be confusing, and is not very flexible. Please reach out to the documentation on Microsoft Learn for more guidance:
How to migrate to the Authentication methods policy – Azure Active Directory – Microsoft Entra | Microsoft Learn
Manage authentication methods – Azure Active Directory – Microsoft Entra | Microsoft Learn
Stay tuned for more news and improvements!
This is great news – thanks for the post. I’m surprised I haven’t seen any mention of this from MS on either Twitter or the Tech Community blogs yet though.
Pingback: Azure MFA, SSPR, Authn methods – Jacques Dalbera's IT world
Pingback: Goodbye legacy SSPR and MFA settings. Hello Authentication Methods Policies – blog by @janbakker_ – 365forall
Excellent writeup…In your example, you have asked to Uncheck the box âVerification code from mobile app or hardware tokenâ. However, the Microsoft and this article is saying
“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”
I’m little confused.
Hi BT, I’m just not using any Hardware OATH tokens in my tenant, so I can uncheck that box without any issues đ
https://learn.microsoft.com/en-us/azure/active-directory/authentication/concept-authentication-oath-tokens#oath-hardware-tokens-preview
Great, thx for the clarification
Pingback: Break glass accounts and Azure AD Security Defaults - JanBakker.tech
New policy makes a lot of noise… After migration, all potentially usable methods work for both: MFA & SSPR. When SSPR requires 2 methods (still set in legacy SSPR policy) then Authenticator with enabled OTP doesnât satisfy SSPR requirements. From all other available methods for SSPR only SMS makes some sense. But ten SMS will satisfy MFA too. To exclude SMS from MFA we have to create a new Conditional Access policy considering Auth Strength (remember to add to the same policy TAP, WHfB, Aythenticator⌠otherwise have fun). And MSFT docs donât provide all the details.
Not to mention that having a legacy SSPR policy that require 2 methods but no one is checked â looks like misklick rather than expected state of the quite important security policy in the tenant.
Good point. SMS and policy overall are fine but on the other hand a little bit of custom scripting may help too. I mean why not Python scripts am I right?
Wait, this is supposed to make things simpler? My head is spinning trying to understand this new migration and concurrent mixing of methods. Microsoft loves to confuse and makes things complex.
Tell me about it! Something that was relatively straight forward has now been made difficult. Also from experience it caused me lots of issues for my systems during the migration process. I really don’t like it when MS make things more complicated than it should be which can lead to mistakes.
Excellent Article! Thank You for writing this!
Pingback: Get started with passkeys in Microsoft 365 - JanBakker.tech
Pingback: Selfservice for hardware (OATH) tokens in Entra ID. - JanBakker.tech
Thanks for the writeup!
Now questions… đ
What about the other items on the MFA Legacy page?
– App passwords
Guess this is deprecated as it only supports basic authentication? I would disable this but can we expect this setting to be deprecated as well?
– Trusted IPs
Can migrate to Conditional Access but what about deprecation in the legacy MFA panel?
Can you mix CA and this setting? What takes precedence?
– Remember multifactor authentication on trusted device
It seems to me this is still the only location to set such setting? Guess this remains on this page?
Sorry for asking but next to the deprecation of the MFA settings, mentioned settings are also a part of the legacy MFA settings so it makes me worried if maybe also included in the scope of migration.
All good questions. I’m a little short on time rn, so I guess this is food for another blog post. Stay tuned.