TL;DR: AI-powered phishing in 2026 is shifting from password theft to real-time session hijacking, with AiTM proxying, MFA fatigue, fallback abuse, and consent phishing weakening controls that were tuned for automated attacks, according to WorkOS and cited incident data. MFA still matters, but authentication alone no longer closes the gap between login success and session compromise.
At a glance
What this is: This is an analysis of how AI-assisted phishing is bypassing MFA by stealing active sessions, abusing fallback methods, and exploiting the authorization layer.
Why it matters: It matters because IAM programmes that stop at MFA deployment miss the session, token, and OAuth governance controls that now determine whether access is actually secure.
By the numbers:
- 2024 involved MFA weaknesses.
- By mid-2025, Tycoon 2FA accounted for roughly 62% of the phishing volume Microsoft blocked.
- Research shows that 60% of recipients fall for AI-generated phishing emails.
👉 Read WorkOS's analysis of AI phishing, MFA bypass, and session theft
Context
AI phishing now targets the session rather than the password. That changes the identity problem from simple authentication hardening to post-login assurance, because a successful MFA challenge no longer guarantees that the session belongs to the intended user.
For IAM, PAM, and NHI teams, the practical gap is clear: MFA can still block commodity attacks, but it does not control session replay, OAuth consent abuse, or recovery-path downgrade. Programmes built around login events need to expand to token, device, and authorization governance.
Key questions
Q: How should security teams reduce MFA bypass risk in phishing attacks?
A: Teams should treat MFA as a baseline, not a finish line. Reduce bypass risk by using phishing-resistant methods for high-value users, removing weaker fallback options, binding sessions to devices, and monitoring for token replay after login. The goal is to protect the authenticated session, not just the authentication event.
Q: Why do fallback authentication methods create so much risk after passkey rollout?
A: Fallback methods create risk because attackers target the weakest available route, not the strongest one. If SMS, push, QR fallback, or weak recovery still exists, the attacker can steer the user into that path and defeat the stronger factor indirectly. A passkey deployment is only as resistant as its recovery and fallback design.
Q: What breaks when organisations ignore session security after MFA?
A: What breaks is the assumption that a successful login equals a secure session. AiTM attacks can capture the session cookie after MFA, allowing replay from another device or location. Without device binding, short token lifetimes, and anomaly detection, the attacker can keep using access that appears fully legitimate.
Q: Who is accountable when OAuth consent grants outlive authentication?
A: The accountable owners are the IAM, app governance, and security teams together, because OAuth consent is an authorization control, not a login control. If users can grant broad app access without review, the risk persists after password resets and MFA changes. Governance must cover who can consent, which scopes are allowed, and how tokens are revoked.
Technical breakdown
Adversary-in-the-middle proxying and session cookie capture
Adversary-in-the-middle, or AiTM, attacks place a proxy between the user and the legitimate login service. The user still sees the real site, completes the real MFA challenge, and receives a successful login, but the proxy captures the issued session cookie in transit. That cookie becomes the attacker’s credential, allowing replay without re-entering the second factor. This changes the control boundary: authentication is no longer the end of the problem, because the authenticated session itself becomes the target asset.
Practical implication: pair MFA with device binding, session anomaly detection, and short token lifetimes so stolen cookies are less reusable.
MFA downgrade paths and recovery-flow abuse
Phishing-resistant MFA only works when fallback paths are equally hardened. Many deployments still keep SMS, push approval, or password reset flows active, and attackers deliberately steer victims toward those weaker methods. QR-code fallback and recovery questions create a lower-assurance route that bypasses the strongest factor without breaking the login experience. The technical issue is not the presence of FIDO2 or passkeys, but the existence of an easier alternative inside the same identity journey.
Practical implication: remove or tightly gate legacy fallback methods once phishing-resistant methods are in place, especially for privileged and finance users.
Consent phishing and the authorization layer
Consent phishing targets OAuth, not authentication. The attacker convinces a user to approve a malicious application, which then receives access tokens that function independently of the original login. Password resets do not revoke those tokens, and MFA does not protect the consent screen itself. This makes the authorization layer a separate control plane that many IAM programmes still leave weakly governed, with long-lived delegated access surviving well after the user believes the threat is gone.
Practical implication: govern OAuth consent like privileged access, with app review, scoped permissions, and token revocation workflows.
Threat narrative
Attacker objective: The attacker’s objective is to obtain durable authenticated access to enterprise accounts without needing the victim’s password or second factor again.
- Entry begins with AI-generated lures, vishing, or AiTM phishing kits that capture a victim at the real login page without immediately raising suspicion.
- Credential access occurs when the proxy captures the session cookie, or when the victim approves a downgrade path, granting the attacker an authenticated token rather than a password.
- Impact follows when the attacker replays the session, accesses corporate email or SaaS apps, and, in consent phishing cases, preserves access through OAuth tokens that outlive the login event.
Breaches seen in the wild
- Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
- DeepSeek breach — DeepSeek breach exposed 1M+ log lines and sensitive secret keys.
Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.
NHI Mgmt Group analysis
MFA has been over-scoped as an authentication control when the real failure is session governance. The article shows that attackers are no longer trying to beat the login challenge alone. They are stealing the authenticated session, which means the operational boundary has moved from authentication to post-authentication assurance. Security programmes that still treat MFA success as equivalent to trust completion are managing the wrong control plane.
Fallback authentication is the hidden downgrade path that collapses phishing resistance. FIDO2 and passkeys reduce exposure only if SMS, push approvals, QR fallbacks, and weak recovery methods are removed or tightly constrained. The control gap is not the strong factor itself, but the weaker route left available beside it. Practitioners should treat every fallback as part of the attack surface, not as an administrative convenience.
Consent phishing exposes a separate governance failure: authentication controls do not govern delegated access. OAuth permissions can persist independently of the original sign-in, so password resets and MFA hardening do not address the actual exposure. The named concept here is authorization-layer blind spot: an identity programme can look healthy at login while third-party app consent continues to hold active access. Practitioners need to recognise that access approval and access authentication are not the same control.
AI compresses the attacker economics of phishing, which means the defender’s review cadence is now too slow. The article’s point is not that phishing is new, but that it is cheaper, more personalised, and more adaptive than the controls designed to stop it. That shifts the decision-making burden to continuous session validation, recovery-path reduction, and consent governance. Organisations should stop measuring MFA by deployment rate alone and measure whether post-login trust is actually being re-evaluated.
From our research:
- Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
- That same research found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, with 38% reporting no or low visibility and 47% reporting partial visibility.
- For a broader NHI governance lens, Ultimate Guide to NHIs , Key Challenges and Risks frames why visibility gaps and over-privilege keep recurring.
What this signals
Authorization-layer blind spot: IAM programmes that only measure MFA deployment are missing the control plane where delegated access actually persists. The practical signal is not whether login is enabled, but whether sessions, tokens, and consent grants are continuously governed after authentication.
With 85% of organisations lacking full visibility into OAuth-connected vendors in our research, the gap is already structural, and AI makes it easier to exploit because phishing no longer needs to look crude. Teams should expect session replay, fallback abuse, and consent abuse to converge in the same identity programme.
The next maturity step is not a louder awareness campaign. It is a governance model that treats authentication, session assurance, and authorization review as separate but linked controls, with The 52 NHI breaches Report providing the pattern library for where delegated access fails in practice.
For practitioners
- Harden the post-login trust boundary Add device binding, token lifetime limits, and anomaly checks for session replay so a successful MFA event does not become a standing pass to SaaS access.
- Remove weak fallback routes Disable SMS, push approval, and weak reset paths once phishing-resistant methods are rolled out, especially for admin, finance, and support accounts.
- Govern OAuth consent as privileged access Inventory user-granted applications, restrict high-risk consent, and require review for apps that hold broad scopes or long-lived refresh tokens.
- Retrain users on verification, not email hygiene Shift awareness content away from typo spotting and toward out-of-band verification for urgent requests, even when the message looks polished and legitimate.
Key takeaways
- AI-assisted phishing is now aimed at the authenticated session, which makes MFA alone insufficient as a trust boundary.
- The scale of the problem is measurable, with Cisco Talos, Microsoft, and other incident data showing MFA weaknesses and AiTM campaigns at industrial volume.
- Practical defence now depends on phishing-resistant authentication, removal of downgrade paths, and governance of sessions and OAuth consent.
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 address the attack and risk surface, while NIST CSF 2.0 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-01 | Session theft and token abuse map directly to NHI credential lifecycle risk. |
| NIST CSF 2.0 | PR.AA-01 | Identity verification and authentication assurance are central to this article. |
| NIST Zero Trust (SP 800-207) | PR.AC-7 | Zero Trust requires ongoing verification after initial authentication, which this article stresses. |
Continuously verify sessions, device posture, and anomalous access instead of trusting login success.
Key terms
- Adversary-in-the-middle attack: An adversary-in-the-middle attack places attacker-controlled infrastructure between a user and the real service so the login appears normal while credentials or session artifacts are intercepted. In identity security, the critical risk is not password theft alone, but capture of the authenticated session that follows a valid MFA challenge.
- Session cookie: A session cookie is a browser credential issued after authentication that tells a service the user is already logged in. For IAM teams, it is often more valuable to an attacker than the password because it can be replayed without repeating MFA, especially when device and location checks are weak.
- OAuth consent: OAuth consent is the authorization a user grants to an application to access data or act on their behalf. It is not the same as authentication. A consent grant can outlive the login event and remain active until explicitly revoked, which is why it must be governed as delegated access.
- Phishing-resistant authentication: Phishing-resistant authentication uses cryptographic methods, such as passkeys or FIDO2 security keys, that bind login proof to the legitimate domain. The control reduces proxy-based interception, but it only remains resistant when fallback and recovery methods do not reintroduce weaker authentication paths.
Deepen your knowledge
AI phishing, session hijacking, and OAuth consent abuse are covered in our NHI Foundation Level course, the industry's only accredited NHI security programme. If your team is still treating MFA as the end state, this is the right place to reset the model.
This post draws on content published by WorkOS: How attackers are bypassing MFA using AI in 2026. Read the original.
Published by the NHIMG editorial team on 2026-04-02.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org