Category: Multi-Factor Methods

Push-Based MFA

Also known as: Push Notification Authentication, Push Authentication, Push Notification MFA

Simply put

Push-based MFA is a way of confirming your identity by responding to a notification sent to an app on your phone when you try to log in. Instead of typing in a code, you typically approve or deny the sign-in attempt directly from your device. This provides an additional check beyond a password to help verify that the person logging in is really you.

Formal definition

Push-based MFA is a multi-factor authentication method that uses a possession factor: an authenticator app registered to a user's mobile device receives a push notification from the service provider during a sign-in attempt, and the user approves or denies the request in-app. It serves as an additional authentication factor alongside a primary credential (commonly a password), and depending on configuration it may satisfy 2FA or broader MFA requirements. Because simple approve/deny prompts are susceptible to MFA fatigue and accidental approval, many deployments layer on number matching, where the user must enter or confirm a short numeric code shown on the sign-in screen within the authenticator app to bind the approval to the specific session. Push-based MFA typically requires an internet connection on the device; it addresses authentication (verifying who the principal is) and is out of scope for authorization decisions.

Why it matters

Push-based MFA became widely adopted because it reduces friction compared to manually typing one-time codes: the user simply approves or denies a prompt on a device they already carry. As a possession-factor method, it strengthens authentication beyond a password alone, which is significant given how frequently password-only accounts are compromised through phishing, credential reuse, and brute-force attacks. For many organizations, push-based MFA offers a practical balance between security and usability that encourages broad enrollment.

However, the same low-friction design that makes push notifications convenient also introduces a well-documented weakness: MFA fatigue (also called prompt bombing). When an attacker already holds a valid password, they can repeatedly trigger push prompts in the hope that a distracted or annoyed user will eventually tap approve. A simple binary approve/deny prompt gives the user little context about which session they are authorizing, making accidental approval a real risk. This is why many deployments have moved toward number matching, in which the user must confirm a short numeric code displayed on the sign-in screen, binding the approval to the specific session that requested it.

Because push-based MFA typically depends on the device having an internet connection and on the integrity of the authenticator app, IAM teams should treat it as one option among several rather than a universal solution. Its effectiveness varies with configuration, particularly whether number matching or similar session-binding controls are enabled, and it addresses authentication only, not authorization.

Who it's relevant to

IAM Engineers and Security Architects

Those designing authentication flows need to decide when push-based MFA is appropriate and how to harden it. Enabling number matching and other session-binding controls is often the practical difference between a resilient deployment and one exposed to MFA fatigue attacks. Architects should also account for the internet-connection dependency and enrollment lifecycle of authenticator apps.

System Administrators

Administrators configuring and rolling out MFA policies are responsible for choosing between simple approve/deny prompts and number-matching variants, and for guiding user enrollment of authenticator apps on registered devices. They also handle the operational realities, such as users who lack connectivity or lose access to their enrolled device.

Compliance Officers and Identity Governance Leads

Those responsible for meeting MFA requirements need to understand that push-based MFA may satisfy 2FA or broader MFA mandates depending on configuration, and that the security posture varies with whether number matching is enabled. This distinction can matter when demonstrating that authentication controls meaningfully mitigate credential-based attacks.

Security Operations Teams

SOC analysts and incident responders should recognize repeated or unexpected push prompts as a potential indicator of MFA fatigue attacks against users whose passwords may already be compromised. Understanding how number matching changes attacker behavior helps in tuning detection and user-education efforts.

Inside Push-Based MFA

Push Notification Challenge

A prompt delivered to a previously registered device, typically via a vendor's authenticator app, asking the user to approve or deny an authentication attempt. This serves as a possession factor in an MFA or 2FA flow, since control of the enrolled device is what is being verified.

Enrolled Device and App Binding

The registered mobile device and its authenticator app instance, typically bound to the user's account during enrollment. The binding often relies on a key pair or device-specific secret established at registration, though the exact mechanism depends on the vendor and configuration.

Approve/Deny Response

The user's action on the challenge, returned to the identity provider or authentication service to complete or reject the authentication step. This response contributes to authentication (verifying the principal), not authorization (determining what the principal may do).

Out-of-Band Channel

Push-based MFA typically uses a separate communication channel from the primary login session, so the challenge and response do not travel over the same path as the initial credential entry. This separation is a design goal, though its security benefit depends on deployment specifics.

Relationship to Other Factors

In most deployments push-based MFA is combined with a first factor such as a password (knowledge factor), making the overall flow multi-factor. The push approval itself represents the possession factor rather than a standalone authentication method.

Common questions

Answers to the questions practitioners most commonly ask about Push-Based MFA.

