One Entra ID user is asked by Entra to add a phone number for authentication despite the method being disabled in our tenant

Question

One Entra ID user is asked by Entra to add a phone number for authentication despite the method being disabled in our tenant

Tilman Schmidt 270

We have disabled the "SMS" and "Voice call" authentication methods in our Entra ID tenant and require all users to use Microsoft Authenticator as their second authentication factor.

Now one of our users reports, after having his authentication methods reset via "Require re-register multifactor authentication", that after registering his Microsoft Authenticator instance he was asked by Entra ID to add his phone number as a second method and confirm his identity by a phone call or SMS code. The dialog he received was this:

User's image

Translation:

"Method 2 of 2
Add own phone number
Confirm your identity through a call or a text code on your mobile phone.
Country code
Phone number
Choose how it should be confirmed
(*) Send code by SMS
..."

I tried to reproduce the effect with my own account but couldn't.

What could be the reason for Entra ID to force my user to register the phone number method even though I disabled it tenant-wide? How can I fix it?

VEMULA SRISAI 12,615 Reputation points Microsoft External Staff Moderator

2026-04-22T15:21:07.73+00:00
Hello Tilman Schmidt,

This behavior can occur after using “Require re-register multifactor authentication”. During MFA re-registration, Entra ID enforces security info requirements, which are separate from the tenant’s allowed authentication methods. Even though SMS and voice call are disabled for MFA sign-in, Entra ID may still prompt the user to register a phone number as backup/security info.

Solution / What to do

The phone number requested is only for account recovery or identity proofing, not for MFA sign-in.

SMS or voice will not be used for authentication if they are disabled tenant-wide.

To avoid this prompt, configure Registration Campaigns or allow an alternative backup method (such as FIDO2 security keys or Temporary Access Pass) instead of forcing full MFA re-registration.

If only the Authenticator needs to be reset, remove and re-add the Authenticator method rather than using “Require re-register MFA”.

https://learn.microsoft.com/en-in/entra/identity/authentication/howto-mfa-userdevicesettings
VEMULA SRISAI 12,615 Reputation points Microsoft External Staff Moderator

2026-04-24T14:32:41.74+00:00

Tilman Schmidt I’m following up on my previous response to see if it helped. Please feel free to reach out if you need any further assistance—I’m happy to help.
Tilman Schmidt 270 Reputation points

2026-04-27T08:16:15.8066667+00:00

I'm still waiting for the affected user to get back to me with a proposal when we can test it.
Tilman Schmidt 270 Reputation points

2026-04-27T13:03:47.6133333+00:00
Thank you for your reply. I just got the user to do a few tests with me, and now I am thoroughly confused:

In an attempt to avoid the prompt for the phone number, I tried to create a Temporary Access Pass for the user, but Entra refused that with an error message:

The declared reason for requiring the phone number is indeed verifying the user's identity. There is however no discernible attempt at actually doing that. I can enter whatever phone number I want and the verification code will be sent there. So an attacker could just enter her own phone number and get the code. Where does the verification happen?

After completing the verification step, the phone number used for verification appears on the user's Entra account as "usable authentication method". But in reality it isn't usable. When the user signs in and is asked for the second factor, he does not get the option of using SMS or phone call, only Authenticator push or OTP.

The reason why we do "Require re-register" is usually either some Entra malfunction, a suspected account compromise, or several identically named Microsoft Authenticator methods listed under "Usable authentication methods" with no way to distinguish which of them is actually in use. Can the "remove and re-add Authenticator method" procedure cover those use cases?

Thanks for your help.
VEMULA SRISAI 12,615 Reputation points Microsoft External Staff Moderator

2026-04-28T18:33:38.9733333+00:00

Tilman Schmidt This behavior is expected after using “Require re‑register multifactor authentication.” Even if SMS/Voice are disabled for MFA sign‑in, Entra ID may still require a phone number as security/identity verification info during re‑registration. This phone number is not used for MFA, which is why SMS/call never appears during sign‑in—only Microsoft Authenticator is available.

