Why Microsoft 365 Needs Phishing-Resistant Authentication
Nov 11, 2026 Nathan Taylor Cloud Security | Security & Compliance | Microsoft 365 | Cybersecurity | Data Protection | Sourcepass MCOE 4 min read
Right now an attacker could be reading a user's mailbox inside your Microsoft 365 tenant, and every sign in log would tell you MFA was satisfied.
That scenario is becoming far more common. For years, MFA was treated as the primary line of defense for Microsoft 365 identities. Today, attackers use token theft, Device Code Flow, session hijacking, and adversary-in-the-middle attacks to get around protections that many organizations still consider airtight. MFA is still one of the most important security controls you can deploy. The problem is that modern attackers have shifted their focus to the authenticated session that comes after login, not the password in front of it.
That shift is driving the industry toward phishing-resistant authentication, and it starts with understanding where traditional MFA falls short.
Why do Accounts Get Compromised Even with MFA Enabled?
Not every MFA method offers the same level of protection, and the gap between them is wider than most teams assume.
Consider SMS and email-based verification. Text messages can be intercepted through SIM swapping, and email codes are often only as secure as an employee's personal inbox. Push notifications carry their own risk through MFA fatigue attacks, where a user is prompted repeatedly until they approve a request out of frustration or confusion.
Moving users to a method like Microsoft Authenticator with number matching solves many of these older social engineering problems. It does not, however, solve the attack that older MFA methods were never built to stop.
Here is how common MFA methods compare:
|
MFA Method |
Protection Level |
Primary Weakness |
|---|---|---|
|
SMS or email codes |
Weak |
SIM swapping, telecom compromise, personal inbox exposure |
|
One-time passcodes (TOTP) |
Moderate |
Can be phished or relayed through a proxy |
|
Authenticator with number matching |
Strong |
Resists social engineering, but not token theft |
|
Passkeys (FIDO2) and Windows Hello for Business |
Phishing-resistant |
No shared secret to steal or replay |
Each method is stronger than the one before it, but only phishing-resistant options like FIDO 2.0 Passkeys and Windows Hello for Business remove the shared secret an attacker can steal or replay.
What is an AiTM Attack and How does it Bypass MFA?
The clearest example of this gap is the adversary-in-the-middle, or AiTM, attack.
In a traditional phishing attack, the goal is to steal a username and password. In an AiTM attack, the attacker places a convincing proxy between the user and the real Microsoft login page. The user believes they are signing into Microsoft 365, enters their password, and approves the MFA prompt. Company branding loads exactly as expected, and in many cases the user is even shown their real inbox through the attacker's server. Everything appears normal.
Behind the scenes, the attacker captures the session token that Microsoft issues after a successful login and uses it to access Microsoft 365 resources without needing the password or the MFA code again. Microsoft has documented AiTM campaigns that led to business email compromise and account takeover even though MFA was enabled.
In many of these attacks, the attacker is not bypassing MFA at all.
MFA works exactly as intended. The user authenticates, Microsoft issues a valid token, and the attacker steals that authenticated session. Because that stolen token represents an already completed login, the attacker inherits the session with the password unknown, and MFA already satisfied.
This is also what makes these attacks so difficult to investigate. A traditional account compromise leaves obvious traces, such as a string of failed logins followed by a success. A stolen token produces sign-ins that all appear legitimate, MFA included. Spotting it means correlating subtle signals, such as an unexpected IP address or an impossible location, rather than looking for an obvious failure.
What once required advanced skill is now widely accessible through phishing-as-a-service kits, which is why these attacks continue to grow.
Why are Passkeys Phishing-Resistant?
Passkeys, built on FIDO2 standards, work differently from passwords and codes.
Rather than relying on passwords and codes that can be intercepted, passkeys use cryptographic keys tied to a trusted device and to the legitimate service being accessed. A private key stays securely on the user's device, a matching public key is stored by Microsoft, and the private key never leaves the device.
That design makes passkeys significantly more resistant to phishing, credential relay, and MFA proxy attacks. Microsoft describes them as phishing-resistant because the credential is released only to the genuine service where it was registered.
The key to this is origin binding. A passkey registered for Microsoft will only authenticate with Microsoft's legitimate services. If an attacker builds a fake sign-in page on another domain, the passkey recognizes that the site is not where it was registered, and the authentication fails. Because the passkey will not authenticate to the fake origin, the attacker does not receive a valid session token.
How to Move to Phishing-Resistant Authentication in Microsoft 365
Many organizations are closer to phishing-resistant authentication than they realize.
Start with Windows Hello for Business
For organizations already invested in Microsoft 365, Windows Hello for Business is often the easiest entry point into phishing-resistant authentication.
It uses the same cryptographic principles as FIDO2, and when configured with a device security chip such as a TPM, it turns the device itself into a phishing-resistant credential unlocked by a PIN or biometric. Organizations already running Intune, Microsoft Entra ID, and Windows 11 frequently have the underlying technology available today.
Roll Out Passkeys in Tiers
A full passkey rollout does not need to happen all at once. Treat it as a risk management decision and secure your highest-value accounts first before expanding in waves.
|
Priority Group |
Recommendation |
|---|---|
|
Global administrators |
Hardware FIDO2 security keys |
|
Privileged accounts |
Hardware FIDO2 security keys |
|
Executives and public-facing leaders |
Microsoft Authenticator Passkeys or hardware keys |
|
Finance and HR |
Microsoft Authenticator Passkeys with Conditional Access |
|
General workforce |
Microsoft Authenticator Passkeys or Windows Hello for Business |
As you plan, account for the edge cases. Certain legacy desktop applications and older embedded mobile browsers do not yet support FIDO2 and will fall back to a push prompt, so identify those scenarios before enforcing anything broadly.
How Conditional Access Stops Token Theft
Conditional Access should sit at the center of the strategy. A few policies do the heavy lifting:
- Enforce phishing-resistant methods for sensitive workloads
- Block legacy authentication
- Require compliant, managed devices
Compliant device policies are particularly effective against AiTM, because the stolen token alone is not enough to satisfy a policy that also validates a trusted device.
It is also worth clarifying what happens after a compromise. Resetting the password is not enough on its own, because the stolen token and any attacker-added authentication methods can survive that reset. Effective response means revoking active sessions, revoking tokens, and reviewing any authentication methods or connected applications the attacker may have added.
Cost is rarely the barrier, either. Passkeys and FIDO2 are available across all Microsoft Entra ID editions, including the free tier, so no additional licensing is required to begin. Organizations should move from Entra's legacy MFA and self-service password reset controls to the unified Authentication methods policy.
This proves one place to manage modern methods such as passkeys and Microsoft Authenticator, with more precise control over which users and groups can use them.
Is your MFA Still Enough?
MFA still does important work in Microsoft 365, and skipping it leaves you far more exposed than teams that have not deployed it.
The difference now is where the industry is heading. Session hijacking, token theft, MFA fatigue, and adversary-in-the-middle attacks have exposed the limits of traditional MFA, and the broader ecosystem is responding. Microsoft, Google, and Apple are among the major organizations aligned behind FIDO2 passkeys and passwordless authentication standards.
For many organizations, the question is no longer whether to deploy MFA. It is whether the MFA currently in place is still enough.
Subscribe To
Sourcepass Insights
Sourcepass Insights
Stay in the loop and never miss out on the latest updates by subscribing to our newsletter today!
