## 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

```text
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/pst_x_voSXbXZ-GCUanka4yHig