The phone verification step only confirms user presence during enrollment; it does not make the phone an active MFA method. To avoid this prompt in the future, remove and re‑add only the Microsoft Authenticator method instead of forcing full MFA re‑registration, or use alternatives like FIDO2 or properly scoped Temporary Access Pass flows.

This does not indicate a tenant misconfiguration or security gap.
Tilman Schmidt 270 Reputation points

2026-04-29T09:04:53.1366667+00:00

@VEMULA SRISAI Thanks for your explanation. It does not quite match my experience, though.

You write "it does not make the phone an active MFA method". But as I wrote, Microsoft Entra lists it as such.

You write "To avoid this prompt in the future, [...] use alternatives like [...] Temporary Access Pass flows". But as I wrote, creating a Temporary Access Pass is blocked by Microsoft Entra.

Also, I still don't understand how to apply your advice to "remove and re‑add only the Microsoft Authenticator method" in the use cases I described, for example in the case of a suspected account compromise when there are several Microsoft Authenticator methods listed under "Usable authentication methods", all of them called "iPhone 12".
VEMULA SRISAI 12,615 Reputation points Microsoft External Staff Moderator

2026-04-30T13:45:19.6466667+00:00
Tilman Schmidt This behavior is expected when “Require re‑register multifactor authentication” is used. That action forces the user through combined security info registration, which is shared by MFA and Self‑Service Password Reset (SSPR). In this flow, Entra ID validates that the user has sufficient security information, not only an MFA sign‑in method.

Even if SMS and Voice are disabled for MFA sign‑in tenant‑wide, Entra ID may still prompt for a phone number as security info if:

The user is in scope for SSPR, and

Your SSPR configuration requires more than one authentication method for password reset.

The phone number collected here is for identity verification / security info enrollment, not for MFA sign‑in. That is why:

The number appears under Authentication methods in the user profile

But SMS / voice never appear as sign‑in options, since they are disabled by policy

This is not a security bypass—the verification only proves possession of the entered number at enrollment time, which is by design.

About Temporary Access Pass (TAP) TAP creation or usage will fail if:

TAP is not enabled in Authentication methods > Policies, or

The user is not included in the TAP policy scope, or

A Conditional Access policy for “Register security information” still requires existing security info

Recommended operational approach

Instead of using Require re‑register MFA:

Remove the specific Microsoft Authenticator method(s) from the user (especially duplicate entries)

Revoke sign‑in sessions

Re‑add Microsoft Authenticator cleanly

Use TAP only after confirming the TAP policy and CA scope are correctly configured

This avoids triggering the full combined registration flow and prevents unwanted phone prompts.
VEMULA SRISAI 12,615 Reputation points Microsoft External Staff Moderator

2026-05-04T08:11:38.07+00:00

Tilman Schmidt ,I’m following up on my previous response to see if it helped. Please feel free to reach out if you need any further assistance—I’m happy to help.
Tilman Schmidt 270 Reputation points

2026-05-04T08:57:55.9033333+00:00

@VEMULA SRISAI I'm sorry but your response did not help. The behavior might be expected for you, but it certainly doesn't meet our expectations. None of the criteria you cite as causing Entra ID to prompt for a phone number apply, and yet it does. Our users should not, and do not want to, provide a phone number for identification, but Entra ID forces some of them to do so. It is not understandable, and thoroughly confusing to our helpdesk and security operators, that the phone number thus obtained subsequently appears as "usable authentication method" for the user. I still do not understand why I cannot create a TAP for the user since none of the reasons you list are present. And I find myself unable to apply your recommended operational approach because I do not know which of the Microsoft Authenticator methods listed is the specific one or the duplicate, and also I still cannot use TAP even though I confirmed TAP policy and CA scope to the best of my knowledge.
VEMULA SRISAI 12,615 Reputation points Microsoft External Staff Moderator

