Choose passkeys as the preferred sign-in method for returning users, then keep a deliberately designed recovery path. Email OTP is a practical bootstrap for low-risk products. Passwords still fit users who need a familiar, portable credential, but they bring phishing, credential-stuffing, storage, and reset work with them.

That is the short answer. The right production setup depends on what a compromised account can do, which devices your users share, and how you will recover an account when its strongest authenticator is unavailable.

The risk and UX matrix

Method	Phishing resistance	Returning-user friction	Recovery dependency	Main operational burden	Good default for
Password	No	Medium	Email or support	Hashing, breach checks, resets, stuffing defence	Broad compatibility when passkeys are not viable
Email OTP	No	Medium to high	The same email inbox	Delivery, resend rules, abuse controls, email availability	Bootstrap, low-risk consumer apps, verified waitlists
Passkey	Yes, when WebAuthn is correctly configured	Low after enrolment	Another passkey or a separate recovery method	Enrolment, RP ID stability, device and recovery UX	Returning users, admins, and higher-risk actions

NIST is explicit on the important distinction: passwords are not phishing-resistant, and an authenticator that asks a person to manually enter an OTP is not phishing-resistant because an attacker can relay the value. WebAuthn achieves phishing resistance by binding a credential to the verifier's domain.

The matrix is not a leaderboard. A passkey with a weak recovery process can still lead to account takeover. Email OTP may be entirely reasonable for a low-risk newsletter tool. A password plus phishing-resistant MFA may fit a workforce application better than password-only or email-only access.

Passwords trade familiarity for a shared secret

A password works almost everywhere. It does not depend on a particular inbox being available at sign-in, and users understand the interaction. Those advantages explain why passwords remain useful.

The cost is that your service verifies a reusable secret. Attackers can phish it, guess it online, or replay one exposed by another site. A credible password implementation therefore needs more than a form and a hash:

Hash passwords with a memory-hard password hashing function and unique salts.
Block common and known-compromised passwords without sending the full password to a third party.
Rate-limit by account and network signal, while avoiding an easy account-lockout denial of service.
Use generic responses where a detailed error would reveal whether an account exists.
Provide a secure reset flow and invalidate affected sessions after a confirmed compromise.
Offer phishing-resistant MFA for privileged or high-impact access.

Do not compensate with theatrical password rules. Current NIST password guidance says a single-factor password should be at least 15 characters, recommends supporting at least 64 characters, rejects arbitrary composition rules, and rejects forced periodic changes without evidence of compromise.

If you keep passwords, treat credential stuffing and recovery as core product flows, not later security tasks.

Email OTP removes the password, not phishing

Email OTP lowers initial friction because the user does not create or remember a new secret. It also proves that the person completing the flow can access the inbox at that moment. That makes it useful for onboarding, early-access gates, and products where an email account is already the practical recovery anchor.

But email OTP inherits the security and availability of the mailbox. A compromised inbox becomes a compromised application account. A fake sign-in page can ask for the code and relay it. Delivery can be delayed, and every send endpoint is an opportunity for email bombing and user-enumeration abuse.

A production email OTP flow should:

Generate a short-lived, single-use code.
Invalidate older outstanding codes when a new code is issued.
Limit sends and verification attempts by identity, network signal, and environment.
Return generic browser-safe errors rather than internal counters or raw JSON.
Avoid creating an active user merely because somebody typed an email address.
Keep waitlist verification separate from authentication and account creation.

Email OTP verifies inbox control. It does not verify a person's legal identity, prove that the person owns the address permanently, or become phishing-resistant just because the code expires quickly.

For a waitlist, the safe sequence is request, verify inbox control, create the pending request, then create or activate the application user only after approval and sign-in. The same principles appear in our guide to rate-limiting authentication endpoints.

Passkeys remove the reusable server-side secret

A passkey is a public-key credential. The authenticator keeps the private key; your service stores the public key and verifies a signature over a fresh challenge. There is no password or OTP for a person to type into a look-alike site.

The WebAuthn specification scopes each credential to a relying-party identifier (RP ID). A credential registered for one RP ID cannot authenticate to an unrelated domain. The FIDO Alliance describes passkeys as phishing-resistant credentials with no shared secret.

