Frequently asked questions about Microsoft Entra multifactor authentication

With Multi-Factor Authentication Server, user data is only stored on the on-premises servers. No persistent user data is stored in the cloud. When the user performs two-step verification, Multi-Factor Authentication Server sends data to the Microsoft Entra multifactor authentication cloud service for authentication. Communication between Multi-Factor Authentication Server and the multifactor authentication cloud service uses Secure Sockets Layer (SSL) or Transport Layer Security (TLS) over port 443 outbound.

When authentication requests are sent to the cloud service, data is collected for authentication and usage reports. The following data fields are included in two-step verification logs:

• Unique ID (either user name or on-premises Multi-Factor Authentication Server ID)
• First and Last Name (optional)
• Email Address (optional)
• Phone Number (when using a voice call or text message authentication)
• Device Token (when using mobile app authentication)
• Authentication Mode
• Authentication Result
• Multi-Factor Authentication Server Name
• Multi-Factor Authentication Server IP
• Client IP (if available)

The optional fields can be configured in Multi-Factor Authentication Server.

The verification result (success or denial), and the reason if it was denied, is stored with the authentication data. This data is available in authentication and usage reports.

For more information, see Data residency and customer data for Microsoft Entra multifactor authentication.

In the United States, we use the following short codes:

• 97671
• 69829
• 51789
• 99399

In Canada, we use the following short codes:

• 759731
• 673801

There's no guarantee of consistent text message or voice-based multifactor authentication prompt delivery by the same number. In the interest of our users, we may add or remove short codes at any time as we make route adjustments to improve text message deliverability.

We don't support short codes for countries or regions besides the United States and Canada.

Yes, in certain cases that typically involve repeated authentication requests in a short time window, Microsoft Entra multifactor authentication will throttle user sign-in attempts to protect telecommunication networks, mitigate MFA fatigue-style attacks and protect its own systems for the benefit of all customers.

Although we don't share specific throttling limits, they are based around reasonable usage.

No, you're not charged for individual phone calls placed or text messages sent to users through Microsoft Entra multifactor authentication. If you use a per-authentication MFA provider, you're billed for each authentication, but not for the method used.

Your users might be charged for the phone calls or text messages they receive, according to their personal phone service.

Billing is based on the number of users configured to use multifactor authentication, regardless of whether they performed two-step verification that month.

When you create a per-user or per-authentication MFA provider, your organization's Azure subscription is billed monthly based on usage. This billing model is similar to how Azure bills for usage of virtual machines and Web Apps.

When you purchase a subscription for Microsoft Entra multifactor authentication, your organization only pays the annual license fee for each user. MFA licenses and Microsoft 365, Microsoft Entra ID P1 or P2, or Enterprise Mobility + Security bundles are billed this way.

For more information, see How to get Microsoft Entra multifactor authentication.

Security defaults can be enabled in the Microsoft Entra ID Free tier. With security defaults, all users are enabled for multifactor authentication using the Microsoft Authenticator app. There's no ability to use text message or phone verification with security defaults, just the Microsoft Authenticator app.

For more information, see What are security defaults?

If your organization purchases MFA as a standalone service with consumption-based billing, you choose a billing model when you create an MFA provider. You can't change the billing model after an MFA provider is created.

If your MFA provider is not linked to a Microsoft Entra tenant, or you link the new MFA provider to a different Microsoft Entra tenant, user settings, and configuration options aren't transferred. Also, existing MFA Servers need to be reactivated using activation credentials generated through the new MFA Provider. Reactivating the MFA Servers to link them to the new MFA Provider doesn't impact phone call and text message authentication, but mobile app notifications will stop working for all users until they reactivate the mobile app.

Learn more about MFA providers in Getting started with an Azure multifactor authentication provider.

In some instances, yes.

If your directory has a per-user Microsoft Entra multifactor authentication provider, you can add MFA licenses. Users with licenses aren't counted in the per-user consumption-based billing. Users without licenses can still be enabled for MFA through the MFA provider. If you purchase and assign licenses for all your users configured to use multifactor authentication, you can delete the Microsoft Entra multifactor authentication provider. You can always create another per-user MFA provider if you have more users than licenses in the future.

If your directory has a per-authentication Microsoft Entra multifactor authentication provider, you're always billed for each authentication, as long as the MFA provider is linked to your subscription. You can assign MFA licenses to users, but you'll still be billed for every two-step verification request, whether it comes from someone with an MFA license assigned or not.

If your organization uses a consumption-based billing model, Microsoft Entra ID is optional, but not required. If your MFA provider isn't linked to a Microsoft Entra tenant, you can only deploy Azure Multi-Factor Authentication Server on-premises.

Microsoft Entra ID is required for the license model because licenses are added to the Microsoft Entra tenant when you purchase and assign them to users in the directory.

Have your users attempt up to five times in 5 minutes to get a phone call or text message for authentication. Microsoft uses multiple providers for delivering calls and text messages. If this approach doesn't work, open a support case to troubleshoot further.

Third-party security apps may also block the verification code text message or phone call. If using a third-party security app, try disabling the protection, then request another MFA verification code be sent.

If the steps above don't work, check if users are configured for more than one verification method. Try signing in again, but select a different verification method on the sign-in page.

For more information, see the end-user troubleshooting guide.

You can reset the user's account by making them to go through the registration process again. Learn more about managing user and device settings with Microsoft Entra multifactor authentication in the cloud.

To prevent unauthorized access, delete all the user's app passwords. After the user has a replacement device, they can recreate the passwords. Learn more about managing user and device settings with Microsoft Entra multifactor authentication in the cloud.

