Passkeys for SaaS: A Rollout Plan That Doesn't Lock Users Out

Passkey implementation in an existing SaaS product is an authentication migration: the sign-in button is the easy part, and recovery, account linking, compatibility testing and measured rollout gates decide whether every customer keeps access.

Passkeys replace a shared secret with a key pair: the customer’s device or password manager keeps the private key, your server stores only the public key, and each passkey works only on the domain it was created for. That makes sign-in phishing-resistant, and it moves risk to new places: lost devices, accounts that span several tenants, and the browsers and credential managers your customers actually use.

A safe plan works through six steps in order: define the problem and first cohort, map your authentication system, implement the server checks, design recovery, test the journeys demos skip, then pilot behind a flag and expand on agreed evidence. Start with the identity provider you already run; custom authentication is the exception.

The FIDO Alliance’s Passkey Index 2026, published October 15, 2026, reports that on average 36% of successful sign-ins across its participants used a passkey, against 26% in the 2025 edition. The panel grew from 9 to 15 participating consumer services, so FIDO calls the comparison directional: it describes a larger group, not growth inside the same companies. The same Index found that most participants still had more users enrolled than signing in with a passkey, which is why this plan measures enrollment and usage separately.

What problem are passkeys solving for you?

Passkey implementation starts with a baseline, not a library: how often sign-in fails today, how many recovery requests support handles, what SMS one-time codes cost and how many account takeovers you see. Without those numbers, a pilot cannot show whether passkeys helped.

A useful baseline covers:

• Sign-in success rate by method and platform.
• Recovery volume: password resets, lockouts and support-assisted recoveries.
• Support load: sign-in tickets and handling time.
• SMS cost and delivery failures for one-time codes. In the same Index, every participant that provided savings data reported lower SMS OTP costs.
• Account takeover reports and credential-stuffing attempts.

Pick a first cohort you can observe closely, such as new signups, opted-in customers or a few tenants whose admins agreed to take part, and write its success criteria against your own baseline.

Keep three populations apart. This project covers customer accounts that sign in against your own user store. Users who arrive through their company’s identity provider over SAML or OIDC keep using it, and any passkey they hold lives there. Passkeys for your own staff are a separate workforce identity project. For the controls around sign-in, see our web application security checklist.

Map your authentication system first

Before writing code, inventory where sign-in happens and who owns each piece: your identity provider, web and mobile clients, account identifiers, tenant boundaries, custom domains and SSO connections. Two of those decisions, the relying party ID and the allowed origins, are hard to change once customers have created passkeys, so settle them first.

How WebAuthn registration and sign-in work

WebAuthn is the browser API behind passkeys, now a W3C Recommendation as Web Authentication Level 3 since August 25, 2026. Three parties take part: your server (the relying party), the browser or operating system acting as the client, and the authenticator holding the private key, which can be a device’s built-in platform, a password manager, a phone or a hardware security key.

Both ceremonies follow a challenge-response pattern. Your server issues a random challenge, the authenticator verifies the person locally with a fingerprint, face scan or PIN, and returns a response your server can check. Biometrics are never sent to you: the specification states that biometric data is not revealed to the relying party and is used only locally, a point worth making in your help content.

Registration: a signed-in customer adds a passkey

1. Server: re-verifies the user, then builds the options: challenge, RP ID, user.id, excludeCredentials and residentKey set to required, so the passkey is a discoverable credential.
2. Browser or OS: calls navigator.credentials.create(options).
3. Authenticator: verifies the person locally with a face scan, fingerprint or PIN.
4. Authenticator: creates a key pair scoped to the RP ID; the private key stays with the provider.
5. Browser or OS: returns the credential ID, public key and flags.
6. Server: checks the challenge, origin, RP ID and flags.
7. Server: stores the credential against the account.

Sign-in: a returning customer authenticates

1. Server: builds the options: a fresh challenge, the RP ID and the user verification policy.
2. Browser or OS: calls navigator.credentials.get(options), or offers passkey autofill in the sign-in form through conditional mediation.
3. Authenticator: verifies the person locally.
4. Authenticator: signs the challenge with the private key.
5. Browser or OS: returns the credential ID, signature and user handle.
6. Server: finds the credential, checks the challenge, origin, RP ID and flags, and verifies the signature.
7. Server: discards the challenge and starts the session.

Relying party ID and origins in a multi-tenant product

The relying party ID (RP ID) is the domain a passkey belongs to, and the browser will only use the passkey on that domain or its subdomains. The WebAuthn specification gives the rule by example: for a service at login.example.com, both login.example.com and example.com are valid RP IDs, but m.login.example.com is not.

For most SaaS products, the registrable parent domain is the safer choice, so one passkey works on both app.example.com and auth.example.com. Three situations need a decision before launch:

