MFA downgrade attacks expose the limits of passwordless rollouts

At a glance

What this is: This analysis explains how MFA downgrade attacks let attackers steer users from phishing-resistant login methods to weaker backup options.

Why it matters: It matters because identity teams can deploy passkeys and still leave accounts exposed if backup methods, app gaps, and conditional access exceptions remain in place.

👉 Read Push Security's analysis of MFA downgrade attacks and passkey bypass

Context

MFA downgrade is a control bypass problem, not a failure of passwordless authentication itself. The issue appears when an account still has multiple sign-in methods and the attacker can steer the user toward the weaker one, which turns authentication choice into an attack surface for human IAM.

For identity programmes, this sits at the boundary between human authentication, access policy, and application governance. Stronger methods such as passkeys reduce phishing exposure, but they do not deliver full assurance unless security teams can remove fallback methods and enforce the strongest available path across the estate.

Key questions

Q: How should security teams prevent MFA downgrade attacks in mixed authentication estates?

A: Start by identifying every allowed sign-in method per application and per user class. Then remove unused or weaker options, especially for privileged access and sensitive workloads. The goal is not to add more MFA choices, but to narrow the set until users cannot be silently pushed from phishing-resistant methods to phishable fallbacks.

Q: Why do passkeys still leave organisations exposed to phishing attacks?

A: Passkeys reduce phishing risk only when they are the sole usable method. If passwords, backup codes, OTP, or other legacy methods remain active, attackers can downgrade the session to one of those paths. The exposure is created by the account’s remaining authentication surface, not by the passkey itself.

Q: What do security teams get wrong about conditional access and authentication strength?

A: They often assume an IdP policy protects every app equally. In reality, conditional access coverage varies, and some applications do not inherit the same controls. Teams need to verify where the policy actually applies, because a strong centre with weak downstream apps still leaves a workable attack path.

Q: Who is accountable when backup login methods remain enabled after passwordless rollout?

A: Accountability sits with the identity owner and the application owner together, because the risk comes from a governance gap across both layers. If a fallback method remains enabled, the programme has not completed the control change. That should be tracked as an access governance exception until the weaker path is removed.

Technical breakdown

How attacker-in-the-middle phishing enables MFA downgrade

Attacker-in-the-middle kits sit between the user and the real site, relaying traffic so the victim appears to authenticate normally. The downgrade step changes the choice architecture inside that session. Instead of letting the user select a phishing-resistant method such as a passkey, the phishing page suppresses that option and pushes a weaker fallback such as an OTP code, backup authenticator, or password path. That means the attacker is not defeating the strongest method directly. They are exploiting the fact that the account still accepts weaker ones, and the session becomes valid once any permitted method succeeds.

Practical implication: remove fallback methods wherever possible and verify that the strongest method is the only usable path.

Why passkeys reduce phishing risk but do not eliminate it

Passkeys are domain-bound, which makes them resistant to replay on a fake domain. The problem is not the cryptography of the passkey itself but the operational reality of mixed authentication estates. Many organisations add passwordless methods without fully retiring passwords, SMS, push approvals, or app-based OTP. That leaves an account with multiple active factors, and an attacker only needs the weakest surviving option. In practice, adoption often happens additively, so the control set grows instead of narrowing. The technical failure is not absence of a strong method. It is the persistence of weaker methods that remain reachable under attack.

Practical implication: treat passwordless rollout as a deprecation programme for weak methods, not an additive feature deployment.

Conditional access only helps when the app actually supports it

Conditional access can reduce account takeover risk by checking device state, IP location, and authentication strength after login, but it only works where the application stack supports it. Many downstream apps do not support the same policy depth as the IdP, and some sit outside central management entirely. In those cases, an attacker may bypass the core IdP path and target the app directly. This creates a split control plane: the IdP is hardened, but the app remains permissive. Security teams often overestimate coverage because the main directory looks well controlled while the long tail of SaaS apps still accepts weaker login paths or unmanaged methods.

Practical implication: map conditional access coverage per application, not just at the IdP layer.

NHI Mgmt Group analysis

Backup authentication method persistence is the real control gap behind MFA downgrade. Organisations often think the threat is phishing resistance failure, but the deeper issue is that backup methods remain accepted after stronger methods are added. That creates an enduring alternate path for attackers to exploit. The implication is that MFA policy is only as strong as its weakest still-enabled method.

