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.

I am currently a victim of spoofing (piracy) for over 8 mos. anything I type or submit electronically is copied by the hackers. A Mutli factor authentication using a landline that I can register as my number might be helpful.. I can register my job number. corp security or even the police officer's number. either they provide my authentication or the spoofer attempts to pirate the number and caught with a back trace.I have over 15 email address attempting to access my account information because there is not a secure way to retrieve your old account without creating a new one. It is a never ending cycle.

We are deploying Azure MFA by the following method, and we perform various controls depending on the status of MFA ([Forced] or [Enabled]).
https://docs.microsoft.com/ja-jp/azure/active-directory/authentication/howto-mfa-userstates
Even without enabling MFA, I understand that it is possible to directly access 「https://aka.ms/mfasetup」 and register the MFA notification destination in advance.
However, if you enable MFA after registering the MFA notification destination, the status of MFA will not be changed to [Forced] even though MFA setup has been completed.

The specifications are different from the status of each MFA status described in the Microsoft public documentation.
Since the control is based on the status of the MFA, if you enable the MFA for the user who changed the notification destination of the MFA in advance, please change the specification so that it is automatically changed to [Forced].

CA has the ability to grant access by enforcing MFA, we have a use case whereby in the large part our user estate is configured for push notifications, we have some systems whereby we do not want this method of MFA (this is for a number of reasons), some scenerios we would prefer to selectively pick verifications codes as the only method of MFA but leave push notifications for other services.

It would be great to also incorporate this into NPS in the form of say a RADIUS attribute which would be able to toggle between what MFA method to use for a given policy.

MFA for Admin credentials in a business environment should NEVER require an admin to provide PERSONAL information in order to verify identity.

Existing requirement is limited only to provide a Phone # (seemingly ONLY a Cell#) and a 2nd Email address (which is not related to the domain) and this has more of the appearance of data-mining rather than MFA.

Not everybody has a company-provided cell phone. Verification call back to a PBX cannot navigate an extension. Even when having it call a direct dial number to my desk, the message is that verification was not possible.

This is infuriating and unprofessional when there are no other options to authenticate the account within a normal corporate environment.

Furthermore, when an admin calls Support due to the lack of MFA options that will work without providing personal phone or email data, the support staff should have the power to determine identity and validate the MFA for another 180 days when the limited offerings WILL NOT WORK.

Even better, if the admin could disable MFA for Admin credentials entirely if they choose to.