TL;DR: Legacy MFA models built for 2015-era threats are increasingly vulnerable to MFA fatigue, reverse-proxy phishing, token theft, SIM swaps, OTP interception, and AI-driven social engineering, according to eMudhra. The security problem is no longer authentication alone, but whether trust is cryptographically anchored enough to survive modern deception and session abuse.
At a glance
What this is: This is an opinion-led security analysis arguing that weak MFA patterns are no longer sufficient against 2026 attack techniques that exploit approval fatigue, session theft and AI-enabled deception.
Why it matters: It matters because IAM teams must treat MFA as a cryptographic trust control, not a user-consent step, or the same authentication layer will keep failing against modern phishing and session abuse.
Context
Weak MFA is increasingly a governance problem, not just an authentication problem. The article argues that controls designed around password plus OTP assumptions cannot withstand modern phishing kits, push fatigue, SIM swaps and session theft.
For IAM, PAM and workforce identity teams, the key question is whether the authentication method is phishing-resistant and device-bound enough to survive adversarial manipulation. The article also broadens the issue beyond human logins to machine identity and session trust.
The article's core claim is that many enterprises still measure MFA by whether a second factor exists, while attackers now target the approval channel, the token, the session cookie and the user decision itself.
Key questions
Q: What breaks when organisations keep approval-based MFA for 2026 threats?
A: Approval-based MFA breaks when attackers can manipulate the user, intercept the code or replay the session after the factor has been accepted. The problem is not only bypass, but the false sense of assurance created by prompts that are easy to fatigue, spoof or relay. That makes the factor operationally weak even when it is technically present.
Q: Why do push prompts and OTPs create so much identity risk?
A: They create risk because they depend on a user action that attackers can influence through fatigue, phishing or real-time relay. Once the factor can be approved, intercepted or replayed, it no longer provides durable proof of identity. Security teams should treat these methods as transition controls, not the end state for sensitive access.
Q: How should security teams decide where to deploy phishing-resistant MFA first?
A: Start with the accounts and workflows that create the greatest blast radius if compromised, including privileged access, sensitive data access, and business-critical approvals. That sequencing gives the most risk reduction for the least disruption. The goal is to protect the paths an attacker is most likely to target, not just increase MFA coverage everywhere.
Q: How should identity programmes cover machine accounts and workloads?
A: Identity programmes should govern machine accounts with the same seriousness as human access, but through device, certificate and secret lifecycle controls rather than prompts and approvals. Service accounts, APIs and workloads need inventory, ownership, authentication scope and revocation paths because weak machine identity often becomes the route around strong human MFA.
Technical breakdown
Why push-based MFA fails under modern phishing and fatigue
Push approval and one-time code MFA fail because the attacker does not need to break the cryptography if they can shape the user's response. Reverse-proxy phishing kits relay credentials and session material in real time, while MFA fatigue attacks turn approval into a nuisance signal instead of a trust signal. OTP interception and SIM swap attacks exploit the fact that the second factor is often still a shared or interceptable secret. In practice, the authentication boundary is too dependent on human judgement and too weakly bound to the device or session.
Practical implication: treat push approval and SMS OTP as legacy controls and move privileged or external access paths to phishing-resistant authentication.
What cryptographic MFA changes for identity trust
Cryptographic MFA changes the trust model by binding authentication to a private key, device hardware, or certificate instead of to a code the user can repeat or approve. FIDO2 security keys, certificate-based authentication and device-bound passkeys reduce replay risk because the secret never leaves the trusted hardware or secure enclave. This is not just stronger authentication, it is a different assurance model: possession is proven by cryptographic challenge, not by a user confirming intent under pressure. That distinction is what makes the method resistant to social engineering.
Practical implication: prioritise cryptographic binding for administrators, high-risk users and sensitive workflows where approval-based MFA is easiest to manipulate.
Why MFA must extend beyond human logins to machine identity
The article's machine-identity point is operationally important because service accounts, APIs, bots and workloads authenticate at machine speed and scale. A control that only protects human interactive logins covers only part of the real attack surface. If machine identities rely on the same weak patterns, attackers can pivot from human compromise into persistent access through API tokens, service accounts or workload sessions. In this model, MFA is really a broader trust enforcement layer that has to cover both interactive users and non-human actors where authentication and authorisation overlap.
Practical implication: include service accounts, workload identities and API access in your authentication review, not just employee logins.
Threat narrative
Attacker objective: The attacker aims to bypass authentication assurance and obtain durable access through a session or token that the organisation still treats as trusted.
- Entry begins when attackers use reverse-proxy phishing, MFA fatigue or AI-driven social engineering to capture credentials, approval signals or session material.
- Credential access follows through OTP interception, SIM swaps or session cookie theft, which turns the second factor into reusable access rather than proof of presence.
- Impact occurs when the stolen session or replayed trust grants continued access to applications and sensitive actions despite the appearance of MFA protection.
Breaches seen in the wild
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
- Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.
Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
Weak MFA is now a trust-design failure, not a factor-counting problem. The article is right to separate modern compromise paths from legacy second-factor thinking. Push approvals, SMS codes and user-visible prompts are no longer reliable evidence of identity assurance when attackers can spoof, intercept or fatigue the response. The practitioner conclusion is that MFA design must be judged by resistance to interception and manipulation, not by the mere presence of a second factor.
Phishing-resistant authentication is becoming the baseline, not the premium tier. Cryptographic binding through FIDO2 keys, certificates and device-bound passkeys is the only part of the MFA stack that materially reduces replay and approval abuse. That does not remove the need for IAM governance, but it changes the control plane from user judgement to device-backed proof. The practical consequence is that enterprises should stop treating resilient MFA as an edge case for privileged users only.
Machine identity exposes the real limit of human-centric MFA programmes. Service accounts, APIs and workloads authenticate at a pace that makes human approval patterns irrelevant. Once the organisation accepts that non-human actors also need strong identity assurance, MFA becomes part of a wider machine identity governance model rather than a login-only control. The practitioner takeaway is that identity security programmes must align human and non-human trust models, or attackers will simply move to the weaker one.
Zero Trust turns MFA into a continuous assertion, not a one-time event. The article correctly notes that authentication is increasingly about the full session, not the first screen. Continuous validation, context checks and privileged action step-up are now the meaningful assurance points because session theft can outlive initial login confidence. Teams should therefore assess whether their trust model survives beyond the prompt, the push notification and the first successful sign-in.
Cryptographic trust debt: Legacy MFA accumulates risk when organisations keep approval-based factors in place after attackers have learned to exploit the approval channel itself. That debt shows up as a gap between compliance language and actual resilience. The implication is that security leaders need to reclassify MFA as a cryptographic and lifecycle governance problem, not just an authentication UX choice.
From our research library:
- Across one million observed logins, 1 in 4 were password-based rather than SSO, 2 in 5 were not protected by MFA and 1 in 5 used a weak, breached or reused password.
What this signals
Cryptographic trust debt: organisations that keep approval-based MFA in place after attackers have shifted to relay, fatigue and session theft are carrying avoidable trust debt. The practical signal is that authentication policy must be reviewed as a runtime control, not a one-time deployment decision.
Passwordless and device-bound methods change the failure mode from user choice to cryptographic proof, which is why authentication programmes should be measured by replay resistance rather than by how many factors they can present.
Machine identity is part of the same trust problem: once service accounts and workloads inherit weak authentication assumptions, the weakest path in the session becomes the one attackers will exploit.
For practitioners
- Replace approval-based MFA on critical access paths Move administrator, finance and privileged application access away from push prompts and SMS codes toward phishing-resistant methods such as FIDO2 security keys, certificate-based authentication or device-bound passkeys.
- Extend authentication governance to machine identities Review service accounts, workload identities and API access paths for weak or reusable credentials, especially where the same trust model is still applied to humans and non-human actors.
- Add session-level verification to Zero Trust policies Require contextual checks on high-risk actions, not just at login, so stolen cookies, replayed tokens and fatigued approvals do not remain trusted for the rest of the session.
- Audit MFA bypass conditions and recovery paths Test help-desk recovery, push fatigue tolerance, token replay exposure and SIM-swap reliance so the strongest factor is not undermined by the weakest fallback path.
Key takeaways
- Weak MFA is failing because attackers now target the approval path, session material and user judgement rather than the password alone.
- Cryptographic authentication methods such as FIDO2 keys and device-bound passkeys reduce replay and fatigue risk by binding trust to hardware.
- Identity programmes need to cover human and machine access together, because a strong login control does not protect a weak workload identity path.
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 and MITRE ATT&CK address the attack and risk surface, while NIST SP 800-53 Rev 5 and NIST Zero Trust (SP 800-207) 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 centres on weak MFA and authentication methods that can be phished or replayed. |
| NHI-05 — Overprivileged NHI | Machine identity is part of the article's scope because weak access paths extend to service accounts and workloads. | |
| NHI-10 — Human Use of NHI | The article warns that human judgement and approval are being used where cryptographic assurance should dominate. | |
| Recommendation — Replace replayable MFA with phishing-resistant authentication for high-risk access paths. Review machine accounts for excess access that weak authentication could expose. Remove human approval from identity decisions that should be cryptographically enforced. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | Authenticator lifecycle and strength are central to the article's critique of weak MFA. |
| IA-9 — Service Identification and Authentication | The article explicitly extends the discussion to service accounts, APIs and workloads. | |
| Recommendation — Use authenticator management to phase out reusable and interceptable factors. Apply service authentication controls to workloads and APIs, not only to users. | ||
| NIST Zero Trust (SP 800-207) | Section 2.3 — Continuous Verification | The article argues that authentication must persist beyond login into the active session. |
| Recommendation — Enforce continuous verification for high-risk actions after initial authentication. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The threats discussed map to credential theft, token replay and movement after session compromise. |
| Recommendation — Map phishing, token theft and replay paths to credential access and lateral movement detections. | ||
Key terms
- Phishing-Resistant Authentication: Phishing-resistant authentication proves identity without relying on a user to approve a prompt or reveal a reusable secret. It typically binds access to a device, key, or cryptographic proof that an attacker cannot easily reuse or coerce. This approach reduces reliance on human judgment at login time.
- Cryptographic binding: Cryptographic binding links the authenticator to a specific website, application, or verifier so the credential cannot be replayed against a different target. This is the technical property that makes phishing-resistant authentication work. Without it, an MFA flow may still be vulnerable to impersonation even if it uses multiple factors.
- Session Theft: Session theft is the reuse of an already authenticated access context, usually through stolen cookies, tokens, or browser artifacts. It is dangerous because the attacker may not need to know the password at all. For IAM and NHI governance, it means authentication success cannot be treated as proof of legitimate intent.
- Machine Identity: The digital identity of a machine, device, or workload, such as a server, container, or VM, used to authenticate it within a network. Sometimes used interchangeably with NHI, though NHI is the broader category.
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 building or maturing an IAM programme, it is worth exploring.
Published by the NHIMG editorial team on July 11, 2026.
Updated on October 11, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org