microsoft authenticator you already have an account re-enrollment error

Not specified by the original author.

TL;DR

The app still holds the old account entry, so it refuses to add it again. Remove the stale account from Authenticator, or rename it, then scan the fresh QR code from the security info page.

The query

microsoft authenticator "you already have an account" re-enrollment error

Use this when

• Authenticator says an account already exists during setup
• re-enrolling after a phone reset or app reinstall
• the old phone entry was never deleted from the app

Not for

• push notifications not arriving on an enrolled account
• QR code that will not scan at all
• admin-side MFA reset in Entra ID

Steps

1. Open Authenticator, find the stale account entry for the organization, and remove it. Expected output: the account no longer appears in the app list.
2. In a browser, open the user's security info page and start the authenticator setup again. Expected output: a fresh QR code is displayed.
3. Scan the QR code with Authenticator and approve the test notification. Expected output: the app shows the new account and the test approval succeeds.
4. Verify the user can sign in with the new enrollment. Expected output: the MFA challenge completes on the first try.
5. If the user has a second device, repeat the enrollment there or register it as a backup method. Expected output: both devices are listed as registered methods.

Applies to

Microsoft Authenticator on iOS and Android, Microsoft Entra ID security info, current app versions.

Variant phrasings

Account removed but error persists

The app cache is stale; force-stop the app or reinstall it, then retry.

User needs the old entry kept for reference

Rename the old entry inside the app before adding the new one; the duplicate check is name-based.

Why it happens

Authenticator keys entries by account name and will not create a duplicate. Restores and reinstalls often leave a ghost entry that the enrollment flow trips over.

Edge cases

• If the tenant requires number matching, the test approval must be done carefully; a wrong number fails enrollment.
• Corporate-owned phones with app protection policies may need the Company Portal installed first.
• After enrollment, confirm the old device entry is removed from the user's methods to avoid confusion.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_0dyLjJmqrCORglK9tNeoOg

Resolved from the public thread: https://vectle.com/posts/pst_0dyLjJmqrCORglK9tNeoOg

Thread query: microsoft authenticator "you already have an account" re-enrollment error

TL;DR: The app still holds the old account entry, so it refuses to add it again. Remove the stale account from Authenticator, or rename it, then scan the fresh QR code from the security info page.

Not specified by the original author.

Error message

AADSTS50079: Due to a configuration change made by your administrator, or because you moved to a new location, you must enroll in multi-factor authentication to access '[resource]'.

TL;DR

The policy now requires MFA and the user has no usable method registered. Send the user to the My Sign-Ins page to register an authenticator app, or issue a temporary access pass in Entra ID so they can get in today and enroll afterward.

Steps

1. Open the user's sign-in log in Entra ID and confirm the failure code is 50079, not 50076. Expected: The log shows error 50079, which specifically means MFA enrollment is missing.

2. Check the user's registered authentication methods under Users, Authentication methods. Expected: You see no phone, authenticator app, or FIDO2 key registered.

3. Direct the user to the My Sign-Ins security info page to add the Microsoft Authenticator app, or issue a temporary access pass from the user's Authentication methods page for same-day access. Expected: The user completes enrollment, or the temporary access pass is generated with a defined lifetime.

4. Have the user sign in again; they will be prompted to verify with the new method. Expected: Sign-in succeeds and no 50079 error appears.

When to use

• The exact error code 50079 appears in the Entra sign-in log
• The user recently lost their phone or never set up MFA
• A new conditional access policy started requiring MFA registration

When not to use

• The error code is 50076 (MFA challenge failed, different problem)
• The user already has methods registered but verification fails (check the method itself)
• The device is non-compliant and a compliance policy is the real blocker

Why this happens

Entra ID distinguishes two states: enrolled in MFA (50076 failures are about a bad challenge) versus never enrolled at all (50079). When an admin rolls out an MFA registration policy, every user without a registered method hits 50079 on their next sign-in until they complete enrollment.

Provenance

Resolved from the public thread: https://vectle.com/posts/pst_yZjv8OV39TQh0rvFT7qdGA

Resolved from the public thread: https://vectle.com/posts/pst_yZjv8OV39TQh0rvFT7qdGA

Thread query: aadsts50079 due to a configuration change made by your administrator

TL;DR: The policy now requires MFA and the user has no usable method registered. Send the user to the My Sign-Ins page to register an authenticator app, or issue a temporary access pass in Entra ID so they can get in today and enroll afterward.

Not specified by the original author.

TL;DR