• Customer custom domains. A passkey created for your domain will not work on app.customer.com by default. Route sign-in through one central authentication domain, or use Related Origin Requests from WebAuthn Level 3, where your RP ID domain publishes the extra origins it accepts. Browsers cap that list by their own policy, so it suits a handful of domains, not one per tenant.
• Native mobile apps. Apps must be tied to the RP ID domain before they can use its passkeys. Apple’s passkey documentation requires an associated domain with the webcredentials service type, and Android’s Credential Manager requires Digital Asset Links between the app and the website.
• Hosted identity providers. A provider often sets the RP ID for you. Amazon Cognito, for example, asks for a relying party ID that is typically your user pool domain.

Changing the RP ID later orphans every passkey already created, so record the decision.

When your identity provider already does the work

If customer sign-in already runs on a managed identity platform, start there. Auth0 supports passkeys for database connections, with a limit of 20 passkeys per user, and Amazon Cognito user pools support WebAuthn passkeys from the Essentials tier upward. Provider features are usually enough when the provider owns the user store, sign-in runs through its hosted pages or SDKs, and your domains fit its RP ID model.

Custom work is justified when you run your own user store, serve tenants on custom domains, or must link passkeys to legacy identifiers and SSO accounts with rules the provider cannot express. Even then, recovery, tenant logic and support tooling usually outweigh the passkey endpoints.

Secure passkey implementation on the server

A secure passkey implementation rests on five server-side checks: a fresh challenge for every attempt, a credential bound to the right account, origin and RP ID verification, signature verification against the stored public key, and a deliberate user verification policy. Use a maintained FIDO server library or your provider’s tooling for them. Google’s server-side guidance puts it plainly: “we recommend that you rely on a library instead.”

As Apple’s passkey security documentation puts it, “The server never learns what the private key is.” A database breach exposes public keys an attacker cannot sign in with, and a look-alike domain cannot ask for a passkey bound to your RP ID. Passkeys are phishing-resistant, not immune: session theft, malware on a device and weak recovery channels still need their own controls, as our look at whether AI can hack your software explains.

1. Challenges. Per Google’s server-side authentication guide, a challenge must be cryptographically secure and at least 16 bytes, generated for every attempt, stored in the user’s session, and discarded after the attempt succeeds or fails. Never accept the same challenge twice.
2. Credential-to-account binding. Store credentials in their own table, keyed by credential ID and linked to the account. Google’s registration guide recommends a random, permanent user ID for passkeys that contains no personal data, and passing existing credential IDs in excludeCredentials so the same provider does not create duplicates. Expect several passkeys per account.
3. Origin and RP ID checks. Reject any response whose origin is not on your explicit allowlist (your web origins, related origins and app origins) or whose RP ID does not match the one you registered.
4. Signature verification. Verify the signature over the authenticator data and client data with the stored public key, and check the user presence and user verification flags your policy requires.
5. User verification policy. Decide whether the device’s screen lock check is required or preferred. If passkeys will replace a password plus a second factor, require it. Cognito makes the same choice explicit: with its MULTI_FACTOR_WITH_USER_VERIFICATION setting, a passkey with user verification satisfies MFA requirements.

Store the backup eligibility and backup state flags with each credential. They show whether a passkey can sync and whether it has, which drives recovery prompts and any later decision to drop passwords.

Enrolling existing accounts safely

Existing customers create passkeys while already signed in, which makes enrollment an attack surface. Google’s passkey deployment checklist on web.dev sets the controls:

• Re-verify first with the strongest method the customer has, so an attacker in a hijacked session cannot add their own passkey.
• Notify after every passkey creation, so the owner learns about one they did not add.
• Provide a management page listing each passkey by provider, showing whether it syncs, with add and remove.
• Prompt at the right moment: after a successful sign-in, and instead of a new password in the forgot-password flow.

A passkey proves the person controls a credential for an account. It does not decide what they can reach. Authorization, tenant isolation, session lifetime and re-authentication for sensitive actions stay in your application code.

Design recovery before launch

Recovery is where a passkey rollout keeps or loses customers’ trust, and it sets your real security level: if a lost passkey can be replaced through a weaker channel, an attacker will use that channel. Decide the recovery paths, threat-model each one and test them end to end before the first customer enrolls.

Consider a hypothetical customer, Dana, an operations manager at a client account, who signs in with a passkey on her phone and loses it. What happens next depends on the type of passkey she created:

• Synced passkeys follow her to a new phone. Apple says passkeys sync through iCloud Keychain and can be recovered through iCloud Keychain escrow even if every device is lost; Google Password Manager also syncs passkeys across platforms.
• Device-bound passkeys, such as those on a hardware security key or in a provider that does not sync, are gone with the device. Dana needs another registered passkey or a recovery path you built.

Your server can tell the difference from the backup eligible and backup state flags; NIST SP 800-63B-4 notes that a passkey which can be synced has not necessarily been synced. Prompt customers who hold only device-bound passkeys to add a second one.

