MFA downgrade attacks expose the limits of passwordless rollouts

At a glance

What this is: This analysis explains how MFA downgrade attacks let phishers bypass passwordless and other phishing-resistant methods by forcing users onto weaker backup login paths.

Why it matters: It matters because identity teams cannot treat passkeys as a complete control unless backup methods, app defaults, and conditional access are governed across the full login estate.

Context

MFA downgrade is an identity governance problem, not just a phishing trick. If an account still has more than one active login path, an attacker can steer the user toward the weakest available method and bypass the stronger one.

The practical issue is that many organisations layer passkeys or phishing-resistant MFA on top of existing backup methods, rather than removing the weaker options. That leaves a control gap across the app estate, especially where the identity provider does not centrally govern every relying party.

Key questions

Q: What breaks when backup MFA methods remain active after passkey rollout?

A: The strongest login method stops being the effective control if users can still be pushed onto a weaker fallback. Attackers do not need to defeat the passkey itself when a phishable alternate method is still enrolled and reachable. The governance failure is method sprawl, not passkey weakness.

Q: Why do passwordless programmes still need conditional access and app-level policy?

A: Passwordless reduces phishing exposure, but it does not guarantee that every app enforces the same login rules. Conditional access and app-specific configuration are needed because many services either lack central enforcement or allow weaker methods to persist. Without those controls, the rollout is incomplete.

Q: How can security teams tell whether MFA downgrade risk is still present?

A: Look for accounts that have more than one active sign-in method, especially where the weaker option can still be chosen during login. Also check whether apps default to the strongest method or let users switch to backup options. Those are the clearest signals that downgrade attacks remain viable.

Q: What should organisations do when an app does not support the preferred authentication policy?

A: Treat the app as an exception that needs compensating controls, not as a reason to accept weaker login behaviour. Restrict access paths where possible, remove redundant credentials, and document the residual exposure so the application cannot silently undermine the broader identity programme.

Technical breakdown

How MFA downgrade works inside attacker-in-the-middle phishing

MFA downgrade attacks work by altering the login choice presented to the user during an attacker-in-the-middle session. The phishing site relays traffic to the real service, but it can also change prompts so the user selects a backup method instead of a passkey or other phishing-resistant factor. The key point is that the attacker does not need to defeat the strongest factor directly if the account still exposes weaker alternatives. This is why a phishable fallback is enough to collapse the security value of the stronger method.

Practical implication: Treat every additional login path as part of the attack surface, not as a harmless convenience option.

Why passwordless does not eliminate backup-method risk

Passwordless authentication improves resistance to phishing because a domain-bound passkey cannot be replayed on a fake domain. But passwordless rollout rarely removes all older methods at once. In many environments, users still retain SMS, OTP, recovery codes, passwords, or alternate SSO paths, and those remain targetable. That creates a governance mismatch: the strongest method protects only if the weaker methods are disabled, tightly scoped, or made unreachable through policy. Otherwise, the weaker factor becomes the real control boundary.

Practical implication: Inventory and retire backup methods as part of the passwordless programme, not after it.

Why app-level login variance keeps exposure high

The article highlights a structural problem across SaaS and enterprise apps: identity controls are not uniform. Some applications default to the strongest method, others require manual configuration, and many do not support the same conditional access or authentication enforcement as the core IdP. In practice, this means central policy can be undermined by local app behaviour, especially where users can add methods themselves or where security teams lack admin control. The result is a fragmented authentication estate with uneven enforcement.

Practical implication: Assess app-by-app authentication settings instead of assuming IdP policy is enough.

Threat narrative

Attacker objective: The attacker wants to obtain authenticated access to the account by steering the victim onto a phishable fallback path.

1. Entry occurs through an attacker-in-the-middle phishing kit that proxies a legitimate login session while presenting a fake interface to the victim.
2. Credential and session capture are not the only objective because the attacker can downgrade the user to a weaker factor such as a backup code, password, or alternate SSO path.
3. Impact is account takeover despite the presence of a phishing-resistant method, because the user authenticated through the weaker path the attacker selected.

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