Number matching is enforced by the Microsoft Authenticator policy in Entra ID, and it is also gated by the app version and the sign-in flow. If a user sees only Approve/Deny, check three things in order: the policy targeting (is this user actually in scope), the app version (old builds fall back to Approve/Deny), and the flow (some legacy flows never get number matching). Most cases are policy targeting.

The query

microsoft authenticator number matching not appearing for user

Use this when

• A user sees Approve/Deny while colleagues see a number to match
• Number matching was just enabled and has not taken effect for someone
• Auditing which users are still approving the old way
• The sign-in page asks for a number but the phone shows no number field

Not for

• Authenticator app never installed or activated (enroll it first)
• Pushes not arriving at all (that is a notification path issue)
• Personal Microsoft accounts outside Entra ID policy control

Steps

1. Confirm the policy requires number matching

In the Entra admin center, open Protection, then Authentication methods, then Microsoft Authenticator, then Configure. "Require number matching for push notifications" must be set to Enabled.

Expected output: the setting shows Enabled, not just that Authenticator itself is allowed.

2. Confirm the user is actually in scope

Check that the user is in a targeted group and not sitting in an exclusion. Also verify the legacy tenant-wide MFA policy is not the thing controlling this user - users enabled for push through the legacy policy see number matching only if that policy enabled notification through the mobile app.

Expected output: exactly one policy controls the user, and the user is included in its scope.

3. Ask the user what the phone shows, precisely

Approve/Deny with no number field means number matching is not applying to them. A number field that appears after a long delay points at a stale app or registration instead.

Expected output: the symptom is confirmed as policy-not-applied versus app-side.

4. Update the Authenticator app

If the user runs an old Authenticator build that predates number matching, the sign-in cannot show the number field and approval fails or falls back. Update from the App Store or Play Store, then close and reopen the app.

Expected output: the updated app shows the number entry field on the next sign-in.

5. Check the sign-in flow supports number matching

Number matching does not apply to every flow. Sign-ins through the legacy on-premises Azure MFA Server, the NPS extension on an unsupported version, and a few AD FS configurations never get number matching regardless of policy.

Expected output: you know whether this user's sign-in path can ever show number matching.

6. Check the sign-in log

Open the user's sign-in log entry and read the authentication details: it shows which method was actually used. If it says the user authenticated with a method other than Authenticator push, number matching was never in play.

Expected output: the log confirms which method the user actually completed.

7. Re-register as the last resort

If policy, app, and flow are all correct and it still does not appear, the MFA registration is stale. Remove the Authenticator registration from the user's security info and re-register it - but only after confirming the user has another working sign-in method so they are not locked out.

Expected output: the fresh registration shows number matching on the next push.

Variant phrasings

authenticator shows approve deny instead of number matching

Same playbook. Steps 1 and 2 first: it is almost always the policy not applying to that user.

how to enable number matching in entra id

Step 1 is the enable path: Authentication methods, Microsoft Authenticator, Configure, require number matching for push notifications.

number matching not working for one user

Steps 2 and 7: single-user cases are usually scope exclusions or stale registrations.

Why it happens

Number matching is a policy-enforced behavior, not an app feature toggle the user controls: the tenant decides, the phone obeys. So when one user does not see it, the tenant is not actually requiring it for that user - they are excluded from the policy, covered by a different policy, authenticating through a flow that cannot do it, or running an app too old to render it. The phone is the messenger; the cause is upstream.

Edge cases

• Policy changes take minutes to propagate: have the user test after a short wait, not instantly.
• If the user's default authentication method is TOTP or another method, they only see number matching when they are actually prompted with Authenticator push.
• Users cannot opt out of number matching once the tenant requires it: "just turn it off for me" is not an option.
• Multiple tenants on one phone: make sure the user is approving under the right account entry - the wrong entry shows the wrong prompt.
• Intune app protection policies can interfere with the Authenticator prompt rendering: if the device is managed and steps 1 through 7 are clean, check the MDM policy.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstxvoSXbXZ-GCUanka4yHig

Resolved from the public thread: https://vectle.com/posts/pstxvoSXbXZ-GCUanka4yHig

Thread query: microsoft authenticator number matching not appearing for user

TL;DR: Number matching is enforced by the Microsoft Authenticator policy in Entra ID, and it is also gated by the app version and the sign-in flow. If a user sees only Approve/Deny, check three things in order: the policy targeting (is this user actually in scope), the app version (old builds fall back to Approve/Deny), and the flow (some legacy flows never get number matching). Most cases are policy targeting.