Category: Multi-Factor Methods

Number Matching

Also known as: Number Match, MFA Number Matching

Simply put

Number Matching is a security feature used in push-based multi-factor authentication where the person signing in must read a number shown on their sign-in screen and type it into their authenticator app to approve the request. It is designed to stop attackers from getting an approval through blind, repeated push notifications, since the user cannot approve without seeing the correct number.

Formal definition

Number Matching is an anti-MFA-fatigue control applied to push-notification-based approval flows (a possession-factor authentication method). During authentication, the identity provider or authentication service displays a challenge number on the primary sign-in surface; the user must enter that number into the corresponding authenticator application to complete the possession-factor verification, rather than merely tapping an Approve button. This binds the approval action to information available only on the legitimate sign-in session, mitigating MFA-fatigue (push-bombing) attacks in which an adversary who already holds valid primary credentials triggers repeated push prompts hoping the user approves one. Note that Number Matching addresses only the approval-confirmation step within an already-configured MFA flow; it does not by itself replace phishing-resistant methods such as FIDO2/WebAuthn, and its exact behavior, prompt content, and enrollment requirements vary by vendor and deployment configuration.

Why it matters

Push-based multi-factor authentication improved on SMS and one-time-password methods by making approval a single tap, but that convenience introduced a specific weakness: MFA-fatigue, also called push-bombing. An adversary who already holds a user's valid primary credentials can trigger a flood of push prompts, betting that the user will eventually approve one out of confusion, annoyance, or the mistaken belief that the prompts are legitimate. Because a simple Approve tap requires no context from the actual sign-in session, the user has no reliable way to distinguish their own login attempt from an attacker's. Number Matching directly closes this gap by requiring the user to transcribe a number displayed on the legitimate sign-in surface into their authenticator app, so approval cannot be granted blindly.

For identity teams, Number Matching represents a low-friction hardening step that can be applied to existing push-notification MFA deployments without migrating users to entirely new authentication methods. It raises the cost of credential-based attacks that would otherwise succeed at the approval step, and it does so while preserving most of the usability of push approval. This makes it an attractive intermediate control for organizations that cannot immediately roll out phishing-resistant methods across their entire user population.

It is important to scope its protection accurately. Number Matching hardens only the approval-confirmation step within an already-configured MFA flow. It does not defend against real-time phishing or adversary-in-the-middle attacks in the way that phishing-resistant methods such as FIDO2/WebAuthn do, and it should not be treated as a substitute for them. Its exact prompt content, enforcement behavior, and enrollment requirements vary by vendor and deployment configuration.

Who it's relevant to

IAM engineers and authentication administrators

Teams that operate push-based MFA can enable Number Matching to mitigate push-bombing without re-enrolling users into new authenticators. They should confirm the exact enforcement and enrollment behavior for their identity platform, since prompt content and configuration options vary by vendor and deployment.

Security architects

Architects evaluating defense-in-depth should treat Number Matching as a hardening measure for the approval step of existing push MFA, not as a replacement for phishing-resistant methods such as FIDO2/WebAuthn. It is best positioned as an interim or complementary control while planning toward phishing-resistant authentication.

Incident responders and SOC teams

Teams investigating credential-based intrusions should understand that Number Matching reduces the likelihood of an accidental blind approval during an MFA-fatigue attack. Its presence changes the threat model: an attacker who cannot see the sign-in screen's challenge number cannot complete the approval, which is relevant when assessing how an account was or was not compromised.

Compliance and governance leads

Those documenting authentication controls should record Number Matching as a specific mitigation applied to push-approval flows, while noting its scope limitations. It addresses the approval-confirmation step only and does not by itself satisfy requirements that call for phishing-resistant authentication.

Inside Number Matching

Number matching challenge

A verification step in push-based authentication where the authenticating service displays a number (typically a two-digit code) on the sign-in screen, and the user must enter that number into their authenticator app to approve the request. This binds the approval action to the specific in-progress authentication attempt.

Push notification approval flow

Number matching augments the standard mobile push authentication flow. Rather than a simple approve/deny prompt, the user is required to transcribe the displayed number, which raises the effort and intentionality required to complete the possession-factor challenge.

MFA-fatigue mitigation

The feature primarily targets MFA-fatigue (also called prompt-bombing or push-bombing) attacks, in which an attacker who already holds valid credentials repeatedly triggers push prompts hoping the legitimate user reflexively approves one. Requiring a number that only appears on the attacker-initiated sign-in screen prevents blind approval.

Possession factor role

