TL;DR: Repeated breaches tied to MFA fatigue, phishing, and social engineering show why mobile push is an easy-to-bypass lock and why phishing-resistant MFA based on asymmetric cryptography better fits cloud identity, according to Axiad. The decisive shift is from user-persuasion controls to authentication methods that remove approval abuse from the attack path.
At a glance
What this is: This is an analysis of why mobile push MFA remains weak against MFA fatigue and social engineering, and why phishing-resistant MFA changes the identity attack surface.
Why it matters: IAM and security teams need to treat authentication choice as a control decision, because the wrong MFA pattern keeps approval abuse and account takeover pathways open.
Context
The core problem is not whether MFA exists, but whether the factor can be coerced, fatigued, or socially engineered into approving access. In identity security terms, a control that depends on user patience is still exposed to attacker pressure.
For cloud and SaaS access, the lock must fit the identity journey across devices and applications, not just the login screen. Axiad's article argues that phishing-resistant MFA is the more durable model because it removes the attacker from the approval loop rather than trying to train the user through it.
Key questions
Q: What is the difference between push-based MFA and phishing-resistant authentication?
A: Push-based MFA asks a person to approve a login request, which attackers can abuse through fatigue or social engineering. Phishing-resistant authentication binds access to a device or key and verifies possession cryptographically, so the attacker cannot win by repeatedly asking for approval.
Q: Why do MFA fatigue attacks still work when MFA is already deployed?
A: They work because MFA often assumes a legitimate user will distinguish a real prompt from an attacker-generated one. When attackers can trigger repeated notifications, the control becomes a behaviour test rather than a cryptographic barrier, and the human is the weakest part of the chain.
Q: Should organisations replace MFA or improve it with stronger factors?
A: They should improve it with stronger factors rather than abandon it. Passwordless methods and public key-based authenticators reduce credential theft and prompt fatigue exposure, while step-up controls keep the strongest checks for the highest-risk actions instead of forcing them on every login.
A: Security teams should move beyond SMS OTP as the primary second factor and use phishing-resistant methods such as passkeys, WebAuthn hardware tokens, or app-based authenticators. Add device fingerprinting and step-up authentication for unusual logins or high-risk actions. The goal is to make interception harder while limiting extra prompts to situations where the risk signal justifies them.
Technical breakdown
Why mobile push MFA is easy to bypass
Mobile push works by sending an approval request to a user's phone after an authentication attempt. That design lowers friction, but it also creates a pressure point: attackers can trigger repeated prompts until the user approves one just to stop the noise. Social engineering compounds the weakness when the attacker poses as IT or help desk staff and frames approval as a support action. The weakness is not the phone itself, but the dependence on human reaction as the final control gate.
Practical implication: treat push approval as a convenience control, not a phishing-resistant control, for high-risk access.
How phishing-resistant MFA changes the authentication path
Phishing-resistant MFA relies on asymmetric cryptography, where the private key stays bound to the authenticating party and cannot be replayed like a shared secret or one-time code. Because the user initiates the authentication exchange and the response is cryptographically bound to the origin, an attacker cannot simply bombard the user with approval requests and inherit access. This is the key architectural difference: the control no longer depends on persuading a person to approve a prompt under pressure. It depends on proving possession of a private key in the right session context.
Practical implication: prioritise authentication methods that bind the response to the real origin and remove approval-based bypass paths.
Why identity needs consistent lock choices across SaaS and device access
The article's broader point is that identity is the key for cloud systems, so lock design has to work across applications, devices, and operating systems. Fragmented MFA decisions create uneven protection, especially when different user populations and use cases are covered by different authentication methods. A coherent identity security programme should therefore align authentication strength with access risk rather than leaving individual teams to choose whatever is easiest to deploy. That is where the security model either holds together or breaks apart.
Practical implication: standardise phishing-resistant authentication policy for high-value access instead of letting MFA selection drift by application or team.
Breaches seen in the wild
- Co-op cyber attack 2025: Attackers linked to Scattered Spider tricked their way into a Co-op employee account and stole personal data of all 6.5 million members.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 150+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Push-based MFA is an approval-abuse problem, not a user-training problem. Repeated prompts turn the human into the last line of defence, which means attacker persistence can eventually outrun user attention. The relevant governance failure is the assumption that a user can reliably distinguish legitimate demand from coercive pressure in the moment. Practitioners should treat approval-based MFA as a control with an inherent social-engineering failure mode.
Phishing-resistant MFA changes the control from persuasion to cryptographic proof. Asymmetric cryptography removes the replayable approval path that attackers exploit in push fatigue attacks. That matters because the security property is no longer whether the user is willing to tap a button, but whether the authenticator can prove possession in the right context. The implication is that identity programmes should measure authentication strength by attack resistance, not deployment convenience.
Identity attack surface is now a lock-selection problem. The article is right to frame identity as the key, because cloud access rises or falls on which lock sits in front of the account. When MFA variants are mixed across apps, the weakest path becomes the preferred attack path, and that weak path often remains push-based. Practitioners need a deliberate authentication architecture, not a patchwork of locally convenient choices.
Zero Trust only works when the authentication layer stops being socially negotiable. Zero Trust assumes continuous verification, but continuous verification loses value if the verification method can be manipulated by nuisance, urgency, or impersonation. Phishing-resistant MFA preserves the intent of Zero Trust by making the authentication step harder to coerce. The practical conclusion is that auth method selection is a Zero Trust control decision, not an end-user preference setting.
From our research library:
- 1 in 3 organisations encountered suspicious AI agent activity in 2025, and 99.4% experienced a SaaS or AI ecosystem incident.
What this signals
Approval-based authentication is now a governance liability. When a control can be exhausted through repeated prompts or urgent impersonation, the programme is no longer measuring identity assurance, only user endurance. The right question is not whether MFA exists, but whether the chosen factor can resist coercion at the point of approval.
Phishing resistance is an authentication design choice, not a branding label. The article points to a broader programme shift: high-risk access needs methods that bind the response to the real session and remove the attacker from the approval loop. That is where authentication policy starts to matter as identity architecture, not just login UX.
For practitioners
- Standardise phishing-resistant MFA for privileged and high-risk access Reserve push-based approval for low-risk scenarios only, and move administrative, remote, and SaaS access to cryptographically bound authentication methods that cannot be replayed through prompt bombing.
- Map authentication methods to attack resistance Review where your current MFA mix still depends on user approval, then rank those paths by exposure to phishing, fatigue, and help desk impersonation.
- Eliminate approval-based bypass paths Remove workflows that let attackers use repeated prompts or urgent support stories to drive a manual tap, especially where access leads to email, ERP, or cloud consoles.
- Align Zero Trust policy to authentication strength Tie access policy to methods that prove possession cryptographically, so verification does not depend on user behaviour under pressure.
Key takeaways
- Mobile push MFA remains vulnerable because attackers can combine fatigue, impersonation, and repeated prompts to push users into approving access.
- Phishing-resistant MFA changes the control model by replacing approval dependence with cryptographic proof that is harder to coerce or replay.
- Identity teams should treat authentication method selection as a risk decision, especially for privileged access, SaaS administration, and cloud consoles.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 addresses the attack and risk surface, while NIST SP 800-53 Rev 5, NIST Zero Trust (SP 800-207) and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-04 — Insecure Authentication | The article centers on weak authentication methods that attackers can coerce or bypass. |
| NHI-10 — Human Use of NHI | The control problem arises when humans are asked to operate an identity factor attackers can manipulate. | |
| Recommendation — Replace approval-based MFA with stronger authentication methods for access paths exposed to phishing and fatigue. Reduce human-dependent approval steps wherever user pressure can alter the authentication outcome. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle and strength are central to the article's MFA discussion. |
| Recommendation — Manage authenticators so higher-risk access uses methods that are harder to replay or coerce. | ||
| NIST Zero Trust (SP 800-207) | Identity governance — Identity governance | The article frames authentication as a Zero Trust control decision across cloud access paths. |
| Recommendation — Align authentication policy to access risk so verification remains strong across applications and devices. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | Authentication strength directly affects whether access decisions remain trustworthy. |
| Recommendation — Tie authorization-sensitive access to phishing-resistant authentication methods. | ||
Key terms
- Phishing-Resistant MFA: Phishing-resistant MFA uses authentication factors that cannot be easily replayed, intercepted, or socially engineered. In regulated environments, this usually means device-bound or cryptographic methods rather than push prompts or SMS codes, because the control must hold up under realistic attack conditions.
- MFA Fatigue: MFA fatigue is the behavioural pressure created when repeated login prompts make a person more likely to approve access without checking carefully. It is a control failure in the authentication experience, and it becomes dangerous when the approved session carries broad privilege or long-lived access.
- Identity Attack Surface: Identity attack surface is the total set of accounts, tokens, login endpoints, trust paths, and supporting systems that can be probed for access. For password spraying, the risk grows with every externally reachable authentication path and every dormant or weakly protected identity.
- Asymmetric Encryption: A cryptographic method that uses a public key to share or verify information and a private key to decrypt or sign. It reduces key duplication and is often better suited to identity proofing because the private key can remain tightly controlled.
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on June 8, 2026.
Updated on October 7, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org