"No password to leak" is the pitch. Here's what's actually happening under the hood, and where the trust genuinely moves to instead.
Passwordless authentication doesn't remove the need to prove who someone is: it changes what they prove it with. Instead of a secret the user chose and your database has to store and protect, sign-in relies on something they already control: their email inbox, their phone, or a cryptographic key tied to their device. We built this into AskQuote's own sign-in (every account is OTP-only, no password field exists), so this is written from actually shipping it, not just reading the spec.
The two approaches in real use today work quite differently. One-time codes and magic links generate a short-lived secret server-side, deliver it over a channel the user already controls (email or SMS), and treat successful delivery-plus-entry as proof of identity. It's simple to implement, works on any device with no special hardware, and the trust anchor is whatever secures that inbox or phone number, which for most users is itself protected by a password or a phone unlock.
Passkeys (built on the WebAuthn standard) work differently: the device generates a public/private key pair during registration, keeps the private key in secure hardware that never leaves it, and signs a challenge from the server on every sign-in. Nothing secret is ever transmitted or stored on the server: there's no shared secret to phish, intercept, or leak from a breach, because the server only ever holds a public key. The trade is a more involved setup flow and dependence on device/platform support.
Passwords fail in specific, well-documented ways: people reuse them across services, so one breached database compromises accounts everywhere else the same password was used; weak passwords fall to brute-force and dictionary attacks; and phishing pages harvest them directly. Passwordless sign-in eliminates all three at once, because there's no reusable secret for an attacker to steal, guess, or phish in the same way.
It doesn't eliminate risk, it relocates it. OTP and magic-link flows are only as strong as the delivery channel: email account takeover or SIM-swap attacks against SMS delivery become the new target, not the old password. And passwordless doesn't remove the need for account recovery; if someone loses access to their email or phone, you still need a secondary path back into their account, the same problem password-based systems solve with "forgot password" flows. The failure mode moves, it doesn't disappear.
You want the simplest possible implementation that works identically on every device with no special support required.
Sign-ins are infrequent enough that a short email/SMS wait is an acceptable trade for never managing password resets.
Your users already trust and check the email address or phone number tied to their account.
Users sign in frequently enough that a near-instant, no-code-entry flow meaningfully improves the experience.
Your user base skews toward modern devices and browsers with solid WebAuthn support.
You want the strongest available protection against phishing, alongside, not instead of, a fallback method.
It removes the risks tied to passwords specifically: reuse, weak choices, credential-stuffing attacks against a database of hashes. It doesn't remove risk entirely: OTP and magic links shift trust to the user's email or phone account, so the real question becomes how well-secured that channel is.
You need an account-recovery path regardless: passwordless doesn't remove that requirement, it just moves where it lives. Most products fall back to a secondary verified channel or manual support-assisted recovery, the same as password-based systems need for forgotten passwords.
Not yet, for most products. Passkeys need explicit device/platform support and a slightly more involved setup step, so many teams offer OTP as the default with passkeys as a faster option for returning users on supported devices, rather than passkeys-only.
The first sign-in is usually slower, waiting on an email or SMS to arrive. Every sign-in after that is typically faster than recalling and typing a password, especially for infrequent users who'd otherwise trigger a password reset anyway.
Usually yes: OTP/magic-link sign-in can be added alongside an existing password system as an option, or as the primary method for new accounts, without migrating existing users' credentials on day one.
Secrets in binaries, tokens in the wrong storage, APIs that trust the app: the gaps behind most real mobile breaches, closed in order.
Read the guideFree HTTP caching and a simple mental model, or one flexible query per screen: what each API style actually costs you.
Read the guide