Passkey adoption does not equal phishing resilience unless the surrounding account model is simplified. Passwordless authentication lowers risk, but mixed estates with passwords, OTP, push, and SSO fallbacks preserve downgrade opportunities. The discipline problem is lifecycle, not feature selection. Practitioners need to recognise that authentication assurance degrades whenever multiple active paths are left available.

Conditional access is a boundary control, not a universal fix. It can harden the primary identity provider, but many SaaS applications do not inherit those protections consistently. That means the enterprise can have strong policy at the centre and weak access paths at the edge. Practitioners should treat app-by-app policy coverage as part of identity governance, not a separate technical detail.

Ghost logins and backup methods create hidden authentication debt. The article points to the difficulty of finding and removing older login paths once users have accumulated several methods over time. That is the same governance pattern as NHI sprawl: an identity looks secure until the unused but still-valid access path is found. Practitioners should assume any additive login history will eventually be abused.

Phishing-resistant authentication fails when account administration is not designed for removal. This is not a case for more authentication layers, but for narrower, enforceable authentication choice. A control that can be bypassed by selecting a weaker option has not been fully governed. Practitioners should redefine assurance around what cannot be selected at runtime, not what was once enrolled.

From our research:

• 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, according to The State of Non-Human Identity Security.
• A separate finding from the same research shows that 45% of organisations cite lack of credential rotation as the top cause of NHI-related attacks.
• For a broader control lens, see OWASP NHI Top 10 for how identity attack surfaces expand when runtime access paths multiply.

What this signals

Passwordless adoption is accelerating, but the real governance burden is now removal. Security teams need to model authentication as a lifecycle problem, because every added method becomes a future downgrade candidate unless it is actively retired. The practical shift is from enrolling stronger methods to eliminating weaker survivals.

Authentication choice debt: the longer a user can choose among multiple methods, the more likely the account is to remain phishable. That is a governance concept worth tracking alongside privilege creep and ghost logins, because the underlying problem is the same: access paths accumulate faster than they are removed.

For programmes already standardising on passkeys, the next step is not more user education alone. Teams should verify policy enforcement at the application edge, align it with NIST SP 800-63 Digital Identity Guidelines, and treat any uncancellable fallback as a control exception rather than a user convenience.

For practitioners

• Inventory every active authentication path List passwords, passkeys, OTP, push, backup codes, and any SSO fallback for each high-risk account. Remove unused methods first, then confirm that the remaining path cannot be silently downgraded during sign-in.
• Enforce strongest-method priority at the IdP Configure identity providers to require the phishing-resistant method where supported, and block weaker alternatives for privileged users and sensitive applications. Where app settings are local, push the same rule into the application itself.
• Measure app-by-app conditional access coverage Audit which business applications actually inherit device, location, and authentication-strength policies from the IdP. Treat uncovered applications as governance exceptions, not technical edge cases.
• Remove ghost logins during access reviews Use access review cycles to find accounts that still support passwords or legacy MFA even after passwordless adoption began. Deleting those paths reduces the number of ways an attacker can complete a downgrade attack.

Key takeaways

• MFA downgrade succeeds because weaker backup methods remain available after stronger authentication is added.
• Passkeys reduce phishing exposure, but mixed authentication estates still leave a usable attack path.
• The control objective is not more login options, but fewer ways for an attacker to force a weaker one.

Key terms

• MFA Downgrade: An attack technique that forces or tricks a user into using a weaker authentication method than the strongest one available. The account still appears protected, but the attacker exploits the remaining fallback path to complete login through a phishable factor.
• Passkey: A phishing-resistant authentication method bound to the correct domain and device. In enterprise use, a passkey can sharply reduce replay and proxy phishing risk, but only when weaker backup methods are removed or tightly constrained.
• Conditional Access: A policy layer that evaluates context such as device state, location, or authentication strength before granting access. It improves identity control only where it is actually enforced across the application estate, not just at the primary identity provider.
• Ghost Login: An older or secondary sign-in method that remains active even though the organisation considers the account modernised. These hidden paths create governance debt because attackers often need only one surviving route to regain access.

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 responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.

This post draws on content published by Push Security: MFA downgrade and auth downgrade techniques used to bypass phishing-resistant authentication. Read the original.