Number matching operates within the possession factor of MFA, since it depends on the user controlling a registered authenticator device. It strengthens how that possession factor is exercised but does not itself constitute a separate authentication factor.

Common questions

Answers to the questions practitioners most commonly ask about Number Matching.

Does number matching add a second authentication factor to my sign-in?

No. Number matching does not introduce an additional factor. It is a mechanism applied within push-based authentication, which is typically a possession-factor approval, to make that approval more deliberate. Rather than tapping a simple approve button, the user must read a number shown on the sign-in screen and type it into the authenticator app. This strengthens the integrity of an existing possession-based approval; it does not by itself convert a single-factor push into MFA or add a knowledge or inherence factor.

Is number matching the same as entering a one-time passcode (OTP)?

No. With an OTP, such as a TOTP or SMS code, the code originates at the authenticator or server and the user copies it into the sign-in prompt to prove possession. With number matching, the number is displayed at the sign-in surface and the user enters it into the push-approval app, binding the specific sign-in session to the approval on the device. The direction of the challenge and the purpose differ: OTP is a possession-factor proof, while number matching is an integrity control layered onto a push approval to counter blind or reflexive approvals.

What problem is number matching primarily intended to mitigate?

It is intended to reduce the effectiveness of MFA fatigue, also called MFA bombing or prompt bombing, where an attacker who already holds valid credentials repeatedly triggers push approvals hoping the legitimate user eventually taps approve. By requiring the user to enter a number that is only visible on the actual sign-in screen, an approval cannot succeed unless the user is looking at the genuine authentication attempt, which raises the difficulty of a reflexive or coerced approval.

Where does number matching fit in the authentication flow, and does it affect authorization decisions?

Number matching operates at the authentication step, specifically during the verification of a possession-based push approval, after identification and before any authorization decision. It does not evaluate what a principal may do; authorization is handled separately by policy evaluation once authentication completes. In most deployments it should be treated as a hardening of the authenticator experience rather than a change to access policy logic.

Does enabling number matching require changes to my applications or federation configuration?

Typically not at the application layer. Number matching is generally configured within the identity provider and its authenticator app rather than in relying applications, so SAML, OAuth 2.0, or OpenID Connect integrations usually need no change. The exact configuration surface and any conditional scoping depend on the vendor and deployment context, so confirm behavior in your specific identity platform before assuming universal applicability.

What user-experience and support considerations should I plan for before rolling out number matching?

Because number matching adds a step where users must read and enter a displayed value, plan for user communication and helpdesk readiness, since some users accustomed to one-tap approval may be confused initially. Consider accessibility needs, scenarios where the sign-in screen and the device are not both easily visible, and fallback authentication methods for users who cannot complete the match. Behavior around enforcement scope, exclusions, and fallback varies by vendor and configuration, so validate these paths during a pilot.

Common misconceptions

Number matching is a separate authentication factor that adds security on top of existing factors.

Number matching is not an additional factor. It is a hardening of the approval mechanism within the possession-based push flow, designed to ensure the approval is intentional and bound to the correct session rather than to add a new factor category.

Number matching prevents all MFA bypass and phishing attacks.

Its primary purpose is mitigating MFA-fatigue/push-bombing where credentials are already compromised. It does not by itself defeat real-time adversary-in-the-middle phishing that proxies both credentials and the approval; phishing-resistant methods such as FIDO2/WebAuthn address that threat more directly. Effectiveness depends on configuration and deployment context.

The displayed number is a secret or one-time password the user must keep confidential.

The number is a session-binding value shown on the sign-in screen to be transcribed into the authenticator; its security value comes from the fact that a remote attacker triggering the prompt cannot see the user's sign-in screen, not from it being a secret credential in the OTP sense.

Best practices

Enable number matching for push-based authentication to reduce the risk of users blindly approving fraudulent prompts during MFA-fatigue attacks; note that Microsoft began enforcing number matching tenant-wide for Authenticator push notifications starting May 2023.

Treat number matching as a complement to, not a replacement for, phishing-resistant authentication such as FIDO2/WebAuthn or passkeys where the threat model includes adversary-in-the-middle phishing.

Align number matching with published guidance, including CISA's recommendation of number matching as a mitigation against MFA-fatigue attacks, and document it in your authentication hardening standards.

Educate users that a number matching prompt they did not initiate is a signal of possible credential compromise and should be denied and reported, not approved to make the prompts stop.

Monitor and alert on repeated denied or unmatched push attempts, as these can indicate an active push-bombing attempt against an account whose credentials are already exposed.

Verify behavior and rollout across your specific authenticator apps and platform versions, since exact prompt presentation and enforcement can vary by vendor and configuration.