Take a look a this Github issue: https://github.com/MicrosoftDocs/azure-docs/issues/57279

When I use My Staff to set the user's phone, strong auth method is registered.
This statisfies the Indentity Protection en SSPR reset registration.
I configured to register 2 methods, but the users is never prompted.

1.Brand new user is created
2. User is added to Administrative unit
3. Manager sets phone number
4. Add user to the identity protection and sspr registration policy
5. User logs in, is prompted for MFA like expected (caused by Conditional Access)
6. Users changes password (new user)
7. User is NOT prompted to register second method

When I reset the MFA methods with the portal user is prompted to register BOTH methods at next sign-in

From an onboarding perspective, this is not ideal. Pre-populating is awesome for secure onboarding and proof-up, but after that, I want the user to register for Authenticator for instance. So, it should be better if the user is prompted by either the SSPR policy or Identity Protection policy to register the required amount of methods, in my case mostly 2. Now that is not happening.

We want to include MFA during sign-up where the user is created after the MFA process. However, it seems that currently the user is always created before MFA process in either built-in policy or custom policy. Below is the ideal process for sign-up; note, there is only one identity provider.

The user will be added into the tenant only if he/she finishes all following three steps.
1. Scan the QR code and confirm on mobile

1. Validate the mobile phone number (here custom policy calls external Rest API to check if the mobile phone number is already in the database. Some mobile phone numbers were added into database in advance)
   
   




2. MFA with the same mobile phone number in step 2 (to prove the user is the owner of mobile phone)
   
   

Currently, the challenge is that after step 2, the user is already created in the tenant which means the user can skip step 3.

We should be able to set up the sign-up process so that new users must complete the MFA process before the new user is created.

We use a conditional access policy to enforce MFA enrollment for all users, including guest users, since the data that everyone is accessing is highly confidential. In addition, because SIM-stealing attacks are becoming more and more common, our MFA policy is configured to require an app rather than relying on codes provided by SMS or phone calls.

With this combination of settings, we find guest users to be very disoriented, confused, and frustrated by the current MFA enrollment process. Since this process is often the user's first impression of our technology and Microsoft Azure, it's important for the user experience of this workflow to improve. It should work for someone who is not tech-savvy.

For those that aren't familiar, when opting to use an app for MFA, the steps involved include (see screenshots in attached PDF):

A. Consent to provide "more information" to proceed to "Step 1".
B1. Choose how to receive MFA codes (in our case, they must use an app).
B2. Choose "Use verification code" to ensure users can log-in even if their phone does not have connectivity.
B3. Click the "Set-up" button (resisting the temptation to instead click the "Next" button).
C. Installing an MFA app on a smartphone.
D1. If using Microsoft Authenticator: Tell Microsoft Authenticator to add a "Work" account even if the guest user is logging-in with a personal Live account that may already have MFA setup.
D2. If using a different appp than Microsoft Authenticator: Click "Configure app without notifications" on the web page to get a QR code that's compatible with other apps.
E. Scanning the QR code and saving the account in their authentication app.
F. Click the "Next" button to dismiss the QR-code modal.
G. Click the "Next" button to proceed to "Step 2".
H. Enter the code displayed in the app into the box.
I. Click the "Verify" button.
J1. If the code is accepted, great! Proceed to the app.
J2. If the code is not accepted, now what? The only option is "Cancel". At this point we usually have to hand-hold users through removing the app from their authenticator app, then closing their browser, re-opening their browser, and trying to log-in a second time to restart the process.

Having helped more than 25 guest users get set-up in our system over the last year, the steps with the most confusion appear to be:

• B2: Despite written instructions to the contrary, guest users almost always skip past opting to use a verification code, then get confused later during enrollment if they can't find the notification on their phone).


• B3: Users really want to be able to click "Next" and get confused that it's greyed-out/disabled. They often don't understand why they have to do something different to make the QR code appear when it's a required step.


• D1: Guest users who have an existing Live account -- especially one with MFA already set-up for their own personal use -- often go off-the-rails at this point because Microsoft Authenticator offers to let them log-in with their personal Live account and starts displaying an eight-digit code for their personal use instead of displaying the required six-digit code for access to our system. They often are confused that we have to have them choose to add a second account to the app that's a "Work" account since the email address they're logging-in with they consider to be a "personal" account.


• D2: Tech-savvy users who are using Authy or Google Authenticator don't understand why the QR code that is displayed initially won't scan. It's very unclear that the QR code shown when "notifications" are "enabled" is Microsoft-specific.


• I / J2: If the user didn't properly configure the MFA app in earlier steps, this is where things usually go completely off the rails. After a few incorrect codes the flow completely locks the user out instead of helping them go back to the step where they can set the app up again. We usually get a frantic email or phone call at this step because the user is not sure what to do.

Recommended improvements:

• Fold step A into step B. Why does the screen that indicates more information is required need to be a separate step? That it's something that stands alone and requires confirmation by the user often makes users nervous that we're about to ask them a lot of personal questions, when in reality we just want to drop them into MFA enrollment.


• Add a "Start over" button to the enrollment wizard, in case users just want to start from a clean slate.


• Add a "Back" button to the enrollment wizard so a user can always change his or her mind about the options he or she chose.


• Don't ask in step if the user wants to receive notifications vs. use a verification code at all in the set-up wizard. Move that question into the Microsoft Authenticator app for after they've scanned the QR code for Microsoft Authenticator.


• Eliminate the QR code modal from step B entirely and move the set-up of the mobile app to a new wizard "Step 2". This step needs to explain to the user briefly what the app they're installing is for and why it's important. The user experience design, the terminology, and the verbiage used here should be written closer to what you'd expect from XBox Live and less like that of the Azure Portal. Pretend your target audience does not have any understanding of the technology or security implications of what they're doing, just like XBox Live assumes that the user is a kid who needs guidance through even simple things like entering in a gift card or setting up his or her account.


• In the new wizard step 2, ask the user what type of app they're installing -- "Microsoft Authenticator (preferred)", or "An alternative app like Google Authenticator or Authy". This drives what QR code is displayed to the user.


• In the new wizard step 3, present the appropriate QR code based on what the user chose in step 2.
  
  
  • Display BOTH the QR code and the box where the user has to enter the verification code on this step, together. This makes it easier for the user to set-up the app again if they miss a step, try to enter a code from the wrong account in their MFA app, etc. The verbiage on this page should say "Scan the QR Code below with the app you've installed. If the app displays a six-digit code after scanning the QR code, enter it below."
  
  
  • If using Microsoft Authenticator -- per my recommendation above -- the user can be prompted as to whether or not they want to use notifications or a code. After they make a choice, because Microsoft controls both the enrollment flow and the MFA app, the wizard should automatically proceed to the next step.
  
  
  
  

If you do these things, you will cut down on 75% of the emails we get after inviting guest users to collaborate with us on apps we use that are secured by Azure AD. The pain point is strong enough that I've been considering switching to an in-house system like Keycloak instead of Azure AD because users are so frustrated by this process.