# Passwordless: a strategy that survives reality

Source: https://startwithidentity.com/guides/authentication/passwordless-strategy/
Last updated: 2026-07-16
License: content by Start with Identity. Cite the source URL.

---

"Passwordless" is a marketing word that covers very different security postures. A strategy that survives contact with real users starts by being precise about which passwordless you mean, and matching it to the threat you actually face.

## The honest framing

Magic links are passwordless. One-time codes are passwordless. [Passkeys](https://startwithidentity.com/guides/fundamentals/what-is-passwordless/) are passwordless. Only the last is also phishing-resistant, because a passkey is a [WebAuthn/FIDO2](https://startwithidentity.com/standards/webauthn-fido2/) credential bound to the origin it was created for, so it cannot be replayed against a lookalike domain. Magic links and codes remove the reused-password risk but still send a bearer secret through a channel an attacker can intercept or a user can be tricked into forwarding. Pick the method for the threat model, not for the word on the pricing page.

## Choose by threat model

- **Consumer apps, low value:** Magic links or OTP. Low friction, acceptable security when the account protects little of worth.
- **Consumer apps, high value (financial, health, social):** Passkeys with an email or OTP fallback, so the strong path is the default and the fallback is the exception.
- **Workforce, general population:** Passkeys, plus an authenticator app for legacy applications that cannot yet consume WebAuthn.
- **Workforce, admins and high-risk roles:** FIDO2 hardware security keys, no exceptions. This is the population attackers target first.

## Implementation order

1. Add passkey enrollment alongside existing flows. Do not force it. Measure adoption and failure rates.
2. After a few months of voluntary adoption, default new accounts to passkeys.
3. Prompt existing password users to enroll a passkey at sign-in, using conditional UI so it feels like autofill.
4. Demote passwords to a recovery-only role, or remove them, once passkey coverage is high.

Track enrollment rate, passkey sign-in success rate, and support tickets per thousand sign-ins at each step. If success rate drops or tickets spike, hold the phase until you understand why. The deeper mechanics are in the [passwordless authentication implementation guide](https://startwithidentity.com/guides/authentication/passwordless-authentication-implementation-guide/) and, for staff, the [implementing passkeys in the enterprise](https://startwithidentity.com/guides/authentication/implementing-passkeys-enterprise/) guide.

## Recovery is the hard part

Passwordless without a credible recovery story will lock users out, and passwordless with a weak recovery story just moves the attack to recovery. Plan for:

- Lost device with no backup authenticator enrolled
- Device and platform migration, for example Android to iOS, where synced passkeys may not follow
- Family member, assistant, or delegated access without shared credentials
- A recovery flow that is itself resistant to phishing, rather than a "click this email link" bypass of everything you just built

Encourage users to enroll a second passkey or a hardware key up front, so a lost device is an inconvenience rather than a lockout.

## Vendor requirements

When you evaluate platforms, insist on WebAuthn support for both platform and roaming authenticators, conditional UI for browser autofill, account recovery that supports multiple methods, and telemetry that surfaces failed-authentication patterns. Compare providers in the [best passwordless CIAM providers](https://startwithidentity.com/rankings/best-passwordless-ciam-providers/) ranking and the [top passwordless authentication platforms](https://startwithidentity.com/articles/top-7-passwordless-authentication-platforms/) article. The goal is not "no passwords." The goal is authentication that is both stronger and easier than the passwords it replaces.