TL;DR: Phishing and credential theft are reduced far better by passkeys, email magic links, authenticator apps, and hardware security keys than by SMS and push-based flows, while also improving session handling and recovery design, according to Descope. The key governance point is that MFA is only as strong as the fallback path, because weak recovery and approval fatigue can undo strong primary factors.
NHIMG editorial — based on content published by Descope: 4 Safest MFA Methods & Flows to Implement
By the numbers:
- 33% of organisations report their AI agents have accessed inappropriate or sensitive data beyond their intended scope.
- 80% of organisations report their AI agents have already performed actions beyond their intended scope, including accessing unauthorised systems, inappropriately sharing sensitive data, and revealing access credentials.
Questions worth separating out
Q: How should security teams implement phishing-resistant MFA for privileged SaaS access?
A: Start with the identities that can export data or change access, including IdP admins, SaaS admins, and helpdesk staff.
Q: Why do MFA implementations still fail even when a second factor is enabled?
A: MFA fails when the validation process is weaker than the factor itself.
Q: What do organisations get wrong about push notification MFA?
A: Organisations often treat push MFA as if user approval were equivalent to strong proof of identity.
Practitioner guidance
- Prioritise phishing-resistant factors for high-value accounts Move administrative, executive, finance, and support accounts to passkeys or hardware security keys first, then phase weaker methods out of sensitive workflows.
- Review recovery paths as part of the authentication control Test password reset, backup code, device replacement, and helpdesk recovery steps against the same assurance standard as the primary sign-in flow.
- Reduce dependence on SMS and push approvals Limit SMS and approval-based push flows to lower-risk use cases while planning a migration to cryptographic factors for sensitive access.
What's in the full article
Descope's full article covers the implementation detail this post intentionally leaves for the source:
- Practical comparisons of passkeys, email magic links, authenticator apps, and hardware security keys in user-facing flows
- Implementation notes on SPF, DKIM, and DMARC for email magic-link deliverability and spoofing resistance
- Flow examples for password plus token, passkey-based login, and password plus magic-link authentication
- Discussion of when SMS and push should be treated as transitional options rather than final-state controls
👉 Read Descope's analysis of the safest MFA methods and login flows →
Safest MFA methods: are your login flows actually phishing-resistant?
Explore further
Phishing-resistant MFA is now an identity assurance problem, not a feature checklist. The article is correct to separate passkeys and hardware security keys from weaker second factors, because the control objective is resisting replay, coercion, and approval abuse. In IAM terms, the programme should measure whether the factor can be phished, not whether the user had to click twice. That makes authentication design a governance decision, not a UX preference.
Phishing-resistant MFA should be treated as a baseline control for human identity programmes that still rely on privileged workflows. The practical shift is away from second-factor presence toward factor resistance, recovery integrity, and session revocation. Teams that keep SMS or push as default options will keep carrying avoidable account-takeover risk into their IAM stack.
A question worth separating out:
Q: How can teams tell whether their MFA design is actually strong enough?
A: Check whether the factor resists phishing, whether recovery preserves the same assurance, and whether sessions can be revoked quickly after suspicious behaviour. If any of those three steps are weaker than the login flow, the programme is still exposed.
👉 Read our full editorial: Phishing-resistant MFA is the practical baseline for account security