2026-05-06T05:17:41.1833333+00:00
Tilman Schmidt,This behavior is related to using “Require re‑register multifactor authentication”.That action forces the user through the combined security info registration flow (used by both MFA and SSPR), not just Microsoft Authenticator re‑enrollment. In this flow, Entra ID may require a phone number as security information, even if SMS/Voice are disabled for MFA sign‑in at tenant level.

Key points:

The phone number collected is not usable for MFA sign‑in; policy still blocks SMS/voice at sign‑in.

The verification step only proves possession of the entered number, not that it belongs to the user.

The phone appears under Authentication methods because it’s stored in the unified methods framework, but usability is enforced by policy, which is why users never see SMS/call during MFA.

For Temporary Access Pass, TAP creation should normally be allowed even if the user is not in scope to use it. If TAP creation itself is blocked despite policies and roles being correct, that does not align with documented behavior and should be treated as a product/support issue.

Operationally, to avoid this confusion:

Avoid Require re‑register MFA unless absolutely necessary.

For duplicate or suspicious Authenticator entries, remove specific Microsoft Authenticator methods from the user and revoke sessions, instead of forcing full re‑registration.

This is expected platform behavior, but the UX and labels are admittedly misleading.

1 answer

Your answer

VEMULA SRISAI 12,615 Reputation points Microsoft External Staff Moderator

2026-04-22T15:21:07.73+00:00

Hello Tilman Schmidt,

This behavior can occur after using “Require re-register multifactor authentication”. During MFA re-registration, Entra ID enforces security info requirements, which are separate from the tenant’s allowed authentication methods. Even though SMS and voice call are disabled for MFA sign-in, Entra ID may still prompt the user to register a phone number as backup/security info.

Solution / What to do

The phone number requested is only for account recovery or identity proofing, not for MFA sign-in.

SMS or voice will not be used for authentication if they are disabled tenant-wide.

To avoid this prompt, configure Registration Campaigns or allow an alternative backup method (such as FIDO2 security keys or Temporary Access Pass) instead of forcing full MFA re-registration.

If only the Authenticator needs to be reset, remove and re-add the Authenticator method rather than using “Require re-register MFA”.

https://learn.microsoft.com/en-in/entra/identity/authentication/howto-mfa-userdevicesettings
VEMULA SRISAI 12,615 Reputation points Microsoft External Staff Moderator

2026-04-24T14:32:41.74+00:00

Tilman Schmidt I’m following up on my previous response to see if it helped. Please feel free to reach out if you need any further assistance—I’m happy to help.
Tilman Schmidt 270 Reputation points

2026-04-27T08:16:15.8066667+00:00

I'm still waiting for the affected user to get back to me with a proposal when we can test it.
Tilman Schmidt 270 Reputation points

2026-04-27T13:03:47.6133333+00:00

Thank you for your reply. I just got the user to do a few tests with me, and now I am thoroughly confused:

In an attempt to avoid the prompt for the phone number, I tried to create a Temporary Access Pass for the user, but Entra refused that with an error message:

The declared reason for requiring the phone number is indeed verifying the user's identity. There is however no discernible attempt at actually doing that. I can enter whatever phone number I want and the verification code will be sent there. So an attacker could just enter her own phone number and get the code. Where does the verification happen?

After completing the verification step, the phone number used for verification appears on the user's Entra account as "usable authentication method". But in reality it isn't usable. When the user signs in and is asked for the second factor, he does not get the option of using SMS or phone call, only Authenticator push or OTP.

The reason why we do "Require re-register" is usually either some Entra malfunction, a suspected account compromise, or several identically named Microsoft Authenticator methods listed under "Usable authentication methods" with no way to distinguish which of them is actually in use. Can the "remove and re-add Authenticator method" procedure cover those use cases?

Thanks for your help.
VEMULA SRISAI 12,615 Reputation points Microsoft External Staff Moderator

2026-04-28T18:33:38.9733333+00:00

Tilman Schmidt This behavior is expected after using “Require re‑register multifactor authentication.” Even if SMS/Voice are disabled for MFA sign‑in, Entra ID may still require a phone number as security/identity verification info during re‑registration. This phone number is not used for MFA, which is why SMS/call never appears during sign‑in—only Microsoft Authenticator is available.

