Passkeys vs OTP vs SMS Auth: Which One Should Your Service Use?

When you start reviewing ways to strengthen login security, the first challenge you run into is deciding which method to adopt: passkeys, OTP, or SMS authentication. All three provide multi-factor authentication (MFA), but each works in a different way.

First, Set Your Criteria

If you judge an authentication method on security alone, your conclusion can end up skewed. You should weigh three criteria together, taking into account the practical constraints of running your service.

• Phishing resistance: Even if a user lands on a fake site, is their credential kept from leaking?
• Implementation difficulty: How much do development, operations, and incident response cost?
• User convenience: Will users keep using it to the end, and can they recover access if they change devices?

Phishing resistance is the top priority for a clear reason. Many of today's account takeovers happen not because of weak passwords alone, but because users type their information directly into a forged login page. Whether a method can block that path entirely is the biggest difference between the three.

How the Three Methods Work

SMS authenticationThe server sends a 6-digit code by text message, and the user types it in manually. The sign-up process is simple, so it is widely used. However, because the user enters the code by hand, it can leak to a phishing site. There are also network-level weaknesses such as SIM swapping and number reassignment. Major standards bodies like NIST classify phone-based authentication as a restricted security measure.

OTPusually refers to TOTP. An app like Google Authenticator generates a code every 30 seconds, and the server verifies it against the same secret key. Because it does not rely on the phone network, it is safe from SIM swapping. But the user still has to type the code in, so it remains vulnerable to real-time relay phishing attacks.

Passkeyssign with a private key stored on the device, while the server keeps only the public key. The browser verifies the service's domain before signing, so the authentication process is blocked outright on a phishing domain. The key point of this method is that there is no room for the user's own judgment to get involved.

Comparison at a Glance

One point to note in the table is the 'low implementation difficulty' entry for SMS auth. Generating and sending the code is easy, but once you account for sending vendor integration, error handling, abuse prevention, and cost management, it calls for more operational review than the simple feature build suggests.

I am against adopting passkeys for the time being. Libraries have made implementation much easier, but the core challenge lies in designing the recovery process. If there is no way for users to recover their accounts when they lose a device, I expect customer support inquiries to surge regardless of the security gains.

What to Choose by Situation

A personal blog or small communityFor the admin account, I recommend prioritizing TOTP. With a small user base and limited operations staff, a method that carries no external sending costs is a good fit. For regular members, offering social login or a passkey option should be enough.

Consumer services(shopping, content, subscriptions): A realistic setup is to adopt passkeys as the default login method and keep passwords and TOTP as secondary options. Switching existing users all at once is not practical, so a gradual approach works better: prompt users to set up a passkey right after they log in, and raise the conversion rate over time.

Finance, payments, and services handling sensitive personal dataGiven the scale of damage phishing attacks can cause, you should adopt passkeys as the primary authentication method. Regulatory and authentication requirements can differ by industry, so please check the relevant standards in advance. Also, using SMS authentication as a standalone method is less safe than using it as a supplementary verification step.

Internal tools and admin consolescall for passkeys or hardware security keys. There are few users and you can control the devices, so this is the environment where adoption is least burdensome.

When you really do need SMS authenticationThere are cases where it is necessary. If phone-based identity verification is required at sign-up, or if many of your users have limited ability to install apps, limit SMS to confirming phone number ownership rather than using it as a login security method. Also, be sure to apply limits on the number of sends and attempts to prevent indiscriminate sending.

Suggested Rollout Order

Rather than trying to pick just one at once, it is better to split this into stages.

1. Make TOTP or passkeys mandatory for admin accounts first.
2. Open passkey registration as an optional choice for regular users.
3. Once enrollment rates build up, switch the default login flow on the login screen to passkeys first.
4. Keep SMS only for supporting uses like recovery and identity confirmation.

At the end of each stage, test directly that the recovery path actually works. Unless you reproduce the scenario of losing a device at least once, that path will be the weakest link. Attackers do not break through strong authentication; they click "Recover my account."

The Answer Is a Combination

On phishing resistance, passkeys have the edge, but on ease of adoption, SMS is ahead. TOTP serves as a compromise that balances cost and security. Considering your service's risk level and your users' environment, the most recommended standard model is passkeys as the primary method, TOTP as the fallback, and SMS as a supplementary method.