Multifactor authentication was, for years, the single most effective control an organization could deploy — and it remains essential. But "turn on MFA" is no longer a finish line. Attackers have industrialized techniques that sail straight past traditional MFA: adversary-in-the-middle phishing kits that steal the session token after a legitimate MFA prompt, prompt-bombing that wears users down until they approve, SIM swaps that hijack text-message codes, and stolen cookies that replay an authenticated session. The uncomfortable truth is that a password plus a one-time code or a push approval is now a phishable credential.
This guide explains why MFA alone is no longer enough, how these bypass techniques work, and what to do about it: move to phishing-resistant MFA and wrap it in a layered identity defense — device compliance, token protection, continuous evaluation, and risk-based policies. Because Microsoft updates these capabilities and their licensing regularly, treat the specifics here as a well-grounded starting point and confirm current behavior against Microsoft documentation before you act.
Who should read this
- CIOs and CISOs responsible for identity security
- IT directors and identity / security administrators
- Security teams hardening against phishing and account takeover
- Compliance leaders aligning to phishing-resistant MFA mandates
Key points for executives
A realistic view of MFA today rests on four points:
- Traditional MFA (SMS, voice, and push approvals) is now routinely bypassed by phishing-as-a-service kits.
- The goal has shifted from "have MFA" to "have phishing-resistant MFA," starting with administrators.
- Strong authentication must be paired with device, token, and session controls — MFA is one layer, not the whole defense.
- Risk-based policies and monitoring catch what prevention misses, and contain compromise quickly.
Strong authentication is the foundation of a Zero Trust identity strategy. For how it fits the wider model, see How to Implement Zero Trust Identity Using Microsoft Entra ID.
Executive takeaways
- MFA is still essential — but traditional MFA is now phishable at scale.
- Adversary-in-the-middle attacks steal the session token after a valid MFA prompt.
- Only phishing-resistant methods — FIDO2, Windows Hello for Business, certificates — defeat these attacks.
- Layer device compliance, token protection, and risk policies around strong authentication.
- Prioritize administrators and sensitive users for phishing-resistant MFA first.
Business outcomes
Organizations that move to phishing-resistant, layered identity security typically achieve:
How do attackers get past MFA?
MFA bypass is no longer the domain of nation-states; it is packaged into off-the-shelf phishing kits. Several techniques dominate.
Table 1. MFA bypass techniques.
| Technique | How it works | What it defeats |
|---|---|---|
| Adversary-in-the-middle (AiTM) | A proxy site relays the login and steals the post-MFA session token | SMS, app, and push MFA |
| MFA fatigue / prompt bombing | Repeated push prompts until the user approves one | Push-approval MFA |
| SIM swap / SMS interception | Attacker takes over the phone number to receive codes | SMS and voice MFA |
| Session cookie theft | Malware exfiltrates an authenticated session cookie | Any MFA (post-authentication) |
| Help-desk social engineering | Impersonation to reset MFA or credentials | Any MFA (process weakness) |
| Consent phishing (OAuth) | User grants a malicious app standing access | Any MFA (no password needed) |
What does an adversary-in-the-middle attack look like?
The most important technique to understand is adversary-in-the-middle (AiTM), because it defeats the MFA methods most organizations rely on. The attacker does not break the MFA — they let it succeed, then steal the result.
Warning. Because AiTM steals the token issued after a successful MFA prompt, it works even when MFA is enforced. Text-message codes, authenticator codes, and push approvals are all vulnerable, because none of them bind the authentication to the legitimate site. "We have MFA" is no longer a sufficient answer to phishing risk.
Which MFA methods actually resist phishing?
The defense is phishing-resistant MFA — methods that cryptographically bind the authentication to the real sign-in surface, so a proxy cannot relay them. Microsoft's built-in Phishing-resistant MFA authentication strength allows FIDO2 security keys, Windows Hello for Business, and certificate-based authentication (multifactor). These require an interaction between the authenticator and the sign-in surface that an adversary-in-the-middle cannot reproduce.
You enforce these through a Conditional Access policy using the Require authentication strength grant control (which requires Microsoft Entra ID P1), scoping the phishing-resistant strength to administrators and sensitive resources first, then broadening over time. For the enforcement pattern, see Conditional Access Best Practices for SMBs.
Best practice. Start phishing-resistant MFA where it matters most: every administrative account, then high-risk and executive users, then the general population. Use Conditional Access authentication strengths so the requirement is enforced per scenario — phishing-resistant MFA for admin portals and sensitive apps, and standard MFA everywhere else at minimum.
Authentication maturity model
| Level | Maturity | Characteristics |
|---|---|---|
| 1 | Password only | No second factor — phished and sprayed routinely |
| 2 | Traditional MFA | SMS, voice, app, or push — susceptible to AiTM and fatigue |
| 3 | MFA + Conditional Access | Baseline policies enforce MFA and block legacy authentication |
| 4 | Phishing-resistant MFA | FIDO2, Windows Hello, or certificate — enforced via authentication strengths |
| 5 | Layered Zero Trust identity | Phishing-resistant MFA + device compliance + token protection + CAE + risk-based policies |
What does defense beyond MFA look like?
Phishing-resistant authentication is the strongest single improvement, but Zero Trust assumes that any control can fail. The durable answer is layered: wrap strong authentication in device, token, session, and risk controls so a stolen credential or token is still stopped.
Table 2. Controls that complement MFA.
| Control | What it adds | Typical licensing |
|---|---|---|
| Phishing-resistant MFA | Authentication a proxy cannot relay | Microsoft Entra ID P1 (Conditional Access) |
| Device compliance | Grants access only from healthy, managed devices | Microsoft Intune |
| Token protection | Binds sign-in session tokens to the device | Microsoft Entra ID P1/P2 |
| Continuous Access Evaluation | Revokes access in near real time on risk events | Included with Entra ID |
| Risk-based policies | Steps up or blocks on sign-in / user risk | Microsoft Entra ID P2 |
| Monitoring & response | Detects and contains token abuse | Microsoft Defender XDR |
How do you move beyond MFA?
Improving identity security is a sequence, not a switch. This roadmap moves an organization from basic MFA to phishing-resistant, layered defense without disrupting users.
Table 3. Hardening roadmap.
| Phase | Focus |
|---|---|
| 1 · Assess | Measure MFA coverage, methods in use, and gaps |
| 2 · MFA everywhere | Enforce MFA for all users; block legacy authentication |
| 3 · Phishing-resistant | Roll out FIDO2 / Windows Hello / certificates, admins first |
| 4 · Device + token | Require compliant devices; add token protection |
| 5 · Continuous | Enable risk-based policies and monitoring |
Typical migration timeline
| Organization size | Typical duration |
|---|---|
| 50–300 users | 4–8 weeks |
| 300–1,000 users | 8–14 weeks |
| Enterprise (1,000+ users) | 3–6 months, phased by business unit |
Note: Timelines vary depending on application compatibility, device readiness, and organizational maturity.
Best practices
- Keep MFA on for everyone — it still blocks the vast majority of untargeted attacks.
- Move administrators to phishing-resistant MFA first, then sensitive and executive users.
- Use Conditional Access authentication strengths to enforce the right method per scenario.
- Block legacy authentication so nothing bypasses MFA entirely.
- Require compliant or managed devices as a Conditional Access grant control.
- Enable Continuous Access Evaluation and token protection to limit token replay.
- Turn on risk-based policies with Entra ID Protection where licensed.
- Harden the help desk against social-engineering MFA resets.
- Monitor for anomalous sign-ins and token anomalies with Microsoft Defender XDR.
Common mistakes
- Treating "MFA is on" as done. Traditional MFA is now routinely phished.
- Relying on SMS or voice codes. These are the weakest methods and are SIM-swappable.
- Leaving legacy authentication enabled. It bypasses MFA completely.
- Applying phishing-resistant MFA to no one. Admins are the highest-value target and should go first.
- Ignoring token theft. Prevention alone misses stolen-cookie replay; add token and session controls.
- Weak help-desk verification. Attackers reset MFA by impersonating users.
- No monitoring. Without detection, a bypassed MFA goes unnoticed.
Implementation checklist
Before considering identity authentication hardened, confirm that:
- MFA is enforced for all users and legacy authentication is blocked
- Administrators use phishing-resistant MFA (FIDO2 / Windows Hello / certificate)
- A Conditional Access authentication-strength policy is in place for sensitive access
- Compliant or managed devices are required for key resources
- Continuous Access Evaluation and token protection are enabled
- Risk-based Conditional Access is enabled where Entra ID P2 is licensed
- Help-desk identity-verification procedures resist social engineering
- Sign-in and token anomalies are monitored in Microsoft Defender XDR
- A rollout plan exists to extend phishing-resistant MFA to all users
Frequently asked questions
Is MFA still worth having?
Yes. MFA still blocks the overwhelming majority of untargeted, password-only attacks. Traditional MFA is no longer sufficient against targeted phishing — it must be strengthened and layered, not abandoned.
What is an adversary-in-the-middle attack?
AiTM uses a proxy site between the user and the real sign-in. The user completes MFA legitimately, and the attacker captures and replays the resulting session token — bypassing MFA without breaking it.
Which MFA methods are phishing-resistant?
Per Microsoft, the phishing-resistant methods are FIDO2 security keys, Windows Hello for Business, and certificate-based authentication (multifactor). They bind the authentication to the real sign-in surface so a proxy cannot relay them.
Why aren't authenticator apps phishing-resistant?
Push approvals and one-time codes can be relayed by an adversary-in-the-middle proxy, and pushes are also vulnerable to fatigue attacks. Number matching helps against fatigue but does not make the method phishing-resistant.
How do I enforce phishing-resistant MFA?
Use a Conditional Access policy with the Require authentication strength grant control set to the built-in Phishing-resistant MFA strength, scoped to administrators and sensitive resources first. This requires Microsoft Entra ID P1.
What else should I do beyond changing MFA methods?
Require compliant devices, enable token protection and Continuous Access Evaluation to limit token replay, turn on risk-based policies, harden the help desk, and monitor for anomalies with Microsoft Defender XDR.
Where should we start?
Confirm MFA is on everywhere and legacy authentication is blocked, then roll out phishing-resistant MFA to administrators, then extend it and add the surrounding layers.
Key takeaways
- MFA is essential but traditional MFA is now phishable through AiTM, fatigue, and token theft.
- Move to phishing-resistant MFA — FIDO2, Windows Hello for Business, or certificates — starting with admins.
- Enforce it with Conditional Access authentication strengths.
- Layer device compliance, token protection, and risk-based policies around strong authentication.
- Monitor for token abuse and contain compromise quickly.
Recommended next steps
Organizations can begin with the Data & AI Readiness Checklist, review the Microsoft 365 Governance Knowledge Center, or schedule a technology assessment.
Build a Phishing-Resistant Identity Foundation
Partner with Insyto
Design and deploy phishing-resistant, layered identity security
Insyto helps CIOs and CISOs move beyond traditional MFA — deploying phishing-resistant authentication with Microsoft Entra ID, hardening Conditional Access, adding device compliance, token protection, and Continuous Access Evaluation, and wiring risk-based policies and monitoring into Microsoft Defender XDR. The result is a resilient identity foundation that is hard to phish and quick to contain.
Authoritative references
Verified against publicly available Microsoft Learn documentation. Source access date: 25 July 2026. Microsoft product capabilities, licensing, and feature availability may vary by subscription, tenant configuration, region, and Microsoft product updates. Verify current Microsoft documentation before making deployment decisions.
- Microsoft Learn: Conditional Access authentication strengths
- Microsoft Learn: Phishing-resistant passwordless authentication deployment
- Microsoft Learn: What is Conditional Access?
- Microsoft Learn: Conditional Access token protection
- Microsoft Learn: Continuous access evaluation
- Microsoft Learn: What is Microsoft Entra ID Protection?
- Microsoft Learn: Block legacy authentication with Conditional Access
- Microsoft Learn: Require a compliant or hybrid-joined device
- Microsoft Learn: Defend against MFA fatigue with number matching
- Microsoft Learn: FIDO2 security key authentication
Author and reviewers
Insyto is a technology consulting firm specializing in Microsoft, cybersecurity, data modernization and responsible AI adoption.
Microsoft 365 Practice Lead
Editorial Reviewer