Number matching in Microsoft Authenticator cannot be switched off. It is enabled for every Authenticator push notification, in every tenant, and users cannot opt out. That one fact resolves most reports of authenticator number matching not working, because there is no toggle to find, no policy to repair and no rollout to wait for. What is almost always happening instead is that the sign-in in question is taking a path where number matching legitimately does not appear. Microsoft documents six such paths. Only one of them is a misconfiguration you can fix.
The reflex is to go hunting for the setting, which costs an afternoon in the Authentication methods policy and then another in the legacy multifactor authentication settings. Neither of them contains a number matching control. Which method a user is actually challenged with is decided by their registered methods and by how Conditional Access evaluates a sign-in, so that is where the diagnosis starts rather than in the Authenticator app. Every fact below was verified against Microsoft Learn on 12 October 2026.
There is no switch, so stop looking for one
Microsoft’s How number matching works in MFA push notifications for Authenticator article is blunt about this. Number matching is enabled for all Authenticator push notifications, and the FAQ answers the opt-out question with a flat no. There is no tenant setting, no group targeting and no per-user exclusion.
This matters because a great deal of the advice still ranking for this problem was written in 2023, when number matching was a feature being rolled out and there genuinely was a control for it. That control lived in the legacy multifactor authentication settings. Per the Manage authentication methods article, Microsoft announced the deprecation of managing authentication methods in the legacy MFA and self-service password reset policies in March 2023, and from 30 September 2025 authentication methods can no longer be managed in those legacy policies at all. Any instruction that tells you to visit that page and look for a number matching toggle is describing a control that has been gone for over a year.
The current location for anything method related is the Microsoft Entra admin center, under Entra ID, then Authentication methods, then Policies. Number matching will not be in there either. It is not a policy option.
Number matching not working: start with the method, not the app
The single most common cause is that the user was never challenged with an Authenticator push in the first place.
The number matching FAQ is explicit. If a user’s default authentication method is something other than Authenticator push notifications, there is no change to their default sign-in. If their default is TOTP in Authenticator, or a one-time passcode from another provider, or a phone call, they will never see a number, because number matching applies to push notifications and nothing else. The same article adds the useful corollary: regardless of their default method, any user who is prompted for an Authenticator push does see number matching.
So the question to answer first is not “why is number matching broken” but “which method did this sign-in actually use”. A user who added a TOTP code to Authenticator rather than registering the account for push notifications is using the same app, with the same icon, and will never once see a number. From the help desk’s side of the call this is indistinguishable from a broken feature.
This is also where authentication strength becomes relevant, because an authentication strength requirement can rule out push notifications entirely in favour of a phishing-resistant method. If a policy demands phishing-resistant MFA, the user gets a passkey or a certificate prompt, and the absence of a number is the policy working correctly.
Wearables, where the documentation contradicts itself
Number matching is not supported for push notifications on Apple Watch or Android wearable devices. The guidance is that wearable users approve on their phone instead.
Worth knowing: the same article’s FAQ also states that from the January 2023 Authenticator release for iOS there is no companion app for watchOS, because it is incompatible with Authenticator security features, and that you cannot install or use Authenticator on Apple Watch at all. Microsoft recommends deleting it from the watch. So one page simultaneously tells you that number matching is unsupported on Apple Watch and that Authenticator cannot run on Apple Watch. For Apple the exception is moot. For Android wearables it still stands, and that is the case to check.
AD FS, where the gap is a missing patch
The AD FS adapter supports number matching only on patched versions of Windows Server. On unpatched servers users keep seeing the Approve and Deny experience and never see a number. The updates Microsoft names are KB5007205 for Windows Server 2022, KB5007206 for Windows Server 2019, and KB5006669 for Windows Server 2016.
Those are all November and October 2021 updates, so any server inside a normal patch cycle has them. If you are seeing Approve and Deny through an AD FS sign-in in 2026, the interesting question is why that server is four years behind, and number matching is the least of what it is missing.
The NPS extension, where it is genuinely unsupported
This is the one case that is a real configuration problem rather than an expectations problem, and it is the one worth reading carefully if you terminate VPN or Remote Desktop Gateway through RADIUS.
NPS does not support number matching. What the current NPS extension supports instead is a time-based one-time passcode. From NPS extension version 1.2.2216.1 onward, a RADIUS connection prompts for a TOTP method rather than Approve and Deny, but only for users who have a TOTP method registered. Without one, those users continue to get Approve and Deny, which is the weaker experience number matching was introduced to replace.
On earlier extension versions the TOTP prompt has to be forced with a registry value. Versions earlier than 1.0.1.40 do not support it at all.
; Forces the NPS extension to require a TOTP instead of offering Approve/Deny.
; Set on the NPS server where the extension is installed, then restart the NPS service.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\AzureMfa
Name: OVERRIDE_NUMBER_MATCHING_WITH_OTP
Value: TRUE
The constraint that catches people is the authentication protocol. The NPS server must be configured to use PAP, because MSCHAPv2 does not support TOTP. If PAP is not in place, authorisation fails outright rather than falling back, and the NPS extension server logs a challenge event in the AuthZOptCh log in Event Viewer:
; The event written to the AuthZOptCh log when TOTP is required but PAP is not configured.
NPS extension for Azure MFA: Challenge requested in the Authentication extension for the user npstesting_ap.
Microsoft’s own instruction when PAP is not an option is to set OVERRIDE_NUMBER_MATCHING_WITH_OTP to FALSE and accept Approve and Deny push notifications. There is a second case with the same answer: if your organisation uses Remote Desktop Gateway and a user has registered both a TOTP code and Authenticator push, that user cannot satisfy the Microsoft Entra MFA challenge and Remote Desktop Gateway sign-in fails. The documented fix is again to set the value to FALSE.
I have not run the NPS extension path in production, and my own tenant is a lab with no RADIUS infrastructure behind it, so what follows is a reading of the documentation rather than a measurement. What the documentation describes is a design in which the stronger option, TOTP, is available only to users who happen to have registered a TOTP method, and in which the fallback for an incompatible protocol is to turn the stronger option off. If you depend on RADIUS, the honest reading is that number matching is not something you have, and the supported path is to retire the dependency rather than to configure around it.
Same device, no number, nothing wrong
When a user signs in to a Microsoft mobile app such as Teams or Outlook on the same device that runs Authenticator, they can reply Yes or No rather than typing a number. Microsoft’s reasoning is that the prompt only ever appears on the device that initiated the sign-in, so there is no additional risk.
Users signing in through Microsoft Edge, Chrome or Safari continue to enter the number. This is the detail that generates help desk tickets, because the same person sees a number in the browser on their laptop and a Yes or No button in Teams on their phone, concludes that the phone is broken, and reports it.
One related oddity, documented and easy to mistake for a rendering fault: in mobile iOS broker flows the number match request appears over the number after a two second delay. The option to recheck it is Show me the number again, and it exists only in those flows.
The failure modes
Four things present as number matching not working when the cause is in fact elsewhere.
The first is an outdated Authenticator. If a user runs a version old enough not to support number matching, authentication does not degrade gracefully, it fails. The documented remedy is to upgrade the app. A sign-in that fails outright, rather than succeeding without a number, points here.
The second is Azure Multifactor Authentication Server. Number matching is not enforced there because it is not a supported feature of that product, which is deprecated. If any part of your estate still authenticates through MFA Server, number matching is not coming to it.
The third is the legacy policy inheritance. Users enabled for MFA push notifications through the legacy MFA tenant-wide policy also get number matching, if that policy had notification through mobile app enabled. In other words number matching follows the push notification, not the policy that authorised it, so a tenant that never finished its migration to the Authentication methods policy still sees number matching. Confusing, but not a fault.
The fourth is not a number matching failure at all but gets reported as one: the approval succeeds and access is still refused. That is a token lifetime problem rather than an authentication problem, and it behaves the same way a PIM activation delay does. The factor was satisfied. The thing consuming the token had not noticed yet.
What I would do differently
Number matching is a defence against accidental approval, and it is worth having, but the way it is deployed quietly rewards the configurations that need it least. A fully cloud tenant on the Authentication methods policy gets it everywhere, automatically, with no administrative effort. A tenant with AD FS, a RADIUS dependency and a population of wearable users gets it in some places, not others, with no report anywhere that tells you which users fall into which group. There is no dashboard for this, and the absence is felt.
So I would not treat number matching as a control to be verified. There is nothing to verify. I would instead do two things that are visible and measurable.
The first is to turn on additional context, which is a separate feature and genuinely optional. Per Use additional context in Authenticator notifications, you can show the application name and the geographic location of the sign-in in the notification, and the two are enabled independently through the Authentication methods policy. Number matching stops a user approving by reflex. Additional context is what lets them notice that the request came from a country they are not in. It is the half of the defence that is actually under your control, and it is off by default.
// The two featureSettings properties that control additional context on the
// MicrosoftAuthenticator configuration. PATCH the full schema after a GET,
// or you will overwrite the existing includeTargets.
// GET https://graph.microsoft.com/v1.0/authenticationMethodsPolicy/authenticationMethodConfigurations/MicrosoftAuthenticator
{
"featureSettings": {
"displayAppInformationRequiredState": { "state": "enabled" },
"displayLocationInformationRequiredState": { "state": "enabled" }
}
}
Graph Explorer needs consent for Policy.Read.All and Policy.ReadWrite.AuthenticationMethod before that call will run. The geographic location is derived from the sign-in IP address, which is worth saying out loud to anyone who is about to combine it with named locations and expect precision from it.
The second is to stop counting push notifications as a strong factor in the places that matter. Number matching makes a push harder to approve by accident. It does nothing about a push the user approves deliberately because the attacker asked them to, and it is not phishing resistant. The admin accounts and the high-value applications want an authentication strength requirement rather than a better push prompt, in the same way that Entra ID password protection raises the floor without ever being the thing that stops a determined attacker.
When someone reports number matching not working, the useful first question is which method the sign-in actually used. Six times out of six in the documentation, the answer explains it.
Last verified: 12 October 2026
