TL;DR: MFA can still be bypassed through phishable factors, push fatigue, weak recovery flows, and session hijacking, according to WorkOS. The real control gap is not whether MFA exists, but whether it resists real-time phishing, abuse of fallback paths, and post-login misuse.
At a glance
What this is: This article explains why MFA is still bypassed in practice when teams depend on SMS, push prompts, weak recovery, and incomplete coverage.
Why it matters: It matters because identity teams need MFA that withstands phishing and account recovery abuse, not just MFA that satisfies a policy checkbox.
Context
MFA is intended to add a second verification step, but that protection collapses when the second factor can be phished, socially engineered, or reset through weaker fallback processes. In identity programmes, the real question is not whether MFA exists, but whether it is resistant to the ways attackers actually bypass it.
The article focuses on human identity controls, especially authentication, recovery, and session misuse after login. That makes it directly relevant to IAM teams because the same gap between policy and practice often appears across SSO, privileged access, and downstream access reviews.
Key questions
Q: What breaks when MFA still allows phishing and push fatigue?
A: The control breaks when users can be tricked into approving a session they did not truly initiate, or when a phishable factor can be relayed through a fake login flow. In that case, MFA still exists but no longer proves meaningful user intent, and attackers can turn one login into an authenticated session they can reuse.
Q: Why do weak MFA recovery flows create more risk than the login step itself?
A: Recovery becomes dangerous when support resets, email links, or security questions are easier to compromise than the primary factor. At that point, the fallback path is effectively a bypass channel, so attackers target recovery instead of the front door. A strong MFA programme must govern reset authority with the same discipline as authentication.
Q: How can security teams tell whether adaptive MFA is working properly?
A: Look for a lower challenge rate on routine sessions, a higher challenge rate on suspicious transactions, and stable or improved conversion. If adaptive MFA is triggering everywhere, it is behaving like blunt MFA. If it rarely triggers on risky actions, the policy is too weak to matter.
Q: What should organisations do after an MFA-protected session is hijacked?
A: Contain the session, revoke tokens, review the surrounding login and recovery events, and check for privilege misuse after authentication. The goal is to stop the attacker from extending the session into lateral movement or privileged action. MFA is only the entry control, so post-login monitoring and audit trails become essential.
Technical breakdown
Why phishable MFA factors fail under real-time phishing
SMS codes, TOTP prompts, and email-based verification all prove possession in ways that can be relayed through a fake login flow. In a real-time man-in-the-middle attack, the user completes the challenge against the attacker-controlled session, which then captures tokens or cookies and replays them against the real service. The cryptographic weakness is not the code itself, but the lack of binding to the originating browser and domain. WebAuthn and hardware-backed authenticators change that because the challenge is origin-bound and cannot be reused by a phishing proxy.
Practical implication: prioritise phishing-resistant authentication for high-value users and systems instead of assuming any second factor is enough.
How push fatigue and weak recovery flows expand the attack surface
Push MFA can become a liability when users are flooded with prompts and approve one just to stop the noise. Attackers often pair prompt bombing with stolen credentials, which makes the second factor a friction point rather than a defence. Recovery flows create a second exposure window when support resets, email links, or security questions become easier to abuse than primary MFA. If fallback paths are weaker than the first login path, the control has simply moved the weakness somewhere else in the journey.
Practical implication: treat recovery and reset paths as privileged workflows that need the same scrutiny as primary authentication.
Why partial MFA coverage leaves privileged access exposed
MFA only changes risk when it is enforced everywhere it matters. Gaps across VPNs, admin consoles, CI pipelines, legacy systems, or shared accounts let attackers move through the weakest uncovered path and still reach high-value access. Shared credentials also destroy auditability, because the MFA event no longer maps cleanly to a person or role. In identity terms, the control is not just authentication strength, but consistent policy enforcement across the full access chain.
Practical implication: inventory every privileged entry point and close the MFA exceptions before attackers find them.
Threat narrative
Attacker objective: The attacker wants to turn one successful login into durable authenticated access that can be reused without further MFA challenges.
- Entry begins when an attacker obtains credentials and drives the user into a fake login flow that relays the authentication exchange in real time.
- Credential access occurs when the phished MFA code, push approval, or session cookie is captured and replayed against the legitimate service.
- Escalation follows when the attacker reuses the authenticated session to bypass future MFA checks and reach sensitive applications or admin functions.
- Impact is achieved through session hijacking, token reuse, or misuse of approved access to move laterally and perform privileged actions without another challenge.
Breaches seen in the wild
- Microsoft Midnight Blizzard breach: Midnight Blizzard (APT29) exploited legacy test account without MFA to breach Microsoft.
- Uber breach 2022: A contractor's stolen password and MFA fatigue gave a Lapsus$-linked attacker Uber's internal tools; Uber rotated keys to many services.
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
Phishing-resistant authentication is now the dividing line, not MFA presence. The article shows that phishable factors can still be relayed through a real-time proxy, which means possession-based MFA does not reliably prove user intent. That is why the relevant governance question is whether the second factor is origin-bound, not whether a box labelled MFA is checked. Practitioners should treat WebAuthn-class protection as the control boundary for high-value access.
Recovery flows are a separate trust system, and they often fail more quietly than login itself. Support resets, backup codes, alternate devices, and email-based fallback all create an implicit exception path around the primary control. If those paths are easier to abuse than the main factor, the identity programme has simply relocated risk into off-path recovery. The practitioner implication is that authentication governance must include reset authority and not stop at sign-in.
Inconsistent MFA enforcement creates privilege asymmetry across the estate. The article correctly points out that coverage gaps on VPNs, admin tools, legacy systems, or developer workflows let attackers pick the weakest route, even when most apps are protected. That pattern shows why identity governance has to be measured by exception coverage, not deployment count. Teams should assume attackers will route through the least governed access point available.
MFA controls do not end at verification because authenticated misuse is where the real loss starts. Once a session is stolen or approved, the attacker is operating inside a trusted identity context, which means downstream controls must detect abnormal behaviour rather than rely on another prompt. That shifts the governance burden toward session intelligence, conditional decisions, and auditability. Practitioners need to manage post-authentication risk as a first-class identity problem.
Phishing-resistant auth and recovery governance belong in the same lifecycle model. The article makes clear that a strong front door is undermined if the side entrance is ungoverned, which is a classic lifecycle failure rather than a single product gap. Identity programmes should evaluate authentication, fallback, reset, and session control as one chain of trust. The practical conclusion is that MFA maturity is defined by weakest-link governance across the full user journey.
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
Phishing-resistant authentication should now be treated as a governance requirement for privileged access. MFA that can be relayed, fatigued, or reset through weaker channels does not close the identity risk that attackers actually exploit. Programmes that still rely on phishable factors should expect session theft, not just login compromise, and should reframe assurance around origin-bound authentication.
Recovery is part of the authentication control plane, not an afterthought. When account resets or fallback methods are easier to abuse than the primary factor, attackers will simply shift tactics. Identity teams should align reset approval, recovery evidence, and audit logging to the same standard as sign-in enforcement.
For practitioners
- Deploy phishing-resistant authentication for high-value access Use WebAuthn or hardware-backed authenticators for admins, superusers, and other sensitive roles where real-time phishing and prompt abuse would have the highest impact.
- Harden MFA recovery and reset workflows Require manual review, trusted-device verification, or tightly controlled backup codes so recovery cannot be easier to abuse than primary login.
- Eliminate MFA coverage gaps across critical systems Map where MFA is missing across VPNs, admin panels, legacy systems, CI pipelines, and shared accounts, then close those exceptions before they become the easiest path in.
- Add post-login detection to authentication programmes Monitor session reuse, impossible travel, unfamiliar devices, and suspicious privilege use so a successful MFA challenge does not become a blind spot.
Key takeaways
- MFA is still bypassed in practice when the second factor can be phished, spammed, or reset through weaker fallback paths.
- The article shows that login protection is only as strong as recovery governance and coverage consistency across privileged systems.
- Identity teams should treat phishing-resistant auth, reset controls, and post-login monitoring as one control chain, not separate projects.
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 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 is about phishable MFA factors and authentication bypass paths for non-human and human identities. |
| NHI-10 — Human Use of NHI | Shared MFA devices and weak recovery flows blur human and credential handling boundaries. | |
| Recommendation — Replace phishable second factors with origin-bound authentication for sensitive access paths. Separate user authentication from shared credential handling and remove shared MFA practices. | ||
| NIST SP 800-53 Rev 5 | IA-5 — Authenticator Management | MFA recovery, factor resets, and authenticator lifecycle are central to the article's control gaps. |
| Recommendation — Apply authenticator management rules to reset, rotate, and revoke MFA factors and recovery credentials. | ||
| NIST CSF 2.0 | PR.AA-05 — Access Permissions, Entitlements and Authorizations | The article highlights inconsistent MFA enforcement across critical access points and privileged workflows. |
| Recommendation — Enforce consistent access permission checks across every privileged entry point and exception path. | ||
| MITRE ATT&CK | TA0006;TA0008 — Credential Access; Lateral Movement | The described attack pattern uses phished credentials, session theft, and downstream privileged movement. |
| Recommendation — Map MFA bypass scenarios to credential access and lateral movement detections in your telemetry. | ||
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.
- Push fatigue: A condition where repeated mobile approval prompts train users to approve authentication requests without careful review. Attackers exploit the fatigue to turn a human decision into an accidental bypass, especially after they already know the password.
- Recovery Flow: The set of processes used to regain access to an account after loss of a credential or device. Recovery flows are often the weakest link in authentication because they can reintroduce shared secrets or weaker proofing, so they need the same governance discipline as primary login.
- Session Hijacking: Session hijacking is the takeover of an authenticated session after the original login has completed. The attacker does not need to know the password if they can use the active session token, which is why session monitoring and revocation are essential controls in SaaS identity governance.
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 June 8, 2026.
Updated on October 10, 2026.
NHI Mgmt Group, the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org