Recovery path	How it works	Main risk	Best fit
Another registered passkey	Sign in with a second passkey, then replace the lost one	Low; needs a prompt at enrollment	Every account
Cross-device sign-in	A phone holding the passkey approves sign-in on a nearby computer	Needs the other device present	Customers with two devices
Provider recovery	The provider restores synced passkeys to a new device	Depends on the provider account’s security	Synced passkeys
Email or SMS recovery link	A verified channel issues a link to re-enroll	Phishable; SIM swap; sets the ceiling	Lower-risk accounts, with limits and alerts
Tenant admin re-enrollment	A customer’s admin resets the user’s sign-in	Relies on the admin account’s security	B2B products with tenant admins
Support-assisted recovery	Support verifies identity with documented checks	Social engineering	Last resort, high-value accounts

The decision tree support and product should agree on, for a customer who cannot sign in with a passkey. Work down it and stop at the first yes:

1. Another registered passkey? Sign in with it, then add a new one.
2. Another device holding the passkey? Use cross-device sign-in with the QR code.
3. Was the passkey synced? Restore it through the provider account.
4. Does the tenant have an admin? The admin starts re-enrollment.
5. A verified recovery channel? Send a link, with step-up verification, an alert to the owner and a cool-off.
6. None of the above? Support runs its documented identity checks.

Assess every fallback against the same questions: who can trigger it, what it takes to complete, whether the owner is alerted, how attempts are rate-limited, and whether a cool-off applies before a new passkey becomes active. A fallback that is easier to pass than the passkey becomes the real front door. Explain one constraint in your help content: Google’s help page tells people to turn on Bluetooth to use a passkey on a phone to sign in to another computer. That proximity requirement applies to cross-device flows, not to passkeys used on the same device or synced ones.

Test the journeys demos miss

A passkey demo works on one laptop; production depends on six parties behaving together. FIDO’s Passkey Central troubleshooting guidance lists them (the relying party, operating systems, browsers, credential managers, hardware and the end user) and says testing all ecosystem combinations is impractical or impossible. Test a matrix weighted by your own traffic, plus the failure journeys demos skip.

Adapt this matrix to your analytics:

Platform	Browser or app	Credential provider	Run
iOS / iPadOS	Safari, Chrome	iCloud Keychain, a third-party manager	Create, sign in, autofill, act as cross-device phone
Android	Chrome, your app	Google Password Manager, a third-party manager	Create, sign in, autofill, act as cross-device phone
macOS	Safari, Chrome	iCloud Keychain, Google Password Manager	Create, sign in, cross-device from a phone
Windows	Chrome, Edge	Windows Hello, Google Password Manager, security key	Create, sign in, cross-device from a phone
ChromeOS, Linux	Chrome	Google Password Manager, security key	Sign in, unsupported fallback

Check combinations against Google’s supported environments page: on Android 14 or higher, for example, Chrome can store passkeys in whichever password manager the customer selects in system settings.

The failure journeys that cause tickets:

• Cancellation. The customer dismisses the prompt; the page recovers without an error loop.
• Unsupported clients. An older browser or restricted environment gets the existing sign-in path, never a dead end.
• Multiple accounts. Two accounts in one provider; the session lands on the one the customer picked.
• Lost devices. Dana’s recovery, run end to end for each path in the table.
• Credential deletion. A passkey removed on your server but still offered by the provider, and the reverse; the web.dev checklist recommends signalUnknownCredential so providers clear stray passkeys.
• Interrupted cross-device flows. QR code scanned with Bluetooth off, or the phone locked mid-flow.
• Enterprise restrictions. Work devices or policies that block access to passkeys, a known issue in Passkey Central’s list.
• Account linking. A customer with both a social login and a password account; the passkey binds to the intended account.
• Tenant switching. One person in several tenants; the passkey authenticates the person, and tenant selection and authorization follow.
• SSO cutover. A tenant switches to SSO-required after its users created passkeys in your product; those passkeys stop being offered for that tenant, users are told before the switch, and a deprovisioned account loses its passkeys.

Automate the server side: WebAuthn Level 3 defines virtual authenticators that let a test suite add credentials, set user verification and remove credentials without hardware. Keep real devices for provider interfaces, autofill and cross-device flows. Our QA and test automation team builds this kind of suite into the release pipeline.

Pilot, measure and expand

Ship passkeys behind a feature flag to a defined cohort, keep every existing sign-in method working, and expand only when criteria agreed before the pilot are met. Enabling passkeys and customers actually signing in with them are different outcomes with different measurements.

Three pieces make the pilot safe:

