TL;DR
- Attackers can force FIDO off by spoofing an unsupported browser, exposing weaker fallback paths.
- AiTM kits then steal session cookies and take over accounts without passwords or MFA.
- No widespread in-the-wild use reported yet, but targeted risk is real.
- Mitigate by enforcing phishing-resistant methods with Conditional Access auth strengths and minimizing fallback.
Here’s the context
FIDO passkeys are designed to stop phishing by using device-bound cryptographic keys. They prevent credentials from traveling over the network. But enterprise identity systems often keep alternate sign-in paths for continuity and recovery.
That design opens a door: if the primary method is unavailable—or appears to be—users fall back to less secure methods that standard phishing kits can intercept.
What is a “FIDO downgrade attack”?
A technique that intentionally forces a login flow away from FIDO passkeys to a weaker fallback method, typically by spoofing an environment where FIDO is “unsupported,” making phishing and session hijack possible.
Why this matters now
The FIDO downgrade attack does not crack cryptography; it exploits fallback architecture. As passkeys expand, organizations must ensure that “unsupported” states trigger protective policy—not user choice. Enforce phishing-resistant methods, restrict recovery paths, and watch for downgrades.
Let us dive deep:
Why this works
- The first principle: Security equals the strength of the weakest reachable path, not the strongest one.
- What could be the silent dependency: If fallback exists and is reachable, attackers will try to force users into it.
- The major compatibility gap: Some OS/browser pairs lack full FIDO support in Entra ID. Attackers exploit that gap with user-agent spoofing.
How the attack runs (step-by-step)
- Victim receives a phishing link to a proxied Entra ID page (AiTM kit such as Evilginx).
- The kit spoofsan unsupported browser user-agent (e.g., Safari on Windows) to the Entra ID backend.
- Entra ID disables passkeys and returns an error, prompting alternate sign-in.
- User selects a fallback (e.g., Microsoft Authenticator code, SMS, OTP).
- The proxy captures credentials and the MFA token or session cookie.
- Attacker imports the cookie and hijacks the session—no passkey or MFA required.
Implications & Consequences
Short term: Targeted account takeovers become feasible even for “phishing-resistant” users, especially admins and high-value roles.
Long term: Passkey rollouts that retain broad fallback paths will underperform. Organizations must govern which methods are allowed per resource and user risk.
What do experts say?
- Weakest-link pathing: Don’t measure security by your best control; measure by the easiest successful route.
- Compatibility pressure: “Works everywhere” often conflicts with “secure everywhere.” Treat “unsupported” as a policy event, not a silent fallback.
- Session-centric threat: Modern phishing steals sessions, not just passwords.
- Auth-strength as code: Control allowed methods with policy, not user choice at runtime.
Busting the myth and blind spots
- Myth: “FIDO can’t be phished.” FIDO isn’t broken; it’s being bypassed by forcing weaker paths.
- Blind spot: Fallback prompts feel normal to users. Without banners, logs, or policy blocks, downgrades slip by unnoticed.
- Operational risk: Helpdesk recovery habits can widen the fallback surface if not constrained by policy.
Notable Statements
“This seemingly insignificant gap in functionality can be leveraged by attackers… the user would be forced to authenticate through a less secure method.”
— Proofpoint researcher Yaniv Miron
“The campaign is not the result of a product vulnerability… We recommend customers enforce phishing-resistant methods via Conditional Access authentication strength.”
— Microsoft spokesperson
Primary vs. Fallback: What’s at Risk?
| Method | Phishing Resistance | AiTM Risk | Recommended Use |
|---|---|---|---|
| FIDO Passkey (Security Key / Platform Auth) | High | Low (if enforced) | Primary method for privileged and high-risk access |
| App Code / TOTP | Medium | Medium–High | Tightly scoped; avoid for admin access |
| SMS / Voice | Low | High | Last-resort recovery; consider disabling |
FAQ / Quick Facts
What changed this week? Researchers demonstrated a working downgrade against Entra ID passkeys.
Does this break FIDO? No. It bypasses FIDO by removing it from the flow.
How is the bypass triggered? By spoofing an unsupported user-agent so the service hides FIDO and prompts fallback.
What do attackers steal? Credentials and/or the session cookie via an AiTM proxy.
What should admins do now? Enforce passkey-only where possible; restrict or disable fallback; alert on downgrades.
Practical Mitigations (Admin Checklist)
- Enforce authentication strengths that allow only phishing-resistant methods for sensitive apps and roles.
- Minimize fallback (disable SMS/voice; restrict OTP to low-risk contexts).
- Alert on downgrade events and unexpected method prompts.
- Harden helpdesk flows so recovery cannot silently weaken policy.
- Educate users: treat surprise “use another method” prompts as a red flag.
Further Reading
Here are some of our resources
- Passkeys vs. Passwords: Architecture and Threat Models
- Entra ID Conditional Access: Designing Auth Strengths
- Stopping AiTM: Protecting Sessions, Not Just Credentials
