Blog Post

Microsoft Entra Blog
3 MIN READ

Modernizing Authentication Management

Alex Weinert's avatar
Alex Weinert
Icon for Microsoft rankMicrosoft
May 09, 2023

We’re thrilled to announce two key updates to how you manage your authentication experiences! The General Availability of Converged Authentication Methods and Public Preview of a modernized version of multifactor authentication (MFA) Fraud Alert. 

 

The General Availability of Converged Authentication Methods allows all methods used for authentication and password reset to be centrally managed and with more control, providing the ability to target groups of users.  

 

The Public Preview of modern MFA Fraud Alert brings the configuration into the authentication methods policy and integrates this user-reported signal of suspicious MFA prompts with Identity protection. 

 

Converged Authentication Methods 

Historically, methods had to be managed separately for MFA and self-service password reset. Now, they can both be managed in one policy alongside passwordless methods like FIDO2 security keys and certificate-based authentication. Newly added methods include SMS, Voice Calls, Third-party Software OATH, and Email OTP.  

 

 

 

Methods can now be managed more granularly, with the option to enable them for specific groups of users instead of all users and the ability to exclude groups of users from being targeted. This means you can perform actions like trial methods with pilot groups and limit lower security methods like SMS and Voice to smaller groups of users. 

 

 

 

We’ve also added a migration control to help you migrate methods from the legacy MFA and self-service password reset policies to the authentication methods policy. The control lets you move and test methods individually, before having to disable methods in the legacy policies.  

 

 

 
Later in 2024 we’ll be deprecating the ability to manage authentication methods in the legacy policies. As you migrate, we recommend stepping up your security posture by moving away from SMS and Voice , and enabling more secure methods like Microsoft Authenticator and FIDO2 Security keys, if you haven’t already.  

 

Learn more about managing authentication methods and migrating to the authentication methods policy, and migrate ASAP! 

 

Report Suspicious Activity 

Azure Active Directory (Azure AD) has had the MFA Fraud Alert feature, which enabled users to report suspicious MFA prompts they received on the Microsoft Authenticator app or via phone. Users had the option to be added to a block list where the user would no longer receive MFA prompts until removed, a manual task for admins. Administration of Fraud Alert and the blocklist all required Global Admin privileges. We’ve modernized Fraud Alert with Report Suspicious Activity, moving the configuration for the feature to the authentication methods policy to enable configuration from the same location as other authentication related settings. Now we’ve integrated the alert events with Identity Protection for more comprehensive and configurable action once a user reports a prompt. 

 

You can enable Report Suspicious Activity, and target either all of your users or an initial test group, via the new Settings in the Authentication methods UX, or via the authentication methods MSGraph API. 

 

 

 

Once enabled, if a user reports a MFA phone app push notification or voice MFA prompt as suspicious, the user account will be marked with user risk High. You can then use risk-based policies to have greater control over the specific remediation for these users, whether it’s requiring immediate password change through self-service password reset, requiring MFA for all authentications until the risk is remediated, or blocking authentication until the risk is remediated.   

 

 

If you don’t have P2, you can also use the risk event to disable the account until the risk can be remediated, for similar functionality to the legacy MFA blocklist. 

 

Report Suspicious Activity will function in parallel with the legacy MFA Fraud Alert during preview, so if you have Fraud Alert enabled with automatic blocking, you’ll need to both remediate the risk for users in scope for Report Suspicious Activity as well as remove the user from the MFA blocklist. 

 

Learn more about configuring Report Suspicious Activity and how to leverage risk-based policies and try Suspicious Activity now. 

 

As always, let us know your feedback. 

 

Best regards,   

Alex Weinert (@Alex_T_Weinert)   

VP Director of Identity Security, Microsoft  

 

 

Learn more about Microsoft identity: 

Updated Mar 23, 2023
Version 1.0
  • john66571's avatar
    john66571
    Brass Contributor

    Hello,
    I have laborated a lot and migrated multiple tenants to the new Authentication methods.
    What i found was that if you have more then 2 secondary methods enabled in your tenant in the new Authentication methods in Azure AD, new users can press the "user another method" when signing in for the first time and chose SMS (or any of the other) as their primary method. This is even if you untick "allow sign in" under SMS.

    Sure, the new system-preferred MFA setting that is currently being rolled out will (after 2-6 hours after the new user has logged in) kick in if enabled to enforce the strongest of the method the user signed up with.
    However, this setting was not available until very recently. We still want to use SMS or Email as a "secondary" method for the password reset functionality but we wish for the user to only see Microsoft Authenticator as their primary option (first time sign in) and not the "user another method" on the first option for sign ins. In the second step we wish for the user to be able to select email, sms or another secondary method we have enabled (currently only sms and email seem to work).

     

    Is this possible to address?
    I did a feedback submission a while back (early 2023).

  • On the new "Report Suspicious Activity", what's the Reporting Code intended for? It appears to be just a number that will appear in the related log entry?

  • pj101's avatar
    pj101
    Copper Contributor

    DamienSolodow The Reporting Code will be the number that the end user presses on their phone keypad when the second factor is a voice call to report a suspicious MFA call. It defaults to '0' - so a user would press '0' on their keypad when they get a suspicious MFA call - but can be set to any number 0-9.

  • ChrisBalk's avatar
    ChrisBalk
    Copper Contributor

    Hello,

     

    I started migrating to the new MFA management policy on our tenant but am wondering if "trusted IPs" (bypasses MFA for on prem users) will continue to work once I complete the migration. I would assume so, but since it's on the same page as the legacy MFA "verification options", I want to be sure this will continue to be supported as we use this feature.

     

    Thank you!

  • john66571's avatar
    john66571
    Brass Contributor

    ChrisBalkIt will evaluate your trusted IP's as you are only migrating Methods. However, you should not use that, instead - migrate to Conditional Access and use named locations if you really must use it. Thats the whole power behind the granular modern authentication in Entra ID.