Passkeys vs OTP vs authenticator apps: choosing login methods for your app

Every product that has user accounts eventually has to answer the same question: how do people prove it's them? The usual options are SMS codes, voice calls, authenticator apps and, increasingly, passkeys. Each has a different balance of security, cost and friction.

This guide compares them in practical terms. If you want the design side of making MFA pleasant, read our earlier piece on designing multi-factor authentication users don't hate.

#The options at a glance

#SMS and voice codes

SMS codes are familiar to almost everyone, which is why they are so common, especially in India where OTP-based flows are part of everyday banking and payments.

Their weaknesses are well known:

• Phishing. A fake login page can ask for the code and pass it to the real site in real time.
• SIM swaps and number recycling. An attacker who takes over a phone number receives the codes.
• Delivery. Codes arrive late or not at all on poor networks and international numbers.
• Cost and abuse. Every message costs money, and bots can trigger floods of messages to premium numbers.

The latest revision of NIST's digital identity guidelines classifies phone-delivered codes as a restricted authenticator: allowed, but with extra conditions and an expectation that services offer something stronger.

Voice calls share these weaknesses and add friction. They are still worth keeping for users without smartphones or who rely on audio.

Use them for: fallback and recovery, low-risk accounts, and users who can't use other methods.

#Authenticator apps (TOTP)

Apps like Google Authenticator, Microsoft Authenticator or a password manager generate a six-digit code every 30 seconds from a shared secret.

• Pros: no per-message cost, works offline, not tied to a phone number.
• Cons: setup involves scanning a QR code, which loses some users; codes can still be phished; switching phones without a backup locks people out.

Always show backup codes during setup, and let users add more than one device.

#Push approvals

A push notification asks "Is this you signing in?" in your mobile app. It's low friction, but attackers exploit fatigue by sending repeated prompts until someone taps approve. Number matching (the user types a number shown on the login screen) and rate limits fix most of this.

#Passkeys

Passkeys are built on the WebAuthn and FIDO2 standards. When a user registers, their device creates a key pair. The site stores only the public key. To sign in, the device proves it holds the private key after the user unlocks it with a fingerprint, face or PIN.

Why they matter:

• Phishing resistant. A passkey is bound to the real domain, so a look-alike site can't use it.
• Nothing to steal from your database. Public keys are useless to an attacker.
• Fast. Signing in is usually a single biometric prompt.
• Synced. Passkeys stored in Apple, Google or password-manager accounts follow users to new devices.

The open questions are mostly about recovery and mixed devices. Plan for a user who loses their only phone, or who signs in from a shared computer.

#A practical setup for most products

1. Default: passkeys for users whose devices support them, offered right after sign-up or sign-in.
2. Second option: an authenticator app, with backup codes shown at setup.
3. Fallback: SMS or email codes, rate-limited and restricted to expected countries.
4. Recovery: a tested process, such as backup codes, a second registered passkey or identity verification for high-value accounts.
5. Step-up: ask for a stronger factor before sensitive actions like changing payout details or exporting data.

#Implementation checklist

• Rate-limit code requests and verification attempts per account and per IP.
• Expire codes quickly and invalidate them after use.
• Never reveal whether an account exists in error messages.
• Log authentication events so you can detect takeover attempts.
• Notify users by email or in-app when a new factor or device is added.
• Test the full journey on low-end Android devices and slow networks.
• Store secrets with the same care as passwords, and follow the OWASP Top 10 checklist for the rest of the stack.

#Where to start

If your app relies only on SMS codes today, the simplest upgrade is adding passkeys as an option for returning users and moving SMS to a fallback role. Measure sign-in success rate and time to sign in before and after.

We build authentication flows for web and mobile apps, and publish our open-source Flutter MFA packages for TOTP/HOTP authenticators with hardware-backed storage. Talk to us about your login flow.