# Passkeys vs Passwords for SaaS: What Should an Indie Maker Ship?

> Passkeys vs passwords for SaaS, compared by security, device support, recovery, rollout effort, and the best path for an indie maker to ship.

- Canonical: https://zeroraised.com/blog/passkeys-vs-passwords-for-saas
- Published: 2026-10-18
- Updated: 2026-10-18
- Author: ZeroRaised Team (https://zeroraised.com/blog/authors/zeroraised)
- Publisher: ZeroRaised (https://zeroraised.com/)
- Section: Growth
- Tags: saas, passkeys, authentication

In the **passkeys vs passwords** decision for SaaS, most indie makers should ship passkeys as an option before making them the only sign-in method. Passkeys give users a site-bound public-key credential instead of a reusable shared secret, but the product still needs a tested fallback or recovery route, secure sessions, and server-side authorization ([W3C Web Authentication](https://www.w3.org/TR/webauthn-3/) and [NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html), checked 18 Oct 2026).

**Disclosure:** [ZeroRaised](https://zeroraised.com/) publishes this guide for makers building products without institutional VC or accelerator equity. This article makes no claim about audience size, traffic, conversions, or launch outcomes.

## TL;DR

| Shipping path | Choose it when | Main benefit | Main risk to test | First launch gate |
|---|---|---|---|---|
| Passkeys as an option | You already have password or federated sign-in and can add enrollment from an authenticated account | Users can adopt a phishing-resistant sign-in method without an immediate migration | People may misunderstand where the passkey is stored or continue using the fallback | Enroll, use, name, inspect, and remove a passkey on the actual device mix |
| Passkey-first with recovery | Your users have compatible devices and credential managers, and you can support cross-device sign-in | The primary flow avoids a reusable password | Device loss, credential-provider boundaries, and recovery can become the real account-security boundary | Complete new-account, returning-device, new-device, lost-device, and recovery tests |
| Improved passwords | Your audience or platform constraints make passkeys impractical for the first release | Broad familiarity and a simpler initial support script | Phishing, reuse, reset abuse, storage errors, and weak MFA remain | Meet current password, rate-limit, MFA, reset, and session requirements |

This table is a ZeroRaised editorial decision framework. The security properties come from the [W3C WebAuthn specification](https://www.w3.org/TR/webauthn-3/), current password guidance comes from [NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html), and the need to treat authentication, sessions, and authorization separately follows [OWASP's Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html), [Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html), and [Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html) guidance, all checked 18 Oct 2026.

## What a password and a passkey actually prove

A password is a memorized secret presented to a verifier. A properly built service stores a salted password hash rather than plaintext and compares a derived value at sign-in; OWASP currently recommends Argon2id as its first choice when available and gives separate guidance for scrypt, bcrypt, and PBKDF2 under their stated constraints ([OWASP Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html), checked 18 Oct 2026).

A passkey is a discoverable WebAuthn public-key credential. During registration, an authenticator creates a key pair scoped to the relying party. The service stores the public key while the authenticator retains control of the private key. During authentication, the service sends a fresh challenge, the authenticator signs it after the required user interaction, and the server verifies the signed response ([W3C WebAuthn introduction](https://www.w3.org/TR/webauthn-3/#sctn-intro) and [OWASP Passkey Security](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html), checked 18 Oct 2026).

The face scan, fingerprint, device PIN, or security-key PIN is a local step used by the authenticator. The service receives the public-key credential and authentication response, not the user's biometric template. A passkey does not require biometrics because a PIN or another authenticator-supported local method can perform user verification ([FIDO Alliance, How Passkeys Work](https://fidoalliance.org/how-fido-works/) and [GitHub, About passkeys](https://docs.github.com/en/authentication/authenticating-with-a-passkey/about-passkeys), checked 18 Oct 2026).

That distinction changes the breach and phishing questions. A password can be entered on an impostor site, and a password database can expose hashes that attackers try to crack. A correctly verified WebAuthn credential is scoped to its relying party, and the service stores a public key rather than a reusable shared secret ([W3C WebAuthn relying-party scope](https://www.w3.org/TR/webauthn-3/#sctn-rp-benefits), [NIST phishing resistance](https://pages.nist.gov/800-63-4/sp800-63b.html#phishres), and [FIDO Alliance, How Passkeys Work](https://fidoalliance.org/how-fido-works/), checked 18 Oct 2026).

Passkeys do not make the surrounding account safe by themselves. A stolen authenticated session, an unsafe recovery process, an account-binding error, or a broken authorization check can still give the wrong person access. OWASP explicitly lists those limits and tells relying parties to apply separate authentication, session, and transaction controls around WebAuthn ([OWASP Passkey Security](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html#security-properties-and-limits), checked 18 Oct 2026).

## Recent hook: two opposing Hacker News threads, three days apart

**Dated note, 18 Oct 2026:** Hacker News carried “Passkeys are a trap” on 11 Oct 2026 at 21:59:48 UTC and “Passkeys are not a trap” on 14 Oct 2026 at 15:15:45 UTC. The first thread linked to an argument against passkey adoption, while the second linked to Scott Helme's response. Read the [11 Oct Hacker News thread](https://news.ycombinator.com/item?id=50048312) and its [Algolia record](https://hn.algolia.com/api/v1/items/50048312), then the [14 Oct Hacker News thread](https://news.ycombinator.com/item?id=50088935) and its [Algolia record](https://hn.algolia.com/api/v1/items/50088935), all checked 18 Oct 2026.

The disagreement centers substantially on control, portability, and attestation. The first source article argues that the attestation features around passkeys could enable restrictive platform policies; Helme's response argues that ordinary synced passkeys do not supply the kind of attestation described and that returning to passwords plus time-based codes would give up phishing resistance. These are the authors' positions, not measured outcomes and not a reason to treat every SaaS audience alike ([“Passkeys are a trap”](https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-not-use-them) and [Scott Helme, “Passkeys are not a trap”](https://scotthelme.co.uk/passkeys-are-not-a-trap/), checked 18 Oct 2026).

For a maker, the useful response is to convert the dispute into product questions. Which authenticators will you accept? Will you request attestation? Can users add more than one credential? What happens across Apple, Google, Windows, Linux, and third-party credential-manager boundaries? What recovery proof will the service accept? OWASP advises most public-facing applications to use no attestation, support more than one authenticator, and treat credential management and recovery with the same care as sign-in ([OWASP Passkey Security](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html), checked 18 Oct 2026).

## Passkeys vs passwords for SaaS: the practical comparison

“Better” depends on the decision. A passkey has a stronger answer to ordinary credential phishing; a password has a more familiar manual fallback. A synced passkey adds portability within its provider ecosystem; a device-bound passkey gives up that sync ([NIST phishing resistance](https://pages.nist.gov/800-63-4/sp800-63b.html#phishres) and [GitHub passkey authenticators](https://docs.github.com/en/authentication/authenticating-with-a-passkey/about-passkeys#about-authenticators), checked 18 Oct 2026).

| Decision area | Password | Synced passkey | Device-bound passkey | What the maker must decide | Primary source |
|---|---|---|---|---|---|
| Server credential | Salted password hash when implemented correctly | Public key and credential metadata | Public key and credential metadata | Whether the auth provider or your team owns storage and verification | [OWASP Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) and [W3C WebAuthn](https://www.w3.org/TR/webauthn-3/), checked 18 Oct 2026 |
| Phishing resistance | The password can be presented to the wrong verifier | Credential is scoped to the relying party | Credential is scoped to the relying party | Whether every fallback preserves the intended assurance | [NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html#phishres) and [W3C RP benefits](https://www.w3.org/TR/webauthn-3/#sctn-rp-benefits), checked 18 Oct 2026 |
| User action | Type, paste, or autofill a secret, then complete MFA if required | Approve with the credential manager and configured local verification | Use the enrolled device or portable security key and configured local verification | What copy and support instructions users need | [NIST password requirements](https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver) and [FIDO passkey flow](https://fidoalliance.org/how-fido-works/), checked 18 Oct 2026 |
| Portability | A password manager can sync or export according to its own features | Credential provider synchronizes across supported devices in its ecosystem | Credential stays on one authenticator | Whether cross-device use and provider boundaries fit the audience | [Google passkey use cases](https://developers.google.com/identity/passkeys/use-cases) and [GitHub passkey authenticators](https://docs.github.com/en/authentication/authenticating-with-a-passkey/about-passkeys#about-authenticators), checked 18 Oct 2026 |
| Device loss | Password remains usable if the user remembers it or retains the manager | Provider account recovery may restore access to synchronized credentials | Another enrolled authenticator or service recovery is required | Whether users may enroll multiple methods before loss occurs | [GitHub, Managing passkeys](https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys) and [OWASP Passkey Security](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html), checked 18 Oct 2026 |
| Service breach | Weak storage or weak user passwords can permit offline guessing | Stolen public keys do not provide the private keys | Stolen public keys do not provide the private keys | How sessions, recovery records, and credential metadata are protected | [OWASP Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html) and [FIDO passkey design](https://fidoalliance.org/how-fido-works/), checked 18 Oct 2026 |
| Domain dependence | A password can be reused after a domain change if the service keeps the same account database | RP ID and allowed origins determine where the credential works | RP ID and allowed origins determine where the credential works | Whether a domain or auth-host migration is expected | [W3C RP ID definition](https://www.w3.org/TR/webauthn-3/#relying-party-identifier) and [Clerk domain restrictions](https://clerk.com/docs/guides/development/custom-flows/authentication/passkeys#domain-restrictions-for-passkeys), checked 18 Oct 2026 |
| Recovery risk | Password reset can become a weaker alternate sign-in | Service recovery can become a weaker alternate sign-in | Service recovery can become a weaker alternate sign-in | What proof is enough to regain or change account access | [OWASP Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) and [OWASP Passkey recovery guidance](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html), checked 18 Oct 2026 |

## Start with the user and device mix

Before choosing a path, write a small authentication profile. This is ZeroRaised editorial advice, not a browser-coverage claim:

1. List the operating systems, browsers, native apps, embedded webviews, shared computers, and managed devices that intended users actually bring.
2. Record whether the same person commonly moves between work and personal devices or between different credential-provider ecosystems.
3. Identify accounts that are shared today and replace shared access with named users and roles where the product permits it.
4. Mark users who cannot install extensions, enable device security, carry a phone, or use a hardware authenticator.
5. Decide which account actions require recent authentication and which support cases can justify recovery.

Do not turn generic WebAuthn availability into a claim that your flow works everywhere. MDN marks the Web Authentication API as broadly available but also warns that some parts vary in support. It exposes capability checks such as `isConditionalMediationAvailable()` and `isUserVerifyingPlatformAuthenticatorAvailable()`, which are inputs to progressive enhancement rather than substitutes for a real test matrix ([MDN Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API) and [MDN PublicKeyCredential](https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential), checked 18 Oct 2026).

Cross-device authentication deserves its own test. Google's current developer guide explains that a passkey synchronized through Google Password Manager is available on supported devices using the same Google account, while the same credential is not automatically present in another platform ecosystem. It documents a nearby-phone flow in which the user scans a QR code and the devices use Bluetooth proximity before the phone approves the sign-in ([Google passkey use cases](https://developers.google.com/identity/passkeys/use-cases#sign-in-with-a-phone), checked 18 Oct 2026).

That flow may be perfectly reasonable for a phone-carrying consumer and unacceptable for a user on a locked-down office workstation. Test it with the network rules, camera access, Bluetooth policy, and device ownership patterns of the intended audience. This recommendation is an inference from Google's stated flow, not a claim that every managed environment blocks it.

## Synced and device-bound passkeys are different product promises

A synced passkey is backed up and made available through a credential provider's supported ecosystem. A device-bound passkey remains with one authenticator; a FIDO2 hardware security key is a portable physical example even though its credential does not synchronize. GitHub documents both forms and tells users that some providers offer a choice while others do not ([GitHub, About authenticators](https://docs.github.com/en/authentication/authenticating-with-a-passkey/about-passkeys#about-authenticators), checked 18 Oct 2026).

Apple says passkeys in iCloud Keychain are end-to-end encrypted and can synchronize across a person's Apple devices. Google separately documents the boundary of its synchronized ecosystem and the nearby-device route for crossing operating systems ([Apple Passkeys](https://developer.apple.com/passkeys/) and [Google passkey use cases](https://developers.google.com/identity/passkeys/use-cases#sign-in-with-a-phone), checked 18 Oct 2026).

Your settings page should therefore describe credentials, not just show a green “enabled” badge. Give each passkey a user-visible name, creation time, last-used time when the provider exposes it, and a remove action. Allow more than one passkey unless a documented product or policy constraint forbids it. GitHub labels synchronized passkeys in account settings, while Supabase and Clerk document list, rename, and delete operations for enrolled passkeys ([GitHub, Managing passkeys](https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys), [Supabase passkey management](https://supabase.com/docs/guides/auth/passkeys#manage-passkeys), and [Clerk passkey management](https://clerk.com/docs/guides/development/custom-flows/authentication/passkeys), checked 18 Oct 2026).

Do not promise that a credential is backed up merely because registration succeeded. WebAuthn can return backup-eligibility and backup-state information, but OWASP warns against exposing those values as proof that a provider or device is trustworthy. Use them as protocol metadata according to the maintained library's guidance, not as a customer-facing guarantee ([OWASP Passkey Security](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html#verify-the-registration-response), checked 18 Oct 2026).

## Choose one of three shipping paths

The following paths are product recommendations for a small SaaS, not a ranking of identity vendors. Pick the narrowest path that your team can test and support.

### Path 1: add passkeys as an option

This is the safest default for an existing SaaS and often the best first release for a new product whose user environment is uncertain. Keep the current maintained sign-in route, let a recently authenticated user add a passkey from account security settings, and offer it on the next sign-in. Google recommends passkey autofill within a username and password form when an application is transitioning and still has users without passkeys ([Google passkey use cases](https://developers.google.com/identity/passkeys/use-cases#passkey-autofill-suggestions-in-form-fields), checked 18 Oct 2026).

The word “optional” must not mean “unowned.” Add credential management, notifications, support copy, and outcome events before promoting enrollment. Do not collect biometric data or private-key material; those are not supplied to the relying party in the normal design ([FIDO Alliance, How Passkeys Work](https://fidoalliance.org/how-fido-works/), checked 18 Oct 2026).

Auth0 is a real example of coexistence. Its current database-connection documentation says passkeys and passwords can appear in the same login experience and that password sign-in remains available while the connection allows it. Auth0 also documents prerequisites and policy controls, so enabling a switch should not be mistaken for completing product testing ([Auth0 Passkey Authentication](https://auth0.com/docs/authenticate/database-connections/passkeys) and [Auth0 passkey policy](https://auth0.com/docs/authenticate/database-connections/passkeys/configure-passkey-policy), checked 18 Oct 2026).

Move toward passkey-first only after the successful cohort includes the device and browser combinations that matter, support can distinguish cancellation from technical failure, and recovery has been exercised end to end. Those promotion gates are ZeroRaised editorial advice.

### Path 2: make passkeys primary, with a recovery route

Passkey-first means the sign-in screen first offers a passkey account selector or button, not that every other access route disappears. Google's guide recommends the dedicated passkey button only when the relying party is certain its users have passkeys; otherwise it recommends a combined form with passkey autofill and another method ([Google passkey use cases](https://developers.google.com/identity/passkeys/use-cases#sign-in-with-a-passkey-button), checked 18 Oct 2026).

For a new account, bind the credential to the verified account-creation transaction. For an existing account, require recent authentication before enrollment. OWASP treats adding a passkey as a sensitive change and says the server should bind registration to its authenticated session and intended account, not a client-supplied account identifier ([OWASP secure passkey registration](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html#establish-an-authorized-account-context), checked 18 Oct 2026).

Before making this the default, pass these product gates:

- A new user can create an account and one passkey, recognize where it was stored, and reach the first useful product action.
- A returning user can sign in on the original device and on a supported second device.
- A user with multiple accounts can choose the intended account without exposing another person's account on a shared device.
- A user can add a second authenticator, identify each credential, remove one, and still sign in.
- A user who loses the original device can follow the documented provider or service recovery route.
- A support operator can explain the route without asking for a password, one-time code, or private material in a ticket.

These gates are ZeroRaised editorial acceptance criteria. Their protocol basis is W3C's separate registration and authentication ceremonies and OWASP's guidance to support multiple authenticators and secure the whole credential lifecycle ([W3C WebAuthn](https://www.w3.org/TR/webauthn-3/#sctn-intro) and [OWASP Passkey Security](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html), checked 18 Oct 2026).

### Path 3: retain passwords and improve them

Keeping passwords can be the responsible first release when intended users rely on unsupported or constrained clients, when the auth provider's passkey implementation is immature for your stack, or when you cannot yet operate safe recovery and credential management. That is a sequencing decision, not a claim that passwords match passkeys against phishing.

If you keep passwords, follow the current standard rather than inherited folklore. NIST requires at least 15 characters for a password used as a single factor, permits a lower minimum of eight when the password is part of MFA, recommends allowing at least 64 characters, rejects arbitrary composition rules, rejects routine forced changes, requires checking new passwords against a blocklist, requires rate limiting, and says verifiers must allow password managers, autofill, and paste ([NIST password requirements](https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver), checked 18 Oct 2026).

Store passwords with a purpose-built password-hashing function and a unique salt. OWASP currently places Argon2id first, provides a scrypt alternative when Argon2id is unavailable, retains bcrypt mainly for legacy use, and documents PBKDF2 where FIPS validation is required. Tune the work factor to your own infrastructure and abuse model rather than copying a number without testing ([OWASP Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html), checked 18 Oct 2026).

Add MFA that fits the risk and audience, but describe its properties accurately. NIST states that passwords, out-of-band methods, and manually entered OTP methods are not phishing-resistant. A TOTP app still improves a password-only flow against several attack classes, but it does not acquire WebAuthn's verifier binding merely because two factors are present ([NIST authenticator types](https://pages.nist.gov/800-63-4/sp800-63b.html#authenticators) and [NIST phishing resistance](https://pages.nist.gov/800-63-4/sp800-63b.html#phishres), checked 18 Oct 2026).

Keep account identifiers stable, choose an auth provider that can attach another credential later, and avoid UI text that equates “account” with “password.” These are editorial design recommendations for a later migration.

## Design recovery before promoting enrollment

Recovery is an alternate authentication route. If a passkey account can be taken over through a weak email link or an improvised support exception, the primary credential's phishing resistance does not protect that route. OWASP says recovery deserves the same care as authentication and recommends multiple authenticators so the loss of one does not force a weak bypass ([OWASP Passkey Security](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html) and [OWASP Multifactor Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html#resetting-mfa), checked 18 Oct 2026).

Separate three cases in the support script:

| Case | What may still work | Safe product response | Do not assume |
|---|---|---|---|
| Original device lost, synced provider retained | The credential provider may restore synchronized passkeys on another supported device | Direct the user to the provider's documented recovery, then let normal sign-in decide | That every passkey was synchronized |
| Device-bound authenticator lost, second authenticator retained | Another enrolled passkey can authenticate | Let the user sign in with the second credential, require recent authentication, then remove the lost one | That possession of the account email proves control |
| All authenticators unavailable | Only the service's explicit recovery method remains | Apply the documented proof, delay, review, notification, and session-revocation policy appropriate to the account | That a support agent should attach a new credential manually |

The distinctions follow GitHub's documentation of synchronized and device-bound recovery and OWASP's lifecycle guidance; the response column is ZeroRaised editorial advice ([GitHub, Recovering a passkey](https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys#recovering-a-passkey) and [OWASP Passkey Security](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html), checked 18 Oct 2026).

GitHub provides a useful named product example. It lets an account owner add passkeys, use them for sign-in and sensitive “sudo mode,” and manage them in password and authentication settings. Its documentation tells users that a synchronized passkey can be recovered through the passkey provider, while a lost device-bound credential requires another route ([GitHub, Authenticating with a passkey](https://docs.github.com/en/authentication/authenticating-with-a-passkey) and [GitHub, Managing passkeys](https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys), checked 18 Oct 2026).

Notify the account through an already verified channel when a passkey is added, renamed, or removed, and when recovery changes the credential set. Do not include sensitive credential data in the message. Revoke or review existing sessions according to the event and your threat model. These are editorial controls supported by OWASP's instruction to audit credential association changes and protect the surrounding session lifecycle ([OWASP Passkey Security](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html) and [OWASP Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html), checked 18 Oct 2026).

## Keep authentication, sessions, and authorization separate

Authentication proves control of a credential and connects the request to an identity. Session management carries that authenticated state across later requests. Authorization decides whether the identity may perform a particular action on a particular object. Changing the first layer does not implement the other two ([OWASP Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html), [OWASP Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html), and [OWASP Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html), checked 18 Oct 2026).

After a successful passkey assertion, issue the same carefully protected application session you would issue after another accepted method. OWASP notes that a session token becomes temporarily equivalent to the authentication that created it. Protect cookies, rotate session identifiers at authentication and privilege changes, enforce expiry, implement logout, and provide revocation appropriate to the application ([OWASP Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html), checked 18 Oct 2026).

Then authorize every protected operation on the server. A passkey sign-in does not prove that a user may view another tenant's invoice, change a workspace owner, export all records, or call an administrator endpoint. OWASP recommends deny-by-default behavior, permission checks on every request, and tests for the chosen access-control model ([OWASP Authorization](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html), checked 18 Oct 2026).

Use recent authentication for high-impact account changes. Adding or deleting passkeys, changing recovery contact details, transferring ownership, and disabling MFA deserve a fresh check based on the action's consequence. OWASP specifically recommends reauthentication after risk events and before sensitive changes, and its passkey guide says a long-lived session cookie alone is insufficient for adding a passkey ([OWASP Authentication](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html#reauthentication-after-risk-events) and [OWASP passkey registration](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html#establish-an-authorized-account-context), checked 18 Oct 2026).

## Implement WebAuthn as a server protocol, not a button

The browser prompt is only the visible middle of a registration or authentication ceremony. Google's server-side guide says registration begins with server-generated options, continues through the client authenticator, and ends when the server validates the returned credential and stores the public key. Authentication similarly requires the server to validate the credential and signature before creating access ([Google passkey developer guide](https://developers.google.com/identity/passkeys/developer-guides) and [Google server registration](https://developers.google.com/identity/passkeys/developer-guides/server-registration), checked 18 Oct 2026).

Use a maintained WebAuthn server library or a maintained identity provider. OWASP specifically warns against writing your own CBOR parsing, COSE handling, attestation validation, or assertion verification. The application still owns the expected RP ID and origin allowlist, challenge lifecycle, account binding, user-verification policy, and credential-management workflow ([OWASP, Use a maintained library](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html#use-a-maintained-library), checked 18 Oct 2026).

For registration, the server should generate a fresh challenge, bind it to the ceremony and intended account, expire it, and accept it once. OWASP points to the WebAuthn minimum of 16 random bytes and lists the response checks that a relying party library must perform, including challenge, origin, RP ID hash, user-presence and user-verification flags, algorithm, credential structure, and attestation when policy requires it ([OWASP registration options](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html#generate-and-bind-registration-options) and [W3C registration verification](https://www.w3.org/TR/webauthn-3/#sctn-registering-a-new-credential), checked 18 Oct 2026).

For authentication, decide whether user verification is required and verify the returned flag rather than assuming that a device capability was used. OWASP distinguishes user presence from user verification, and Google's server guide likewise tells relying parties that require verification to check the `uv` flag in authenticator data ([OWASP security model](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html#components-and-terms) and [Google server authentication](https://developers.google.com/identity/passkeys/developer-guides/server-authentication), checked 18 Oct 2026).

Choose the RP ID before production enrollment. It determines the credential's scope and is difficult to change without asking users to enroll again. OWASP recommends the narrowest stable domain that covers the intended application and an explicit origin allowlist. Clerk's documentation gives a concrete vendor example: credentials do not cross unrelated domains, and its satellite-domain model needs special consideration ([OWASP, Choose the RP ID carefully](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html#choose-the-rp-id-carefully) and [Clerk domain restrictions](https://clerk.com/docs/guides/development/custom-flows/authentication/passkeys#domain-restrictions-for-passkeys), checked 18 Oct 2026).

## Roll out progressively

A small team should make the product policy reversible. You should be able to stop enrollment prompts, return the previous method to primary position, and investigate failures without stranding existing passkey users.

Use four stages:

1. **Internal exercise:** Enroll several authenticator types, test credential management, and deliberately fail challenges, origins, and user-verification requirements.
2. **Opt-in release:** Offer passkeys in account settings to a bounded group and keep the current sign-in route visible.
3. **Contextual promotion:** Suggest enrollment after a successful sign-in or from security settings, with copy that names the benefit and recovery route.
4. **Primary presentation:** Put passkeys first only for users or environments where the application has evidence that the credential is available, while retaining the approved alternate path.

The sequence is ZeroRaised editorial advice. It aligns with FIDO's description of enrollment after an existing sign-in, Google's combined-form transition pattern, and OWASP's requirement for recently authenticated account context ([FIDO Alliance, How Passkeys Work](https://fidoalliance.org/how-fido-works/), [Google passkey autofill](https://developers.google.com/identity/passkeys/use-cases#passkey-autofill-suggestions-in-form-fields), and [OWASP passkey registration](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html#establish-an-authorized-account-context), checked 18 Oct 2026).

Instrument outcomes, not impressions. Separate “prompt shown,” “ceremony started,” “user cancelled,” “platform reported an error,” “server rejected the response,” “credential stored,” and “session issued.” A single “passkey failed” event cannot tell you whether the problem is copy, device choice, client support, challenge state, origin configuration, or server verification. This event model is editorial advice based on the distinct protocol stages documented by Supabase and Google ([Supabase passkey ceremony](https://supabase.com/docs/guides/auth/passkeys) and [Google passkey developer guide](https://developers.google.com/identity/passkeys/developer-guides), checked 18 Oct 2026).

Do not use another company's conversion case study as your forecast. Measure completion by supported client, repeat sign-in success, fallback selection, recoveries, support contacts, and lockouts in your own product.

## Test the complete account lifecycle before launch

The broader [product launch checklist](https://zeroraised.com/blog/product-launch-checklist-for-bootstrapped-makers) covers production readiness. Use the [vibe coded app security checklist](https://zeroraised.com/blog/vibe-coded-app-security-checklist) to test the surrounding authorization, session, secret, and recovery controls. For authentication, run the matrix below against the production domain or an environment with the same RP ID and origin behavior.

| Test | Pass condition | Failure to force |
|---|---|---|
| New registration | Credential attaches only to the intended verified account and appears in settings | Reuse an expired challenge; alter account context; cancel the client prompt |
| Returning sign-in | Correct assertion creates the intended session and wrong origin or challenge is rejected | Replay a response; use an unknown credential; require UV and return no UV |
| Multiple credentials | User can add a second authenticator, identify both, remove either one, and retain access with the other | Remove the currently used credential; attempt a duplicate enrollment |
| Cross-device use | Supported nearby-device or synchronized-provider route completes with understandable instructions | Disable Bluetooth, deny camera access, or use a different provider ecosystem |
| Recovery | Each documented case produces the intended proof, notifications, session response, and credential state | Lose a device-bound credential; lose provider access; start recovery from an unknown device |
| Sensitive changes | Adding or removing a credential and changing recovery data require the chosen recent-authentication policy | Try each action with a stale session and from another tenant role |
| Password fallback | Password policy, throttling, MFA, reset, and account-enumeration behavior meet the chosen standard | Try a blocked password, repeated failures, expired reset token, and reused token |
| Logout and revocation | The intended session ends and revoked credentials or sessions no longer authorize protected requests | Reuse the prior cookie or token after logout and after account recovery |

The checks synthesize the [W3C registration and authentication procedures](https://www.w3.org/TR/webauthn-3/#sctn-rp-operations), [OWASP Passkey Security](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html), [OWASP Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html), and [OWASP Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html), all checked 18 Oct 2026. The pass conditions are release criteria, not a claim that this table replaces a security review.

Ask an intended user to explain where the passkey was saved, how another device works, what remains after losing the current device, and how to remove the credential. Repair the copy or flow when the answer differs from actual behavior.

## Common mistakes in the passkeys vs passwords decision

| Mistake | Why it fails | Current reference |
|---|---|---|
| Requiring passkeys after one laptop test | WebAuthn capabilities vary, and the product still needs its intended synchronized, device-bound, nearby-device, managed-device, and accessibility cases | [MDN Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API), checked 18 Oct 2026 |
| Calling every biometric sign-in a passkey | Local biometrics can approve several kinds of local access; passkey authentication still requires a verified WebAuthn ceremony | [FIDO Alliance, How Passkeys Work](https://fidoalliance.org/how-fido-works/), checked 18 Oct 2026 |
| Hiding an email bypass | Recovery becomes part of the account's effective assurance and must be protected, communicated, and tested | [OWASP Forgot Password](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html) and [OWASP Passkey Security](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html), checked 18 Oct 2026 |
| Treating a passkey as a session | A successful assertion authenticates; the application must still protect, expire, and revoke sessions | [OWASP Session Management](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html), checked 18 Oct 2026 |
| Requesting attestation without a requirement | Public-facing applications usually need no authenticator-model restriction, while a justified enterprise policy needs defined trust and failure handling | [OWASP, Minimize attestation](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html#minimize-attestation), checked 18 Oct 2026 |
| Rebuilding verification from fragments | The server must validate origin, challenge, RP ID, flags, algorithms, keys, and applicable policy data | [W3C relying-party operations](https://www.w3.org/TR/webauthn-3/#sctn-rp-operations) and [OWASP library guidance](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html#use-a-maintained-library), checked 18 Oct 2026 |
| Preserving old password folklore | Composition puzzles and scheduled changes conflict with current guidance | [NIST password requirements](https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver), checked 18 Oct 2026 |

## The launch decision

Choose **passkeys as an option** when you can enroll from a recently authenticated account, maintain the current route, and observe real device behavior. This is the default recommendation for most indie SaaS launches because it captures the phishing-resistance benefit without making first access depend on an unproven recovery model.

Choose **passkey-first with recovery** when the intended clients are known, the account and cross-device flows have passed, users can register more than one appropriate authenticator, and support has a written recovery policy. Make the fallback honest and proportionate to the account's risk.

Choose **improved passwords** when client constraints or implementation readiness block a responsible passkey release. Follow current NIST and OWASP guidance, add appropriate MFA, and preserve a credential model that can accept passkeys later ([NIST SP 800-63B](https://pages.nist.gov/800-63-4/sp800-63b.html) and [OWASP Password Storage](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html), checked 18 Oct 2026).

Whichever route you choose, write five sentences before launch: what the primary credential is, where it can be used, how a second device works, how access is recovered, and what happens to existing sessions after recovery. If the team cannot answer those questions consistently, the flow is not ready for strangers.

Once the authentication path works from account creation through recovery, use the [bootstrapped app launch guide](https://zeroraised.com/blog/how-to-launch-a-bootstrapped-app) for the broader release sequence. Makers building without institutional VC or accelerator equity can also review [ZeroRaised](https://zeroraised.com/), browse [maker perks](https://zeroraised.com/perks), and [submit a launch for free](https://zeroraised.com/submit) when the public product page and current submission terms fit.

## Sources

- [W3C Web Authentication Level 3](https://www.w3.org/TR/webauthn-3/), checked 18 Oct 2026
- [NIST SP 800-63B, Authentication and Authenticator Management](https://pages.nist.gov/800-63-4/sp800-63b.html), checked 18 Oct 2026
- [FIDO Alliance, How Passkeys Work](https://fidoalliance.org/how-fido-works/), checked 18 Oct 2026
- [OWASP Passkey Security Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Passkey_Security_Cheat_Sheet.html), checked 18 Oct 2026
- [OWASP Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html), checked 18 Oct 2026
- [OWASP Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html), checked 18 Oct 2026
- [OWASP Session Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html), checked 18 Oct 2026
- [OWASP Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html), checked 18 Oct 2026
- [OWASP Forgot Password Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Forgot_Password_Cheat_Sheet.html), checked 18 Oct 2026
- [OWASP Multifactor Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Multifactor_Authentication_Cheat_Sheet.html), checked 18 Oct 2026
- [Google Passkeys developer guides](https://developers.google.com/identity/passkeys/developer-guides), checked 18 Oct 2026
- [Google server-side passkey registration](https://developers.google.com/identity/passkeys/developer-guides/server-registration), checked 18 Oct 2026
- [Google server-side passkey authentication](https://developers.google.com/identity/passkeys/developer-guides/server-authentication), checked 18 Oct 2026
- [Google Passkeys use cases](https://developers.google.com/identity/passkeys/use-cases), checked 18 Oct 2026
- [Apple Passkeys](https://developer.apple.com/passkeys/), checked 18 Oct 2026
- [MDN Web Authentication API](https://developer.mozilla.org/en-US/docs/Web/API/Web_Authentication_API), checked 18 Oct 2026
- [MDN PublicKeyCredential](https://developer.mozilla.org/en-US/docs/Web/API/PublicKeyCredential), checked 18 Oct 2026
- [GitHub, Authenticating with a passkey](https://docs.github.com/en/authentication/authenticating-with-a-passkey), checked 18 Oct 2026
- [GitHub, About passkeys](https://docs.github.com/en/authentication/authenticating-with-a-passkey/about-passkeys), checked 18 Oct 2026
- [GitHub, Managing your passkeys](https://docs.github.com/en/authentication/authenticating-with-a-passkey/managing-your-passkeys), checked 18 Oct 2026
- [Auth0 Passkey Authentication](https://auth0.com/docs/authenticate/database-connections/passkeys), checked 18 Oct 2026
- [Auth0 passkey policy](https://auth0.com/docs/authenticate/database-connections/passkeys/configure-passkey-policy), checked 18 Oct 2026
- [Supabase Passkey Authentication](https://supabase.com/docs/guides/auth/passkeys), checked 18 Oct 2026
- [Clerk custom passkey flow](https://clerk.com/docs/guides/development/custom-flows/authentication/passkeys), checked 18 Oct 2026
- [Hacker News, “Passkeys are a trap”](https://news.ycombinator.com/item?id=50048312), checked 18 Oct 2026
- [Algolia record for “Passkeys are a trap”](https://hn.algolia.com/api/v1/items/50048312), checked 18 Oct 2026
- [“Passkeys are a trap” source article](https://nonfunctional.substack.com/p/passkeys-are-a-trap-do-not-use-them), checked 18 Oct 2026
- [Hacker News, “Passkeys are not a trap”](https://news.ycombinator.com/item?id=50088935), checked 18 Oct 2026
- [Algolia record for “Passkeys are not a trap”](https://hn.algolia.com/api/v1/items/50088935), checked 18 Oct 2026
- [Scott Helme, “Passkeys are not a trap”](https://scotthelme.co.uk/passkeys-are-not-a-trap/), checked 18 Oct 2026

## Frequently asked questions

### Are passkeys safer than passwords for a SaaS product?

Passkeys resist ordinary credential phishing and do not give the service a reusable shared secret. The complete account can still be weakened by an unsafe recovery path, poor session handling, or broken authorization.

### Should a new SaaS require passkeys at launch?

Usually only after testing the intended users' devices, credential managers, cross-device flow, and recovery path. Offering passkeys alongside a maintained fallback is the lower-risk first release for many small teams.

### Can passkeys and passwords exist on the same account?

Yes. A product can let an existing signed-in user enroll one or more passkeys while retaining password sign-in during a measured migration.

### What happens when a user loses a device with a passkey?

A synced passkey may be restored through its credential provider, while a device-bound passkey requires another enrolled authenticator or the service's recovery process. Test both cases before broad release.

### Do passkeys replace sessions and authorization?

No. Passkeys authenticate a user at sign-in. The application still has to issue and protect sessions, expire or revoke them as designed, and authorize every protected action on the server.