Is passwordless always more secure than passwords?

No. Passwordless is a category, not a guarantee. Magic links and one-time codes remove the reused-password problem but are still phishable and depend on the security of email or SMS. Only passkeys, built on WebAuthn and FIDO2, are phishing-resistant by design, because the credential is cryptographically bound to the site and never leaves the device. Choose the method by threat model, not by the label.

What is the difference between magic links, OTP, and passkeys?

Magic links email a one-time sign-in URL. One-time passcodes (OTP) send a short code by email, SMS, or an authenticator app. Both are passwordless but phishable and channel-dependent. Passkeys are WebAuthn credentials stored on a device or in a synced keychain, released by a biometric check or a PIN, and are phishing-resistant because they only work on the domain they were created for.

How should a company roll out passwordless authentication?

Add passkey enrollment alongside existing login without forcing it, and measure voluntary adoption. After a few months, default new accounts to passkeys. Then prompt existing users to enroll at sign-in, and finally demote passwords to a recovery-only role or remove them. A phased rollout avoids lockouts and support overload.

What is the hardest part of going passwordless?

Account recovery. A passwordless system with a weak recovery path just moves the attack to recovery, and a passwordless system with no recovery path locks users out when they lose a device. Plan for lost devices, platform migration, delegated access, and a recovery flow that is itself resistant to phishing before you remove passwords.

What fallback should passwordless authentication use without creating lockouts?

Use a ladder: a second passkey or security key first, then a verified email or authenticator code with step-up checks, then assisted recovery with identity verification for high-value accounts. Each rung should be weaker only where the account is worth less. Prompting users to add a second passkey at enrollment is the cheapest way to cut lockout tickets.

Do synced passkeys meet NIST requirements?

For most uses, yes. NIST SP 800-63B-4, final in July 2025, allows syncable authenticators at AAL2 provided access to the keys in the sync fabric is protected by AAL2-equivalent MFA. They are not allowed at AAL3, which needs non-exportable keys, so admins and regulated high-assurance flows should use device-bound passkeys or hardware security keys.

Passwordless: a strategy that survives reality

A passwordless strategy is a plan for replacing passwords with methods matched to each user population's threat model, rolled out in phases, with a recovery path as strong as the sign-in it protects. The verdict for 2026: make passkeys the default, keep magic links and one-time codes only as fallbacks for low-value accounts, and design recovery before you remove a single password.

"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 are passwordless. Only the last is also phishing-resistant, because a passkey is a 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.

What changed in 2025-2026

WebAuthn Level 3 is final. It became a W3C Recommendation on 25 August 2026, with no substantive changes since its May 2026 Candidate Recommendation Snapshot.
NIST accepts synced passkeys at AAL2. SP 800-63B-4 (final July 2025) says syncable authenticators may support AAL2 if "user access to authentication keys in the sync fabric SHALL be protected by AAL2-equivalent MFA", and that they "SHALL NOT be used at AAL3." It also requires AAL2 verifiers to offer at least one phishing-resistant option. See synced passkey and AAL.
Passkey portability is half done. The FIDO Alliance approved the Credential Exchange Format (CXF) 1.0 as a Proposed Standard in August 2025, while the Credential Exchange Protocol (CXP) that moves credentials between providers was still under development as of 1Password's October 2025 update. Plan for platform migration as a recovery case, not a solved problem.

Compare methods by threat model

Method	Phishing-resistant	Main weakness	Best fit
Magic link	No	Email account takeover, link forwarding	Low-value consumer accounts
SMS OTP	No	Relay to phishing pages, SIM swap	Temporary fallback only
Email OTP	No	Same as magic link, plus relay	Fallback, onboarding verification
Authenticator app (TOTP)	No	Code relay, seed sync to a cloud account	Legacy apps without WebAuthn
Synced passkey	Yes	Security of the sync account	Consumers and general staff (AAL2)
Device-bound passkey	Yes	Lost device without a backup	High-value staff, regulated flows
FIDO2 security key	Yes	Cost and logistics	Admins and high-risk roles (AAL3)

How this maps to populations:

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, for example from Yubico, no exceptions. This is the population attackers target first.

Implementation order

Add passkey enrollment alongside existing flows. Do not force it. Measure adoption and failure rates.
After a few months of voluntary adoption (a planning estimate, not a benchmark), default new accounts to passkeys. For onboarding, verify the email or phone once, then offer the passkey on the same screen.
Prompt existing password users to enroll a passkey at sign-in, using conditional UI so it feels like autofill.
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. Our read of the Passkey Index 2026 covers what adoption numbers to manage. The deeper mechanics are in the passwordless authentication implementation guide and, for staff, the implementing passkeys in the 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

A fallback ladder that keeps both lockouts and tickets down:

Second authenticator. Prompt for a second passkey or a hardware key at enrollment, so a lost device is an inconvenience rather than a lockout.
Verified channel plus step-up. An email or authenticator code, combined with device and risk signals, for routine recovery on lower-value accounts.
Assisted recovery with proofing. Identity proofing or a manager-verified workflow for admins and high-value accounts, with every new credential logged and alerted.

Revoke existing sessions and notify the user whenever a new credential is added through recovery.

Failure modes to design against

SMS recovery as the weak door. At Coinbase, attackers abused a flaw in SMS account recovery to obtain the codes needed to take over accounts.
Codes relayed in real time. The 0ktapus campaign and the Twilio SMS phishing attack captured credentials and codes on fake login pages; see OTP relay and AiTM phishing.
Synced secrets without protection. At Retool, authenticator seeds synced to a Google account meant one account compromise exposed the codes. The same logic is why NIST requires MFA on the passkey sync fabric.
Attackers adding their own methods. In the Microsoft 365 token replay campaign, the actor wiped and replaced victims' MFA methods. Alert on every authenticator change.
The session after sign-in. Passkeys protect the login, not the cookie. The CircleCI intrusion used a stolen 2FA-backed session; see session cookie theft and device-bound session credentials.

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. Customer-facing options include Stytch (acquired by Twilio, closed November 2025), Descope, Corbado and open-source Hanko; on the workforce side, Microsoft Entra and Okta both support passkeys; Okta's Passkeys (FIDO2 WebAuthn) authenticator also lets admins block synced passkeys org-wide when policy requires device-bound keys. Compare providers in the best passwordless CIAM providers ranking, the top passwordless authentication platforms article and the MFA matrix. The goal is not "no passwords." The goal is authentication that is both stronger and easier than the passwords it replaces.