If your organization still uses legacy clients, and you allowed the use of app passwords, then your users can't sign in to these legacy clients with their username and password. Instead, they need to set up app passwords. Your users must clear (delete) their sign-in information, restart the app, and then sign in with their username and app password instead of their regular password.

If your organization doesn't have legacy clients, you shouldn't allow your users to create app passwords.

Delivery of text messages isn't guaranteed because uncontrollable factors might affect the reliability of the service. These factors include the destination country or region, the mobile phone carrier, and the signal strength.

Third-party security apps may also block the verification code text message or phone call. If using a third-party security app, try disabling the protection, then request another MFA verification code be sent.

If your users often have problems with reliably receiving text messages, tell them to use the Microsoft Authenticator app or phone call method instead. The Microsoft Authenticator can receive notifications both over cellular and Wi-Fi connections. In addition, the mobile app can generate verification codes even when the device has no signal at all. The Microsoft Authenticator app is available for Android, iOS, and Windows Phone.

In some cases, yes.

For one-way SMS with MFA Server v7.0 or higher, you can configure the timeout setting by setting a registry key. After the MFA cloud service sends the text message, the verification code (or one-time passcode) is returned to the MFA Server. The MFA Server stores the code in memory for 300 seconds by default. If the user doesn't enter the code before the 300 seconds have passed, their authentication is denied. Use these steps to change the default timeout setting:

1. Go to HKLM\Software\Wow6432Node\Positive Networks\PhoneFactor.
2. Create a DWORD registry key called pfsvc_pendingSmsTimeoutSeconds and set the time in seconds that you want the MFA Server to store one-time passcodes.

If users don't respond to the SMS within the defined timeout period, their authentication is denied.

For one-way SMS with Microsoft Entra multifactor authentication in the cloud (including the AD FS adapter or the Network Policy Server extension), you can't configure the timeout setting. Microsoft Entra ID stores the verification code for 180 seconds.

If you're using Multi-Factor Authentication Server, you can import third-party Open Authentication (OATH) time-based, one-time password (TOTP) tokens, and then use them for two-step verification.

You can use ActiveIdentity tokens that are OATH TOTP tokens if you put the secret key in a CSV file and import to Multi-Factor Authentication Server. You can use OATH tokens with Active Directory Federation Services (ADFS), Internet Information Server (IIS) forms-based authentication, and Remote Authentication Dial-In User Service (RADIUS) as long as the client system can accept the user input.

You can import third-party OATH TOTP tokens with the following formats:

• Portable Symmetric Key Container (PSKC)
• CSV if the file contains a serial number, a secret key in Base 32 format, and a time interval

Yes, but if you're using Windows Server 2012 R2 or later, you can only secure Terminal Services by using Remote Desktop Gateway (RD Gateway).

Security changes in Windows Server 2012 R2 changed how Multi-Factor Authentication Server connects to the Local Security Authority (LSA) security package in Windows Server 2012 and earlier versions. For versions of Terminal Services in Windows Server 2012 or earlier, you can secure an application with Windows Authentication. If you're using Windows Server 2012 R2, you need RD Gateway.

When multifactor authentication calls are placed through the public telephone network, sometimes they are routed through a carrier that doesn't support caller ID. Because of this carrier behavior, caller ID isn't guaranteed, even though the multifactor authentication system always sends it.

There are several reasons that users could be prompted to register their security information:

• The user has been enabled for MFA by their administrator in Microsoft Entra ID, but doesn't have security information registered for their account yet.
• The user has been enabled for self-service password reset in Microsoft Entra ID. The security information will help them reset their password in the future if they ever forget it.
• The user accessed an application that has a Conditional Access policy to require MFA and hasn't previously registered for MFA.
• The user is registering a device with Microsoft Entra ID (including Microsoft Entra join), and your organization requires MFA for device registration, but the user hasn't previously registered for MFA.
• The user is generating Windows Hello for Business in Windows 10 (which requires MFA) and hasn't previously registered for MFA.
• The organization has created and enabled an MFA Registration policy that has been applied to the user.
• The user previously registered for MFA, but chose a verification method that an administrator has since disabled. The user must therefore go through MFA registration again to select a new default verification method.

Ask the user to complete the following procedure to remove their account from the Microsoft Authenticator, then add it again:

1. Go to their account profile and sign in with an organizational account.
2. Select Additional Security Verification.
3. Remove the existing account from the Microsoft Authenticator app.
4. Click Configure, and then follow the instructions to reconfigure the Microsoft Authenticator.

The 0x800434D4L error occurs when you try to sign in to a non-browser application, installed on a local computer, that doesn't work with accounts that require two-step verification.

A workaround for this error is to have separate user accounts for admin-related and non-admin operations. Later, you can link mailboxes between your admin account and non-admin account so that you can sign in to Outlook by using your non-admin account. For more details about this solution, learn how to give an administrator the ability to open and view the contents of a user's mailbox.

Error 1073741715 = Status Logon Failure -> The attempted logon is invalid. This is due to either a bad username or authentication.

A plausible reason for this error: If the primary credentials entered are correct, there might be a mismatch between the supported NTLM version on the MFA server and the domain controller. MFA Server supports only NTLMv1 (LmCompatabilityLevel=1 thru 4) and not NTLMv2 (LmCompatabilityLevel=5).

Next steps

If your question isn't answered here, the following support options are available:

• Search the Microsoft Support Knowledge Base for solutions to common technical issues.
• Search for and browse technical questions and answers from the community, or ask your own question in the Microsoft Entra Q&A.
• Contact Microsoft professional through Multi-Factor Authentication Server support. When contacting us, it's helpful if you can include as much information about your issue as possible. Information you can supply includes the page where you saw the error, the specific error code, the specific session ID, and the ID of the user who saw the error.