asskeys are WebAuthn/FIDO2 credentials that replace passwords and one-time codes with device-bound public-key cryptography, so nothing phishable is ever typed or transmitted. In 2026 they are displacing SMS OTP for account login, while SMS survives as a fallback and re-verification channel where passkey coverage, account recovery, or cross-device sign-in still fall short.
What a passkey actually is
A passkey is a credential defined by the W3C Web Authentication (WebAuthn) standard and the FIDO Alliance's FIDO2 specifications. When a user enrols, the device generates a public/private key pair: the private key never leaves the authenticator (a phone, laptop, or hardware key) and is unlocked with a local biometric or PIN; the public key is stored by the website. Sign-in is a cryptographic challenge-response, so there is no shared secret to steal, phish, or replay.
There are two flavours. Synced passkeys roam across a user's devices through a platform keychain, which fixes the loss-and-recovery problem that held hardware keys back. Device-bound passkeys stay on a single authenticator and suit the highest-assurance cases. Both are phishing-resistant because the credential is cryptographically scoped to the exact site it was created for — it will not release for a look-alike domain.
Why the industry moved off SMS OTP
SMS one-time passwords have a structural flaw: the secret is a short code a human can be tricked into revealing, and the transport was never designed to be phishing-resistant. Several forces converged to push high-assurance flows away from it.
- NIST SP 800-63-4, finalised in July 2025, classifies SMS one-time passcodes as a restricted authenticator that does not, on its own, meet the bar for phishing-resistant AAL2 authentication.
- The FIDO Alliance positions passkeys as phishing-resistant by design, because the credential cannot be released to a fraudulent origin.
- SIM-swap and OTP-interception fraud let attackers receive codes without the victim's device at all — a threat passkeys structurally remove.
- SMS pumping (Artificially Inflated Traffic) turned every OTP send into a billable attack surface, adding a direct cost incentive to reduce OTP volume.
Passkeys vs SMS OTP, side by side
| Dimension | SMS OTP | Passkey (WebAuthn/FIDO2) |
|---|---|---|
| Secret model | Shared code, human-entered | Private key, never transmitted |
| Phishing resistance | Low — code can be socially engineered | High — origin-bound credential |
| SIM-swap exposure | Vulnerable | Not applicable — no phone-number dependency |
| User friction | Wait for, read, and type a code | One biometric/PIN gesture |
| Reach | Universal — any handset with a signal | Requires an enrolled, capable device |
| Best role | Fallback, recovery, and re-verification | Primary account login |
The trade-off is reach versus resistance. A passkey is stronger but requires the user to have enrolled a capable device and to have it at hand; SMS reaches any phone with a signal but carries the weaknesses above. That difference is exactly why the two coexist rather than one simply erasing the other.
What SMS still does in a passkey world
Removing SMS OTP from primary login does not remove SMS from the stack. Its job shifts from being the credential to supporting the credential's lifecycle and covering the moments passkeys cannot.
- Account recovery — when a user loses every device holding a passkey, a verified phone number is a common, well-understood recovery path back into the account.
- Cross-device bootstrap — confirming a phone number helps establish a new device before a passkey is enrolled on it.
- Fallback for the unenrolled — users who have not yet created a passkey, or are on a borrowed device, still need a working sign-in path.
- Step-up and re-verification — a second signal for a risky action, layered on top of a passkey rather than replacing it.
- Transactional notifications and alerts — delivery updates, fraud alerts, and confirmations that were never authentication in the first place.
BroadNet's OTP and verification stack runs Silent Network Authentication first with automatic SMS fallback, so where you still need a phone-number factor — recovery, bootstrap, or step-up — you get a phishing-resistant network check where operators support it and guaranteed SMS reach everywhere else, from one integration.
How to sequence the migration
Classify flows by assurance need first. Move primary login for sensitive accounts to passkeys, keep a phone-number factor for recovery and unenrolled users, and treat SMS as the lower-assurance role the standards now describe rather than the front door. If you are still designing the phone-number layer, our answer on what OTP is frames the options, number verification explains the network-based alternative to codes, and BroadNet's MyOTP turnkey verification handles the fallback delivery so you can focus on the passkey rollout.
Frequently asked questions
Do passkeys completely replace SMS one-time passwords?
Not entirely. Passkeys replace SMS OTP for primary login, but SMS keeps a role in account recovery, cross-device bootstrap, step-up verification, and reaching users who have not enrolled a passkey. In 2026 the realistic pattern is passkey-first authentication with a phone-number factor retained as a lower-assurance fallback rather than the main credential.
Are passkeys phishing-resistant?
Yes. A passkey is cryptographically bound to the exact origin it was created for, so it will not release its signature to a look-alike or fraudulent domain — the mechanism that makes phishing and man-in-the-middle attacks work is removed. The FIDO Alliance and W3C WebAuthn design passkeys to be phishing-resistant by construction, which SMS OTP is not.
What happens to SMS OTP for account recovery?
It commonly stays. When a user loses all devices holding their passkeys, a pre-verified phone number is a widely used recovery path. The key change is scope: SMS is used to re-establish access under additional checks, not as the everyday login factor, so its exposure to phishing and pumping is confined to a narrow, monitored flow.
Does NIST still allow SMS for authentication?
SMS is permitted but restricted. NIST SP 800-63-4 (finalised July 2025) treats SMS one-time passcodes as a restricted authenticator that does not meet the phishing-resistant AAL2 bar on its own. It can still serve as a lower-assurance or fallback factor, which is precisely the role it retains alongside passkeys.
References
- FIDO Alliance — Passkeys overview: fidoalliance.org
- W3C — Web Authentication (WebAuthn) Level 3: w3.org
- NIST — SP 800-63-4 Digital Identity Guidelines (final, July 2025): csrc.nist.gov
- IETF — RFC 6238, TOTP: Time-Based One-Time Password Algorithm: datatracker.ietf.org