The phone verification step only confirms user presence during enrollment; it does not make the phone an active MFA method. To avoid this prompt in the future, remove and re‑add only the Microsoft Authenticator method instead of forcing full MFA re‑registration, or use alternatives like FIDO2 or properly scoped Temporary Access Pass flows.

This does not indicate a tenant misconfiguration or security gap.
Tilman Schmidt 270 Reputation points

2026-04-29T09:04:53.1366667+00:00

@VEMULA SRISAI Thanks for your explanation. It does not quite match my experience, though.

You write "it does not make the phone an active MFA method". But as I wrote, Microsoft Entra lists it as such.

You write "To avoid this prompt in the future, [...] use alternatives like [...] Temporary Access Pass flows". But as I wrote, creating a Temporary Access Pass is blocked by Microsoft Entra.

Also, I still don't understand how to apply your advice to "remove and re‑add only the Microsoft Authenticator method" in the use cases I described, for example in the case of a suspected account compromise when there are several Microsoft Authenticator methods listed under "Usable authentication methods", all of them called "iPhone 12".
VEMULA SRISAI 12,615 Reputation points Microsoft External Staff Moderator

2026-04-30T13:45:19.6466667+00:00

Tilman Schmidt This behavior is expected when “Require re‑register multifactor authentication” is used. That action forces the user through combined security info registration, which is shared by MFA and Self‑Service Password Reset (SSPR). In this flow, Entra ID validates that the user has sufficient security information, not only an MFA sign‑in method.

Even if SMS and Voice are disabled for MFA sign‑in tenant‑wide, Entra ID may still prompt for a phone number as security info if:

The user is in scope for SSPR, and

Your SSPR configuration requires more than one authentication method for password reset.

The phone number collected here is for identity verification / security info enrollment, not for MFA sign‑in. That is why:

The number appears under Authentication methods in the user profile

But SMS / voice never appear as sign‑in options, since they are disabled by policy

This is not a security bypass—the verification only proves possession of the entered number at enrollment time, which is by design.

About Temporary Access Pass (TAP) TAP creation or usage will fail if:

TAP is not enabled in Authentication methods > Policies, or

The user is not included in the TAP policy scope, or

A Conditional Access policy for “Register security information” still requires existing security info

Recommended operational approach

Instead of using Require re‑register MFA:

Remove the specific Microsoft Authenticator method(s) from the user (especially duplicate entries)

Revoke sign‑in sessions

Re‑add Microsoft Authenticator cleanly

Use TAP only after confirming the TAP policy and CA scope are correctly configured

This avoids triggering the full combined registration flow and prevents unwanted phone prompts.
VEMULA SRISAI 12,615 Reputation points Microsoft External Staff Moderator

2026-05-04T08:11:38.07+00:00

Tilman Schmidt ,I’m following up on my previous response to see if it helped. Please feel free to reach out if you need any further assistance—I’m happy to help.
Tilman Schmidt 270 Reputation points

2026-05-04T08:57:55.9033333+00:00

@VEMULA SRISAI I'm sorry but your response did not help. The behavior might be expected for you, but it certainly doesn't meet our expectations. None of the criteria you cite as causing Entra ID to prompt for a phone number apply, and yet it does. Our users should not, and do not want to, provide a phone number for identification, but Entra ID forces some of them to do so. It is not understandable, and thoroughly confusing to our helpdesk and security operators, that the phone number thus obtained subsequently appears as "usable authentication method" for the user. I still do not understand why I cannot create a TAP for the user since none of the reasons you list are present. And I find myself unable to apply your recommended operational approach because I do not know which of the Microsoft Authenticator methods listed is the specific one or the duplicate, and also I still cannot use TAP even though I confirmed TAP policy and CA scope to the best of my knowledge.
VEMULA SRISAI 12,615 Reputation points Microsoft External Staff Moderator

2026-05-06T05:17:41.1833333+00:00