Backup authentication is now the real weak point in many passwordless programmes. The security promise of passkeys depends on weak alternatives being removed, not merely hidden behind a better default. When SMS, OTP, passwords, or recovery flows remain active, the attacker targets the path of least resistance rather than the primary factor. Practitioners should treat fallback methods as first-class governance objects, not temporary migration artefacts.

Phishing-resistant authentication fails when app governance is inconsistent. Central identity policy cannot fully compensate for applications that expose different login behaviours, different default methods, or weak method-selection logic. That means the authentication control plane is split between the IdP and the application, and attackers exploit the seam. The practical conclusion is that identity teams need app-level enforcement data, not just IdP policy status.

Conditional access only helps where the application actually honours it. The article makes clear that robust policy can reduce risk on core platforms, but many applications do not support the same controls or are not centrally managed. That creates a long tail of direct-login exposure outside the main IdP boundary. Security teams should read this as evidence that authentication governance must extend beyond the primary login stack and into every app that still accepts alternate methods.

Ghost logins and additive MFA create an identity debt problem. Organisations often add new authentication methods without removing the old ones, which leaves multiple valid paths to the same account. Over time, the account accumulates dormant or backup access routes that are hard to find and harder to eliminate. The result is a growing governance burden that turns convenience into persistent authentication risk.

Passwordless adoption is a control migration, not a control replacement. The market sometimes treats passkeys as an end state, but the article shows that rollout quality matters more than feature availability. Identity security improves only when the weakest surviving method set is removed across the estate. Practitioners should measure progress by method reduction and enforcement consistency, not by passkey enrollment alone.

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

Fallback methods are the hidden governance layer in passwordless programmes. The question is not whether passkeys work, but whether every weaker route has been removed from the account lifecycle. If the answer is no, the organisation has modernised its primary method while preserving a downgrade path.

Authentication control now depends on method inventory. Identity teams need a complete view of passwords, recovery codes, alternate MFA methods, and app-specific login options across the estate. Without that inventory, policy assumes stronger enforcement than the actual user experience delivers.

For practitioners

• Remove backup login paths Delete unused passwords, recovery codes, SMS factors, and alternate authentication methods wherever the business app allows it, so phishing-resistant methods are no longer bypassable through a weaker fallback.
• Enforce phishing-resistant MFA on core IdP accounts Require passkey or equivalent phishing-resistant authentication on the primary identity provider account that governs access to business applications, and block weaker methods where policy support exists.
• Review app-level authentication defaults Check whether each business application allows method selection, fallback promotion, or local overrides that can defeat the strongest available login method.
• Tighten conditional access coverage Limit access to domain-joined devices and trusted network conditions for applications that support it, then document the apps that cannot enforce those controls.
• Inventory ghost logins and dormant MFA methods Find accounts that still retain passwords or multiple MFA methods after passwordless rollout, then remove the surplus methods through lifecycle change control.

Key takeaways

• MFA downgrade attacks succeed because an account still has a weaker login path that the attacker can steer the user toward.
• The risk is not theoretical. Modern phishing kits can proxy legitimate logins while modifying the choice of authentication method.
• The decisive control is not passkey adoption alone, but removal of backup methods and consistent enforcement across applications.

Key terms

• MFA downgrade attack: An MFA downgrade attack is an attempt to weaken or bypass multi-factor authentication so a login falls back to a less secure method. It usually works by exploiting recovery flows, legacy protocols, push fatigue, or misconfigured conditional access, allowing an attacker to authenticate with fewer factors than intended.
• 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.
• Conditional Access: Conditional access is a policy model that decides whether an action should proceed based on context such as posture, resource sensitivity, timing, and scope. For AI agents, it must be evaluated at request time so a valid credential does not automatically equal permitted behaviour.
• Backup Authentication Method: An alternate verification method used when the user’s primary MFA factor is unavailable. Good governance treats backup methods as part of the authentication design, not as an afterthought, because they preserve access without forcing unsafe recovery workarounds.

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.