Does push-based MFA authenticate the user, or just the device?

Push-based MFA primarily verifies control of a registered device, which serves as a possession factor. Approving a push notification confirms that the person responding has access to the enrolled device, not necessarily that they are the legitimate user. Unless the approval step is additionally gated by a knowledge or inherence factor (for example, a device PIN or biometric unlock enforced by the authenticator app), push approval alone establishes possession rather than fully authenticating the individual. Treat it as one factor within an authentication flow, not as complete proof of identity on its own.

Is push-based MFA inherently phishing-resistant?

Not by default. Standard push-based MFA is vulnerable to real-time relay and, notably, to MFA fatigue (also called push bombing), where an attacker who already has valid credentials repeatedly triggers push prompts hoping the user approves one. Because the approval is typically a simple accept/deny decision decoupled from the origin the user is actually visiting, it does not provide the cryptographic origin binding that phishing-resistant methods such as FIDO2/WebAuthn offer. Some deployments add number matching or contextual details to the prompt to reduce these risks, but these are mitigations, not equivalents to phishing-resistant authentication.

What can be done to reduce MFA fatigue attacks in a push-based deployment?

In most deployments, common mitigations include enabling number matching (requiring the user to enter a code shown on the login screen into the app), displaying context such as application name, location, and IP address in the prompt, rate-limiting or throttling repeated push requests, and alerting or auto-denying after a threshold of denied prompts. Depending on the vendor, administrators may also combine push with a device-side biometric or PIN unlock so that mere approval requires an additional factor. These measures reduce, but do not eliminate, the underlying risk.

How should push-based MFA be handled when the enrolled device is offline or unreachable?

Because push delivery depends on network connectivity and, typically, a push notification service, deployments generally need a fallback method. Common approaches include a TOTP code generated locally in the same authenticator app, hardware tokens, or backup codes issued during enrollment. The choice of fallback affects your overall assurance level and should be documented, since some fallbacks may be weaker or more phishable than the primary push method. Recovery and fallback flows are frequent targets for attackers and warrant the same scrutiny as the primary factor.

How does push-based MFA fit with step-up authentication?

Push can serve as either a primary MFA factor at initial login or as a step-up challenge invoked when a session attempts a higher-risk action or accesses a more sensitive resource. In a step-up model, the policy decision point evaluates risk or resource sensitivity and requires the additional push approval at that point rather than at every interaction. Whether push is appropriate for step-up depends on the assurance you need for the protected action; for high-value operations, a phishing-resistant factor may be more suitable than standard push.

What device enrollment and lifecycle concerns apply to push-based MFA?

Since push relies on a registered device as the possession factor, enrollment binding, re-enrollment on device replacement, and prompt deregistration on loss or offboarding are critical. These are identity lifecycle and administration concerns rather than runtime enforcement, and they typically intersect with provisioning and deprovisioning processes. Weak enrollment (for example, allowing self-registration of a new device using only a single factor) can undermine the strength of the push factor at authentication time, so enrollment assurance should be aligned with the assurance expected from the factor itself.

Common misconceptions

A push approval authorizes what the user can access.

Approving a push challenge is part of authentication, confirming the principal's identity via possession of the enrolled device. What the authenticated principal may then do is determined separately by authorization, which push-based MFA does not address.

Push-based MFA is inherently more secure than all other second factors and immune to attack.

Push-based MFA improves on some methods in usability but is susceptible to risks such as MFA fatigue or prompt-bombing, where users may approve fraudulent prompts. Its relative security depends on configuration, and it should not be presented as universally superior.

Push-based MFA and passwordless authentication are the same thing.

Push-based MFA is typically used as an additional factor alongside a knowledge factor such as a password. It is distinct from passwordless authentication, which eliminates the knowledge factor entirely, and from FIDO2/WebAuthn passkey flows, which use different mechanisms.

Best practices

Enable number matching or a similar challenge-response confirmation where supported, so users must actively transcribe or select a value rather than blindly tapping approve, reducing MFA fatigue risk.

Apply throttling and lockout controls on repeated push requests to defend against prompt-bombing, and alert users or administrators when an unusual volume of challenges occurs.

Display contextual information in the prompt, such as location, application, or requesting IP where available, so users can make an informed approve/deny decision.

Treat push-based MFA as one option within a broader factor strategy and provide fallback or alternative factors, since availability depends on the user having an enrolled, connected device.

Verify the integrity of the device enrollment and binding process, and provide a controlled re-enrollment path for lost or replaced devices to prevent orphaned or hijacked bindings.

For higher-assurance transactions, consider combining push approval with step-up authentication or phishing-resistant factors rather than relying on push alone, based on your risk assessment.