Two-step verification (sometimes called multi-factor authentication) helps protect you by making it more difficult for someone else to sign in to your Microsoft account. It uses two different forms of identity: your password, and a contact method (also known as security info). Even if someone else finds your password, they'll be stopped if they don't have access to your security info. This is also why it's important to use different passwords for all your accounts.
Two-step verification begins with an email address (we recommend two different email addresses, the one you normally use, and one as a backup just in case), a phone number, or any authenticator app. When you sign in on a new device or from a new location, we'll send you a security code to enter on the sign-in page. Learn how you can use the Microsoft Authenticator app or authenticate using Outlook for Android.
If you forget your password when you have two-step verification turned on for your account, you can reset your password as long as we have two ways to contact you, like one of the alternate contact email addresses or phone numbers that you used when you turned on two-step verification.
Depending on what security info you have added to your account, this requirement might mean entering a security code from your authenticator app and entering a security code that was emailed to your backup email account.
If you're looking for info about changing, removing, or updating the alternate email address or phone number where you get security codes, follow the steps in either Security info & verification codes or Replace your Microsoft account security info.
App passwords are only available if you use two-step verification. If you don't have two-step verification turned on, you won't see the App passwords section on the Additional security options page.
If your organization provided you with specific steps about how to turn on and manage your two-factor verification, you should follow those instructions first. Otherwise, you can get to your security verification method settings from the Security info page.
Select Choose a method and then Authenticator app.
Follow the on-screen instructions, including using your mobile device to scan the QR code, and then select Next. You'll be asked to approve a notification through the Microsoft Authenticator app, to verify your information.
You can delete your account from the Microsoft Authenticator app, and you can delete your device from your work or school account. Typically you delete your device to permanently remove a lost, stolen, or old device from your account, and you delete your account to try to fix some connection issues or to address an account change, such as a new user name.
Depending on your organization's settings, you may see a check box that says "Don't ask again for n days" when you perform two-factor verification. If you've selected this option to stop two-factor verification prompts, and then you lose your device or your device is potentially compromised, you should have Microsoft 365 sign you out of all your devices to help protect your account. Unfortunately, you can't sign out of a specific device unless you have access to that device, so you need to sign out of all of them at once.
When I visit Azure Active Directory -> Users -> Multi-Factor Authentication, our initial accounts show "Multi-Factor Auth Status" as "Disabled", but we are seeing MFA prompts. I find it confusing that something shows "disabled" that is really turned on somehow??? Is there more than one type of MFA?
We just received a trial for G1 as part of building a use case for moving to Office 365. I setup the tenant space by confirming our identity and I am a Global Administrator. I was prompted to setup MFA on my second logon, but I don't recall being offered any option other than text message. My understanding is that I had to turn on MFA for our accounts so I just setup SMS to get logged on the second time.
Yes, our tenant space is setup to use the security defaults as mentioned on this page -us/azure/active-directory/fundamentals/concept-fundamentals-security-d.... If you turn off Security Defaults, the multi-factor authentication page still shows that no accounts have MFA setup, even though they are setup for MFA. It really seems like when Security Defaults was implemented they must have setup things to ignore the existing MFA settings altogether. I would really like to see that MFA is turned on for a user whether using the fancy Conditional Access that I am reading about or Security Defaults.
Once you can verify that these settings are no longer applying, I'd recommend using Conditional Access Policies for MFA instead of relying on the Security defaults as these apply blanket settings. You can find this at under Azure Active Directory > Security > Conditional Access.
You will see some Baseline policies there. Don't enable those as they also apply blanket settings, and they are due to be deprecated. I'd highly suggest you create your own CA Policies. I'd recommend at the minimum a policy to require MFA for all privileged admin roles, but don't forget to exclude your permanent break glass account(s) from this policy as you don't want to get locked out.
@Germaum Sorry to bring a dead thread back but we're having a similar issue with Security Defaults disabled. Though it's not every user. We're currently tracking one high profile user. Our tenant responds that MFA is disabled when checked via powershell. (The script works properly for other users so we know the script is good). The users still gets MFA prompts and his account allows for additional security settings even though the MFA is "Disabled".
Any clues as to why this might happen to a small number of users and why it may happen even though default security settings are/have been off?
Office 365
If your tenant was created on or after October 22, 2019, it is possible security defaults are already enabled in your tenant. In an effort to protect all of our users, security defaults is being rolled out to all new tenants created. (referenced from -us/azure/active-directory/fundamentals/concept-fundamentals-security-d...)
Try this:
1. Go to
2. Use the search bar on the upper middle part of the page and search of "Azure Active Directory".
3. Under Azure Active Directory, search for Properties on the left-hand panel. It is in-between of User Settings and Security.
4. Under the Properties, click on Manage Security defaults.
5. Under the Enable Security defaults, toggle it to NO.
6. Wait for few minutes for propagation then try to sign-in using InPrivate or Incognito.
All users have MFA Disabled and Enable Security defaults are also set to No, yet as I am adding each account to Access work or school on new PC I get prompted to setup MFA. I just click Next and then close the window. It's a pain, but the account is successfully added and credentials are used to open O365 etc.
This is all down to a new and ill-conceived UI from Microsoft. They've basically combined MFA setup with account recovery setup. Prior to this change, if you had self-service password reset enabled, on first login users would be prompted to setup a recovery phone and email. If MFA was enabled, they'd be prompted to setup MFA.
The combined approach is highly confusing when not wanting MFA. It still allows a user to setup MFA even when it's disabled on the account in Azure. Indeed it's designed to make you think you have to set it up. Just more nonsense from unskilled product managers and developers with little experience of the real world and zero common sense.
Same with the Security Defaults. These force use of MFA for all accounts, despite Microsoft's own recommendation to have at least one GA account not using MFA in case of MFA issues. Indeed a non-MFA GA account is needed for hybrid operation as well as for any 3rd party services that need access to the 365 tenant.
Anyhow, the solution is to ignore the initial presentation of the setup. For option 1, select Phone instead of Authenticator App from the dropdown. Then complete the phone verification as it used to be done. Then select Email for option 2 and complete that. Account is now setup with password reset info needed but without MFA enabled.
That still leaves the issue that, if the user chose to enable MFA during initial account setup, this won't reflect in AAD. That still shows MFA as disabled!
What we found is that you can enable MFA through MyAccount.Microsoft.com > Security Info > Update Info. If it is enable here, the Azure portal continues to show that it is not enabled yet if functions. If set up this way, then changing it in Azure has virtually no effect (except your powershell reporting will be correct again).
Let me know if I am wrong on any points, but it seems to hold true for us.
If anyone sees this again, log into Azure, search for conditional access to bring up that conditional access interface, and see if you have a conditional access policy applied. It likely will have one intitled "Require MFA for Everyone." If that policy is in the list of conditional access polices listed, delete it. Problem solved. Or at least in my case. Whether or not you have MFA enabled at the user level is superseded by this policy, and it won't even show MFA as enabled at the user level even thought this policy is forcing it. Again this was the case for me. Milage may vary. @Eddie78723
@Eddie78723 it is sorry to hit this point again. Even the users were set Disable in MFA set up but when user login, it still requires to MFA. Some users require to login without the MFA. How can we set it? I did both in Properties and Condition Access but it seemed not work. Thank you
So after a few hours on the phone with Microsoft it was discovered that Self Service is the culprit. It is enabled for all users once you switch it to "None" it will not trigger MFA and allow users to logon without MFA challenge when MFA itself is disabled.
e59dfda104