When should banks prioritise passkeys over SMS or push MFA?

Why banks should treat passkeys as the default, not just another MFA option

Passkeys are the right priority when the bank’s authentication problem is really about phishing resistance, replay resistance, and reducing user friction at scale. SMS codes and push prompts can still have a role in recovery paths, legacy populations, or limited fallback flows, but they preserve more of the old secret-sharing model and remain easier to intercept, coerce, or fatigue into approval.

That makes passkeys less about “newer MFA” and more about changing the trust boundary. A well-run rollout replaces shared knowledge and reusable secrets with device-bound cryptographic sign-in, which materially lowers the value of phishing kits, proxy attacks, and credential replay. It also tends to improve completion rates because the user is proving possession and presence in one step instead of copying a code or approving a prompt.

Banks should think in terms of where the residual risk sits after sign-in. If the bank still depends heavily on SMS for first-time enrollment, recovery, or step-up authentication, it needs to understand that those channels can become the weakest link even if passkeys are available for normal login. The practical question is not whether SMS or push can work, but whether they remain the default path for the users and transactions that matter most.

When SMS and push still make sense

SMS and push MFA are usually better treated as transitional or exception mechanisms. They can help when device coverage is uneven, when a customer cannot yet register a passkey, or when the bank needs a fallback for account recovery and support desks. In those situations, they reduce access friction and keep the service usable while the passkey estate grows.

The trade-off is that both methods inherit known weaknesses. SMS depends on the telecom channel and the phone number lifecycle, which exposes banks to SIM swap, number recycling, and message interception. Push relies on the user’s ability to distinguish a legitimate challenge from a fatigue or bombing attack, which means the control can fail under pressure even when the authenticating app itself is technically sound.

For banks, that means push and SMS are not simply lower-cost alternatives. They are weaker defaults unless the institution can tightly bound where they are allowed, how often they are used, and what recovery or step-up cases justify them. The MFA Guide is useful here because it separates the bypass patterns from the decision to keep a method in the stack at all.

Where banks already have strong digital enrollment and customer support operations, a phased passkey rollout usually gives a better long-term control posture than continuing to scale SMS or push. NIST SP 800-63 Digital Identity Guidelines is relevant because it frames phishing-resistant authenticators and authenticator assurance in a way that supports that migration decision.

What changes in a bank environment when passkeys become the preferred path

Banking has a higher consequence profile than ordinary consumer login, so the choice of MFA method is really a choice about blast radius. When passkeys are the primary path, a stolen password no longer gives an attacker the same leverage, and an intercepted one-time code is no longer enough to complete most sign-ins. That is a material improvement for both retail fraud and targeted account takeover.

Passkeys also change operational design. The bank must support enrollment, device loss, re-binding, and recovery without silently recreating the old SMS dependency everywhere. The rollout works best when the bank can make passkeys the normal experience, keep fallback paths narrow, and instrument enrollment and recovery so the support desk is not the place where phishing resistance collapses.

Several real-world incidents show why that matters. Twilio 0ktapus breach 2022 and Change Healthcare breach 2024 both illustrate how weaker authentication paths can be exploited at scale once attackers get the user to complete the wrong challenge or reuse a vulnerable login path.

Passkeys are therefore not just a security upgrade, they are a control simplification. If the bank can standardise them for high-value customer journeys and staff access, it reduces dependence on phone-number trust, reduces phishing exposure, and makes sign-in behaviour more predictable for detection and fraud teams.

Practitioner Guidance

What to prioritise: Prioritise passkeys first for customers and employees whose compromise would create the largest fraud, data, or operational impact. Keep SMS or push only where there is a documented gap in enrollment, device support, or recovery coverage.

Decision rule: If the bank can support recovery without making SMS the default escape hatch, treat passkeys as the primary method. If recovery still depends on weak fallback channels, the rollout is not ready to be called phishing-resistant in practice.

What to verify: Verify that the help desk, account recovery flow, and step-up rules do not reintroduce the same replay and coercion risks that passkeys are meant to remove. The control is only as strong as the weakest approved alternative path.

Practitioner takeaway: Banks should move to passkeys when they can own the full journey, not just the login screen. The right default is the one that lowers fraud exposure without pushing users and support staff back into the old secret-sharing model.

Related resources from NHI Mgmt Group

• When should identity teams prioritize passkeys over password resets and SMS MFA?
• Should banks prioritise passkeys over other identity changes first?
• Why do passkeys matter more than SMS for MFA?
• Should organisations prioritise phishing-resistant MFA over other identity projects?