Tilman Schmidt,This behavior is related to using “Require re‑register multifactor authentication”.That action forces the user through the combined security info registration flow (used by both MFA and SSPR), not just Microsoft Authenticator re‑enrollment. In this flow, Entra ID may require a phone number as security information, even if SMS/Voice are disabled for MFA sign‑in at tenant level.

Key points:

The phone number collected is not usable for MFA sign‑in; policy still blocks SMS/voice at sign‑in.

The verification step only proves possession of the entered number, not that it belongs to the user.

The phone appears under Authentication methods because it’s stored in the unified methods framework, but usability is enforced by policy, which is why users never see SMS/call during MFA.

For Temporary Access Pass, TAP creation should normally be allowed even if the user is not in scope to use it. If TAP creation itself is blocked despite policies and roles being correct, that does not align with documented behavior and should be treated as a product/support issue.

Operationally, to avoid this confusion:

Avoid Require re‑register MFA unless absolutely necessary.

For duplicate or suspicious Authenticator entries, remove specific Microsoft Authenticator methods from the user and revoke sessions, instead of forcing full re‑registration.

This is expected platform behavior, but the UX and labels are admittedly misleading.

Answer 1

This behavior is caused by how the different authentication method policies work together and by the fact that phone methods can still be enabled for the user through another policy, even if SMS and Voice are disabled in the new Authentication methods policy.

Key points from the documentation:

Microsoft Entra ID evaluates all authentication method policies independently. If a user is enabled for a method in any policy, the user can register and use that method. To fully block a method, it must be disabled in all policies. The documentation states:

“Settings aren't synchronized between the policies… a user who is enabled for an authentication method in any policy can register and use that method. To prevent users from using a method, it must be disabled in all policies.”

For phone-based methods this includes:
- The new Authentication methods policy (SMS, Voice calls)
- Legacy MFA policy (SMS, Phone call, Mobile phone, Office phone)
- Legacy SSPR policy (Mobile phone, Office phone)
The legacy SSPR/MFA settings can implicitly enable phone methods even if SMS/Voice are disabled in the new policy. For example, if Mobile phone is enabled for SSPR, users can still use both SMS and voice for password reset and may be prompted to register a phone number during combined registration.
Combined registration supports “Phone” and “Alternate phone” as methods and allows users to set phone as a default MFA method (phone call or text message). If phone is available to the user via any policy, the combined registration wizard can require it as a second method.
SMS sign-in has its own control under the SMS method. The note in the migration guidance explains that SMS can be enabled for sign-in and that this is separate from other uses of phone numbers.

Because of these interactions, the affected user is likely still targeted for phone methods by one of the legacy policies (MFA or SSPR), or by SMS sign-in settings, even though SMS and Voice are disabled in the new Authentication methods policy. That is why the combined registration experience forced a phone number as “method 2 of 2” for that user but not for others whose effective policy set is different.

To fix and prevent this:

Review the Authentication methods policy:
- Confirm that SMS and Voice calls are disabled for all users (or that the user is not in any included group).
- For SMS, verify the Use for sign-in option is disabled for the user’s scope if you do not want SMS sign-in.
Review legacy MFA policy:
- Ensure SMS, Phone call, Mobile phone, and Office phone are disabled for the user’s scope.
Review legacy SSPR policy:
- Ensure Mobile phone and Office phone are disabled for the user’s scope if you do not want any phone-based methods.
- Remember that enabling Mobile phone in SSPR implicitly allows both SMS and voice for password reset and can surface phone registration in the combined experience.
After aligning all three policy surfaces so that the user is not enabled for any phone method, use Require re-register multifactor authentication again for the affected user so that the registration flow is rebuilt based only on Microsoft Authenticator.

If any of these legacy settings remain enabled for that user (or for a group the user belongs to), Entra ID will continue to treat phone as an allowed method and may require it during registration.

References:

Share via

One Entra ID user is asked by Entra to add a phone number for authentication despite the method being disabled in our tenant

1 answer

Your answer