TL;DR: Repeated breaches tied to MFA fatigue, phishing, and social engineering show that mobile push approval is still easy to bypass, while phishing-resistant MFA uses asymmetric cryptography to make approval requests far harder to steal or manipulate, according to Axiad. The real issue is not adding another login factor but replacing trust assumptions that depend on user response under pressure.
NHIMG editorial — based on content published by Axiad: Identity is the Key to SaaS Security, and You Need a Better Lock
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes.
Questions worth separating out
Q: How should security teams replace push-based MFA for high-risk access?
A: Security teams should move the highest-risk users and systems to phishing-resistant authentication such as WebAuthn or PKI-based methods.
Q: Why do push-based MFA controls fail in real environments?
A: Push-based MFA fails because attackers can exploit human fatigue, urgency, and confusion until one approval gets through.
Q: How do organisations know when MFA is too weak for the access being protected?
A: A control is too weak when a single social-engineering interaction can unlock email, collaboration, or administrative access.
Practitioner guidance
- Replace push approval for high-risk access Move administrators, finance users, and remote workforce entry points to phishing-resistant methods such as WebAuthn or PKI-based authentication where the application and the authenticator are bound cryptographically.
- Treat prompt fatigue as a control failure Measure repeated push denials, user-reported suspicious prompts, and help desk impersonation attempts as indicators that the authentication method is being actively targeted.
- Step up authentication by access context Require stronger authentication for SaaS administration, privilege elevation, and sensitive data access rather than using the same MFA pattern for every login.
What's in the full article
Axiad's full blog post covers the operational detail this post intentionally leaves for the source:
- The specific limitations of mobile push MFA across different user scenarios and device types
- A closer look at phishing-resistant MFA mechanics, including why asymmetric cryptography changes the attack surface
- The expanded platform context for continuous identity proofing and credential lifecycle management
- The FedRAMP ATO context that may matter for federal buyers evaluating deployment constraints
👉 Read Axiad's analysis of phishing-resistant MFA and identity security →
Phishing-resistant MFA and MFA fatigue: are your controls keeping up?
Explore further
Phishing-resistant MFA is now a governance baseline, not an advanced option: Mobile push and OTP-style approval controls still leave identity decisions exposed to pressure, impersonation, and repeated prompt abuse. The article shows why the attack surface is not just technical but behavioural, because the user becomes the security boundary. For IAM leaders, the practical conclusion is that approval-based MFA no longer satisfies the risk profile of critical SaaS and admin access.
A few things that frame the scale:
- Two-thirds of enterprises have endured a successful cyberattack resulting from compromised non-human identities, with a quarter encountering multiple attacks, according to The 2024 ESG Report: Managing Non-Human Identities.
- Enterprises that have experienced a compromised NHI averaged 2.7 separate incidents in the past 12 months.
A question worth separating out:
Q: Who should be accountable for phishing-resistant MFA decisions?
A: IAM, security architecture, and application owners should share accountability, with risk and compliance defining where passwordless or phishing-resistant methods are mandatory. The decision belongs in policy because authentication strength is part of access governance, not just a technical setting on a login page.
👉 Read our full editorial: Phishing-resistant MFA is the control gap identity teams still miss