• Feature flags by cohort or tenant, controlling enrollment prompts and passkey sign-in separately.
• Support guidance: telling synced from device-bound passkeys, the recovery decision tree and macros.
• A non-destructive rollback. Turning the flag off hides passkey prompts and sign-in but keeps stored credentials, so re-enabling needs no re-enrollment. Never delete credentials to roll back; Passkey Central notes that removing passkeys from the relying party can create multiple issues.

FIDO’s rollout guides treat passkeys as an additional sign-in option and offer two strategies: gradual, with lower initial cost and a slower ramp to business benefit, or rapid, the reverse.

Measure from the first day of the pilot:

Metric	What it shows
Enrollment rate	Share of eligible active accounts with at least one passkey
Passkey sign-in share	Share of successful sign-ins that used a passkey
Sign-in success rate	Success by method and platform, against your baseline
Completion time	Time from sign-in start to session, by method
Fallback use	How often a passkey holder signs in another way, and why
Recovery outcomes	Recoveries started, completed and abandoned, by path
Sign-in support tickets	Volume and handling time, against your baseline

In the Passkey Index 2026, 38% of all accounts had a passkey while 36% of successful sign-ins used one, and 8 of 10 participants reporting both still had a sign-in share below their enrollment rate. Two participants said their sign-in flow showed a password or one-time code before offering the passkey, even to users who had one. The fix sits in your sign-in flow: offer the passkey first to customers who have one.

Agree the expansion criteria before the pilot starts and state them against your own baseline: for example, passkey sign-in success at least matching the current method, no unresolved lockouts, and recovery requests the support team can absorb. There is no universal threshold; the numbers come from your product, risk and support capacity.

Release-readiness checklist

This checklist turns the six steps into ten release gates: each line names the decision, its owner and the evidence that closes it. Use it before the pilot and again before each expansion.

Decision	Owner	Evidence required
Baseline, cohort and success criteria	Product lead with engineering lead	Baseline dashboard; cohort definition; written criteria
RP ID and allowed origins	Architect or tech lead	Decision record; map of domains, custom domains and apps
Identity provider or custom build	CTO	Provider capability review against requirements
Server checks and user verification	Backend lead with security engineer	Library choice; tests for challenge reuse, origin mismatch and flags
Enrollment controls	Product lead with security engineer	Re-verification rule; notifications; management page
Recovery paths	Security engineer with support lead	Decision tree; threat review per fallback; end-to-end results
Compatibility	QA lead	Traffic-weighted matrix; failure journeys passed
Flags, rollback and support	Engineering manager with support lead	Flag configuration; rollback rehearsed; support macros
Metrics and expansion gates	Product lead with data analyst	Live dashboards; gates signed off before launch
Identity and security review	Security engineer	Review sign-off on the release

Passkeys support compliance rather than deliver it. NIST SP 800-63B-4 requires verifiers to offer at least one phishing-resistant option at AAL2 and rules out syncable authenticators at AAL3, but whether your product meets a standard depends on the whole system, recovery included.

Where unicrew fits: passkeys in an existing SaaS product

Adding passkeys to a live product is integration work as much as identity work: your provider, user store, tenant model, SSO connections, mobile apps and support tooling change together. Our platform development and integration team takes on that work inside existing products, from the architecture assessment and RP ID decisions through recovery design, the QA matrix and the flagged rollout. Against the release-readiness checklist above, our team produces the evidence for the RP ID decision, the server checks, the recovery paths, the compatibility matrix and the rehearsed rollback, while your product lead, CTO and support lead keep the baseline, the provider decision and the sign-offs.

Authentication products are familiar ground. For a biometric company’s multi-factor authentication platform, which uses 3D facial authentication and machine learning to detect fraudulent behavior among authentication attempts, we re-architected the existing database during a period of rapid customer growth, sharding it so load spread across database nodes. A passkey rollout makes the same kind of change: new authentication data and a new sign-in path inside a product already serving customers. Our cybersecurity consulting team handles security review and remediation around the sign-in flow in your codebase and pipeline.

We hold ISO 27001:2022 and ISO 9001:2015 certifications, audited by Quay Audit UK, and our QA practice includes ISTQB-certified QA engineers. Our SaaS development teams work inside your repository and release process, and most engagements start within two to four weeks.

Planning passkeys for an existing SaaS product? Talk to unicrew about assessing your authentication architecture, integration requirements and rollout plan.

Key takeaways

• Treat passkeys as an authentication migration. Recovery, account linking, testing and rollout gates decide the outcome, not the button.
• Start with your identity provider and your baseline. Measure sign-in failures, recovery volume, support load and SMS costs first.
• Decide the RP ID and origins early. Changing them later orphans every passkey customers have created.
• Let a maintained library or your provider run the cryptography. Your team owns the policy and the authorization that follows sign-in.
• Design recovery before launch. Every fallback sets your real security level, so threat-model and test each one.
• Measure enrollment and usage separately. Expand only on criteria agreed before the pilot.