That security property creates an architectural constraint: your authentication domain is part of the credential. Pick a stable RP ID before broad enrolment. Moving from a generated domain to an unrelated custom domain later may require users to register a new passkey unless you have designed an allowed related-origin migration.

Passkeys also need precise assurance language. Some authenticators require local user verification with a PIN or biometric; others may only prove user presence. Whether a ceremony meets your desired assurance depends on the authenticator and the userVerification policy you enforce. A biometric normally unlocks a device-held key locally; your server does not receive the fingerprint or face template.

The hard part is no longer password reset. It is lifecycle design:

How does a user enrol the first passkey?
Can they register more than one?
What happens on a new or shared device?
How do they recover without turning email into an invisible bypass?
How do you revoke a lost authenticator and notify the user?
Will your RP ID remain stable across Test, Live, and custom domains?

Passkeys improve the front door. They do not absolve you from securing the side door.

Choose by account impact, not fashion

Start with the consequence of takeover.

Low-risk consumer product

Use email OTP for bootstrap, offer a passkey after successful sign-in, and keep email as a clearly labelled fallback. This avoids password creation while giving frequent users a faster, phishing-resistant path.

SaaS application

Prefer passkeys for returning users. Keep either password plus strong MFA or email-based recovery during migration. Require reauthentication before changing authenticators, billing details, or tenant-level settings.

Admin or high-impact account

Require phishing-resistant authentication, preferably a passkey or hardware security key with user verification. Do not let a weaker email-only path silently satisfy the same policy. CISA likewise recommends prioritising phishing-resistant MFA for administrator and privileged accounts.

Shared-device or assisted-access product

Do not assume a synced passkey belongs to only one person or that every user controls a private device. NIST notes that authenticators of several kinds can be shared. Evaluate account switching, local profiles, sign-out visibility, and support-assisted recovery for the actual device model.

Verified waitlist

Use email verification only to establish control of the submitted address. Do not expose password or passkey sign-in to an unapproved applicant, and do not count the pending record as an active application user.

Roll out passkeys without trapping users

A safe migration is gradual:

Measure the current flow. Track successful sign-ins, delivery failures, resets, recovery completion, and account-takeover reports by method.
Offer enrolment after authentication. Do not ask a stranger to create a recovery-critical credential before establishing the account.
Prefer passkeys for enrolled users. Keep "use another method" visible rather than rendering several forms at once.
Register multiple authenticators. Let users add another device or hardware key before they lose the first.
Step up sensitive actions. A remembered session should not automatically authorise a new passkey, email change, or destructive action.
Test recovery as an attack path. Record who initiated it, which checks passed, and which sessions or credentials were revoked.

Browsers intentionally do not reveal a person's passkeys to a website without user interaction. That means an identifier-first flow can narrow the credential request to passkeys registered for the entered account, while a discoverable-credential flow can ask the authenticator to present its account picker. Do not fake automatic detection with an email guess or a local-storage flag.

How NamoID Auth handles the choice

NamoID configures password, email OTP, and passkey availability per environment. When passkeys are enabled, NamoID Auth can present the passkey path first while retaining configured fallbacks. After an identifier is entered, the passkey request can be constrained to credentials registered for that account.

Test and Live environments remain separate, including their authentication policy and passkey scope. Custom domains therefore need deliberate RP ID planning. Waitlist applicants follow a narrower flow: the verification step confirms the request email without exposing password or passkey authentication or turning that pending request into an active user.

The product rule is simple: enable methods because they match your risk and recovery model, not because a settings screen offers a toggle.

Frequently asked questions

Is a passkey always multi-factor authentication?

No. A WebAuthn credential can be single-factor or multi-factor cryptographic authentication depending on the authenticator and whether local user verification is required and performed. Check the returned WebAuthn flags and enforce the policy your risk level requires.

Is email OTP safer than a password?

It removes password reuse and password-storage risk, but it is not categorically safer. Security depends on the inbox, recovery, rate limits, code invalidation, and phishing resistance. Email OTP and passwords solve different operational problems; neither is phishing-resistant.

Password, OTP, or Passkey: Choosing a Sign-In Method