Passkeys (WebAuthn) on a SaaS signup form: should you drop the password?

On a free-trial landing page, the signup form is the exact spot where the promise has to turn into an active account. Two fields too many, a password forced through arbitrary complexity rules, and a meaningful share of visitors close the tab — a pattern already documented in our article on form abandonment. The passkey (the consumer-facing implementation of the WebAuthn standard) promises to remove the password field outright: the user confirms with their fingerprint, face, or device unlock code, and a cryptographic key pair takes over. Appealing on paper. What the usability studies conducted since 2020 actually show is more nuanced: passkeys cut friction in specific contexts, and add it back in others when the implementation is rushed.

What a passkey actually changes in the form

Technically, a passkey isn't a password stored differently: it's a key pair generated on the user's device (phone, laptop, security key). The private key never leaves the device; only the public key is transmitted and stored by your application. At sign-in, the device signs a challenge with the private key after a local check (biometric or PIN), and the server validates the signature against the public key. The direct consequence for your form: no password field, no complexity rules to display, no password-reset email flow to design — and nothing for the user to remember. It's a structural change to the form, not a convenience layer bolted on top of an existing password.

What the usability studies show — and it's not an automatic win

The first large lab study comparing password authentication with passwordless FIDO2 keys, run by Lyastani, Schilling, Neumayr, Backes and Bugiel (IEEE Symposium on Security and Privacy, 2020), put participants through both methods across realistic usage scenarios. The finding: passwordless authentication is perceived as broadly usable once enrollment is complete, but the authors flag specific friction points — an enrollment phase that is often poorly understood, recovery errors when the registered device isn't available, and user trust that depends heavily on how clear the on-screen messaging is. A passkey isn't inherently simpler than a password already handled by an installed manager; it only becomes simpler when enrollment and error paths are well designed.

A second study, by Farke, Lorenz, Schnitzler, Markert and Dürmuth (USENIX SOUPS, 2020), goes further by testing real-world adoption over four weeks among employees of a small company, free to keep using their usual password or switch to a newly offered FIDO2 security key. The finding is blunt: a good share of participants went back to their password manager, judged faster day-to-day, having never really understood what the switch bought them. The lesson for a SaaS landing page is direct: offering a passkey isn't enough — you need to explain in one sentence why it's worth the detour, or the option simply gets ignored.

What recent rollouts add to the picture

Beyond controlled studies, real-world rollout reports published in 2024–2025 confirm this same wear pattern: according to data reported by Corbado, a signup flow with no explanation of the passkey shows an average 38% abandonment rate at the enrollment step, versus 14% once a single sentence of context is added on screen. This isn't a controlled scientific study, but it's a magnitude consistent with the enrollment friction identified by Lyastani and coauthors: the problem is almost never the technology — it's the missing explanation at the exact moment the user has to decide.

When it makes sense on a SaaS landing page — and when it doesn't

• Free-trial signup form that creates an account — relevant: the user will come back to sign in repeatedly, so the friction reduction compounds across sessions. See our comparison of free trial vs. freemium.
• Waitlist landing page — not useful: a single email address is enough to capture a lead, no account exists yet. No point adding WebAuthn to a waitlist landing page that only asks for an email.
• B2B demo request form — also not useful: the visitor isn't creating an account at this stage. See our structure for a demo request form that qualifies without discouraging.
• B2B app used on a shared or IT-managed work computer — worth testing first: some corporate device fleets block biometric sensors or enforce their own security keys, which can add friction instead of removing it.

Implementing it without rebuilding your entire auth backend

On a Next.js landing page, it's rarely worth implementing raw WebAuthn yourself — handling the edge cases (lost device, unsupported browser, cross-device sync) is exactly what made the in-house rollouts observed by Farke and coauthors fail. Common authentication providers in the Next.js ecosystem (Auth.js, Clerk, Supabase Auth) now expose a ready-made passkey provider, alongside Google or email/password sign-in. Three things to check before switching:

• The domain must be served over HTTPS (WebAuthn requires it) — already the case on a standard Vercel deployment.
• The enrollment screen needs one visible sentence of explanation, not just a "Create a passkey" button — that's exactly the change that took abandonment from 38% to 14% in the field data cited above.
• A recovery path must exist for a user who switches devices or loses access to theirs — at minimum a backup email, before considering multi-device sync handled by OS-level password managers.

Never remove the fallback

The costliest mistake seen in real rollouts isn't offering the passkey — it's making it mandatory too soon. Older browsers and operating systems, work computers without an activated biometric sensor, and users switching devices mid-journey are still common: forcing the passkey with no fallback recreates exactly the friction it was meant to remove, with visitors now stuck at signup. The setup that holds up over time offers the passkey as a highlighted option, with email/password or a magic link still available underneath — the same principle as required vs. optional form fields: highlight the fastest path, don't remove the others.

A real win on privacy and security

Contrary to a common assumption, a passkey never sends biometric data to your server: the fingerprint or face scan only unlocks the private key locally on the device, which never leaves it. Your database only stores a public key, useless on its own to impersonate an account — unlike a password hash, which remains a target for offline attacks if leaked. For a landing page that already collects personal data through its form (see our guide on GDPR consent in a form), that's a real security argument to make — as long as you don't oversell it: the sensitive data stays on the user's device, it's never something to advertise as a headline feature.

Common mistakes

• Adding a passkey to a form that doesn't create an account (waitlist, demo request) — added complexity for zero benefit.
• Offering the button with no line of explanation — exactly what nearly triples enrollment abandonment according to the field data cited above.
• Removing the password or magic-link fallback — recreates the exact friction the passkey was meant to solve, for unsupported devices or browsers.
• Providing no recovery path — a user who loses their one registered device gets locked out of their own account with no way back.
• Presenting biometrics as sent to the server — factually wrong, and can needlessly worry a privacy-conscious visitor, the opposite of the intended effect.

A passkey isn't a trendy authentication gadget: it's a real friction win on a SaaS signup form, provided it's introduced with a clear explanation and a fallback that's always available — the two points where under-prepared rollouts fail quietly. On a SaaS waitlist template or any free-trial signup form built with the LanderKit templates (€89 per template, €229 for the full pack), the form structure is already set up to receive this kind of auth provider without rebuilding the page — the remaining question is where, in the real signup journey, to add it without forcing the choice.