How to Choose a Passwordless Vendor

Every identity vendor now says "we support passkeys." That is a feature claim. What you are buying is an outcome: a high share of real sign-ins completed without a password, at a cost that does not punish growth.

The gap between those two things is where most vendor selections go wrong. A checkbox on a feature grid tells you a passkey can be created. It does not tell you whether customers will be offered one at the right moment, whether they can recover when they lose a phone, or what the bill looks like at 500,000 users. This chapter gives you the questions, the scorecard, and the build vs buy line I use to close that gap. Chapter 10 applies them to eight named vendors.

Start with the outcome you are buying

Write down three numbers before you talk to any vendor. Those numbers become the yardstick for every demo.

1. Target passkey share of successful sign-ins in 12 months. Chapter 4 explains why this beats enrollment as a measure.
2. Target first-attempt sign-in success rate. The October 2026 FIDO Passkey Index reports 93% for passkeys against 78% for passwords and traditional MFA.
3. Your user count in 12, 24, and 36 months. Pricing models diverge sharply as you grow, so model the curve, not today's number.

If a vendor cannot show you how its product moves the first two numbers, it is selling you a feature. I wrote more about why enrollment flatters every dashboard in the passkey success rate vs enrollment gap.

Ten questions to ask every vendor

Ask each question in the demo, not in a questionnaire. A sales engineer answering live tells you more than a polished RFP response. For each question, here is what a good answer sounds like and what should worry you.

1. Is passwordless the default path, or an add-on?

Can a user sign up and sign in with no password ever created?

• Good answer: "Yes. Here is a sign-up flow that creates the account with a passkey or an email code, and no password field exists anywhere."
• Red flag: Passwordless works only after the user first creates a password, or the vendor needs a custom build to hide the password field.

2. Does it support passkey autofill and conditional create out of the box?

Passkey autofill (conditional UI, where the browser offers a saved passkey inside the username field) and conditional create (the browser quietly offers to create a passkey after a password sign-in) drive most organic adoption. The web.dev passkey checklist and Chrome's conditional create guide explain both.

• Good answer: A live demo of autofill on web and on native iOS and Android, plus a clear statement of which browsers get conditional create today.
• Red flag: "It is on the roadmap," or autofill works only in the hosted page and not in your own UI.

3. What enrollment prompts ship by default?

Post-login, post-reset, and post-cross-device prompts should be configurable without code.

• Good answer: A settings screen where you choose when to prompt, how often to re-prompt after a "not now," and which copy to show.
• Red flag: Enrollment exists only on a profile settings page that users never visit.

4. How does recovery work when a user loses every device?

Ask for the exact flow, step by step, and who can override it. Chapter 7 covers why recovery is now the front door attackers use.

• Good answer: Two pre-registered recovery methods, a cool-down period for high-value accounts, notifications on every recovery event, and audited support overrides.
• Red flag: "The user resets via email link" with nothing else, or support agents can reset factors without any verification step.

5. Is risk-based step-up built in?

Can you require a fresh passkey check for named actions such as changing an email or adding a payee? This is how the friction map in Chapter 8 becomes real policy.

• Good answer: Step-up is an API call or policy rule tied to an action, with a configurable freshness window (for example, "authenticated within the last five minutes").
• Red flag: Step-up means "send another SMS code," or it requires a full re-login.

6. Which fallbacks are available, and can you turn SMS off?

You need fallbacks. You also need control over which ones exist.

• Good answer: Each method can be enabled per flow. SMS can be restricted to recovery only, or disabled entirely.
• Red flag: SMS is always on as a fallback for sign-in, and you cannot remove it without a support ticket.

7. What passkey analytics do you get?

You will manage what you can see. The minimum set is enrollment rate, passkey share of sign-ins, and failure reasons by platform.

• Good answer: A dashboard or event stream that breaks passkey outcomes down by operating system, browser, and failure reason, exportable to your own warehouse.
• Red flag: Total logins per day, with no split by method, or analytics as a paid add-on you cannot trial.

8. How is pricing counted?

Monthly active users, monthly retained users, verifications, or connections all count the same customers differently. Model your own growth curve. The same 500,000 users can produce very different bills across vendors.

• Good answer: A published pricing page, a clear definition of what counts as an active user, and a written quote for your 36-month forecast.
• Red flag: Passkeys or MFA sit on a tier far above where your volume lands, or overage pricing appears only after you sign.

9. Can you leave?

Ask how users, passkey public keys, and sessions export, and how long a migration takes. Passkeys are bound to a relying party ID (the domain the credential belongs to). If your domain stays the same, exported public keys can move with you.

• Good answer: Self-service export of user records and credential metadata via API or dashboard, a documented grace period after cancellation, and passkeys registered against your own domain.
• Red flag: Passkeys are registered against the vendor's domain, so leaving forces every customer to enroll again.

