Notifications
Clear all
Topic starter
12/06/2026 12:30 am
TL;DR: Attackers are increasingly bypassing phishing-resistant authentication by downgrading users to backup MFA methods inside attacker-in-the-middle phishing flows, according to Push Security. Passwordless helps, but it does not remove the governance problem created by multiple active login paths and inconsistent app-level controls.
NHIMG editorial — based on content published by Push Security: MFA downgrade and auth downgrade techniques used to bypass phishing-resistant authentication
Questions worth separating out
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.
Q: Why do passkeys still leave organisations exposed to phishing attacks?
A: Passkeys reduce phishing risk only when they are the sole usable method.
Q: What do security teams get wrong about conditional access and authentication strength?
A: They often assume an IdP policy protects every app equally.
Practitioner guidance
- Inventory every active authentication path List passwords, passkeys, OTP, push, backup codes, and any SSO fallback for each high-risk account.
- 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.
- Measure app-by-app conditional access coverage Audit which business applications actually inherit device, location, and authentication-strength policies from the IdP.
What's in the full article
Push Security's full research covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how downgrade attacks alter the authentication flow inside attacker-in-the-middle phishing kits.
- Browser-based detection and response approaches for blocking AiTM techniques before session capture completes.
- Practical guidance on identifying backup MFA and login methods across business applications.
- Examples of app-level configuration gaps that allow the strongest login method to be bypassed.
👉 Read Push Security's analysis of MFA downgrade attacks and passkey bypass →
MFA downgrade attacks: are your backup login methods the gap?
Explore further
12/06/2026 9:46 am
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.
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.
A question worth separating out:
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.
👉 Read our full editorial: MFA downgrade attacks expose the limits of passwordless rollouts
