Phone verification is how a store confirms that the person creating an account controls the phone number they gave, and there are three methods in common use. SMS codes send a one-time code by text, and the user types it back. Authenticator apps generate a time-based code on the user's device, and the user types it back. Passkeys replace the code entirely with a cryptographic credential stored on the user's device and unlocked by biometrics. SMS is the most familiar and the weakest: the code travels over the phone network, it can be intercepted by SIM swap, and it is the target of SMS pumping, where attackers use the verification form to send premium-rate messages and collect the revenue. Authenticator apps are stronger because the code never travels over the network, but they require the user to install an app. Passkeys are the strongest, because there is no code to intercept and no password to steal, but they require a device and a browser that support them. The right choice is not the strongest method. It is the strongest method the store's actual users will complete.
SMS codes: familiar, abused, and expensive
SMS verification is the default because every phone receives texts, and the user does not need to install anything. The abuse is well documented. SMS pumping turns a verification form into someone else's revenue: attackers submit premium-rate numbers, or numbers in high-cost destinations, and collect a share of the termination fee for every message the store sends. The store pays the carrier, the attacker collects, and the verification form becomes a money printer. The second abuse is the SIM swap: an attacker who convinces a carrier to move the victim's number to a new SIM receives the verification codes, and the account is theirs.
The cost is the other problem. SMS costs per message, and a verification flow that sends a code on every signup, every login from a new device, and every password reset is paying carrier rates on volume that grows with the user base. The code itself is a six-digit number with a short expiry, usually 5 to 10 minutes, and a limited number of attempts, usually 3 to 5, before the code is invalidated. A store that does not limit attempts is running a brute-force oracle: an attacker who can guess the code by trying all million combinations will eventually succeed, and the only defence is the attempt limit.
Related reading on this site: Home and Fake Account Signups: How Stores Spot and Stop Them cover the neighbouring problems in more depth.
Authenticator apps: stronger, with a setup cost
Authenticator apps generate a time-based one-time password, a TOTP, on the user's device, usually changing every 30 seconds. The code never travels over the network, so there is nothing to intercept, and the setup is a shared secret exchanged once, usually by QR code, that both sides use to generate the same code. The user needs an app, Google Authenticator, Authy, or a password manager with TOTP support, and the setup takes a minute the first time. After that, the verification is a code the user reads off their own device, and the attacker who does not have the device cannot generate it.
The failure mode is the recovery path. A user who loses their phone loses their authenticator, and the recovery flow, usually an email link or a support ticket, becomes the weakest link in the chain. A store that offers authenticator apps must also offer a secure recovery method, and the recovery method must be at least as strong as the authenticator, or the attacker will use the recovery path instead. Backup codes, stored securely by the user at setup, are the standard answer, and they should be single-use and clearly labelled.
Passkeys: the end of the code
Passkeys replace the code with a cryptographic credential. The user's device generates a key pair, keeps the private key on the device, and registers the public key with the store. At login, the store sends a challenge, the device signs it with the private key, and the user approves with a fingerprint or face scan. There is no code to intercept, no password to steal, and no shared secret to phish, because the credential is bound to the store's domain and will not work on a lookalike site. The phishing resistance is the point: a passkey cannot be tricked into signing for the wrong site.
The adoption problem is real. Passkeys require a device and a browser that support them, and the user has to understand what is happening well enough to complete the setup. The practical path is progressive: offer passkeys as an option for users who want them, keep SMS or authenticator as the fallback, and let the user's choice be stored as a preference. A store that forces passkeys on every user will lose the ones whose devices do not support them, and a store that never offers them will keep paying SMS rates and absorbing SIM-swap fraud. The middle path is the one that ships.
Frequently asked questions
What is SMS pumping?
SMS pumping is abuse of a verification form to send premium-rate messages. Attackers submit premium-rate or high-cost destination numbers, and collect a share of the termination fee for every message the store sends. The store pays the carrier and the attacker collects.
Are authenticator apps safer than SMS codes?
Yes, because the code never travels over the network. A time-based code is generated on the user's device from a shared secret exchanged once at setup, so there is nothing to intercept. The trade-off is that the user must install an app and the recovery path must be secure.
What is a passkey?
A cryptographic credential stored on the user's device and unlocked by biometrics. At login the device signs a challenge with its private key, and there is no code to intercept and no password to steal. Passkeys are phishing resistant because the credential is bound to the store's domain.
Should a store force passkeys on all users?
No. Passkeys require a device and browser that support them, and forcing them will lose users whose devices do not. Offer passkeys as an option, keep SMS or authenticator as the fallback, and let the user's choice be stored as a preference.