10. Who owns the company, and where is it headed?

Acquisitions change roadmaps and pricing. Stytch, for example, became a Twilio subsidiary after a deal announced on October 30, 2025 and closed on November 14, 2025. The CIAM graveyard lists the vendors that did not survive at all.

• Good answer: Clear ownership, a public changelog with steady releases, and contract terms that cap renewal increases.
• Red flag: Vague answers about funding or ownership, or no renewal price protection in the contract.

Match the vendor type to your situation

Vendor categories blur at the edges, but they still predict fit better than feature grids do. Start from your situation, then shortlist the type.

Your situation	Vendor type to shortlist
New consumer app, want passwordless from day one	Passwordless-first CIAM API
Mid-market or enterprise B2C with complex policies and compliance	Full-platform CIAM
React or Next.js product team that wants drop-in UI	Developer-first auth with prebuilt components
Already on a CIAM, passkey adoption is stuck	Passkey adoption and analytics layer on top of your existing stack
Data residency or no per-user fees required	Open-source, self-hosted
Already standardized on a cloud provider	That provider's customer identity service

Two situations need a word of caution. If many non-engineering teams must change login journeys every week, ask each shortlisted vendor to show how a product manager edits a flow without a deploy. If you sell to both consumers and businesses, weight organizations, enterprise SSO, and SCIM provisioning higher than this chapter's default weights do.

The CIAM Compass vendor selector runs a version of this matching against the 50 vendor profiles in the directory.

A weighted evaluation scorecard you can copy

Score every vendor on the same sheet after the proof of concept, not after the sales demo. Score each criterion from 1 (poor) to 5 (excellent), multiply by the weight, and add the results. The weights below are my working defaults for a consumer brand. Adjust them, but agree on them before the first demo so nobody tunes weights to favor a vendor they already like.

#	Criterion	What to check	Weight	Score (1-5)	Weighted
1	Passwordless as default	Sign-up with no password ever created	15%
2	Passkey UX	Autofill, conditional create, native mobile	15%
3	Enrollment prompts	Configurable moments and re-prompt rules	10%
4	Recovery	Full device loss flow, support controls	10%
5	Step-up and risk	Action-bound step-up, risk signals	10%
6	Fallback control	Per-flow methods, SMS restriction	5%
7	Analytics	Method split, failure reasons, export	10%
8	Pricing at 36 months	Your forecast, your user definition	10%
9	Portability	Export, relying party on your domain	5%
10	Vendor durability	Ownership, roadmap, contract terms	5%
11	Compliance and residency	Certifications and regions you need	5%
	Total		100%

To compute the result: weighted score = weight × score. A perfect vendor scores 5.00. In my experience, anything under 3.5 on this sheet produces a rollout that stalls below the passkey share you wrote down at the start.

Build vs buy

Passkeys look simple in a demo. The WebAuthn ceremony itself is a few hundred lines of code. Production means cross-device flows, stale credentials, recovery, analytics, and constant browser and operating system changes.

My rule: buy the commodity, own the product. Buy the authentication layer. Own the experience design and the risk policy, because those are what make your login yours. I argued the longer version in build vs buy auth is the wrong question.

Cost checklist for building in-house

Before anyone argues for building, put a number against each line. Most teams underestimate the recurring rows, not the first build.

• Initial engineering: WebAuthn registration and sign-in on web, iOS, and Android
• Passkey autofill and conditional create on every supported browser
• Cross-device sign-in and its edge cases
• Recovery flows, including full device loss and support tooling
• Step-up policy engine tied to sensitive actions
• Fallback methods: email codes, magic links, and their deliverability
• Bot and abuse protection on sign-up and sign-in
• Analytics: method split, failure reasons by platform
• Security review, penetration testing, and audit evidence for each release
• On-call coverage for an outage that locks out every customer at once
• Ongoing maintenance as browsers and operating systems change passkey behavior
• Opportunity cost: the product features that engineering time would have shipped

Cost checklist for buying

Buying has costs too. Put numbers here as well.

• License at your 12, 24, and 36-month user forecast
• Tier jumps needed for passkeys, MFA, SSO, or analytics
• Integration engineering and UI customization
• Migration of existing users and password hashes
• Exit cost: export effort and any forced re-enrollment
• Vendor management, security review, and contract renewals

The CIAM Compass TCO calculator and build vs buy tool give you a starting model. Replace their defaults with your own salaries and forecast.

Key takeaways

• Buy an outcome, not a feature: passkey share of sign-ins and first-attempt success are the numbers that matter.
• Ask the ten questions live, and judge the answers against the good-answer and red-flag patterns above.
• Agree on scorecard weights before the first demo, and let must-have failures disqualify a vendor outright.
• Buy the authentication layer, own the experience design and risk policy.
• Model pricing on your 36-month forecast using each vendor's own definition of an active user.