Passkeys for SaaS: WebAuthn Architecture, Account Recovery, and Secure Rollout

Passkeys replace a reusable password with a public-key credential. The private key stays with an authenticator or passkey provider; the application stores the public key and verifies a signed challenge. This changes the authentication flow, but it does not remove the hard product questions: how accounts recover, how users add a second device, how enterprise identity fits, and what happens when the credential is lost.

A reliable passkey rollout starts with the server-side WebAuthn ceremony and the recovery model, not with a new sign-in button. This guide covers the core architecture, the verification rules that matter, and a rollout plan for SaaS products.

How a passkey login works

The application is the WebAuthn relying party (RP). The browser communicates with an authenticator, which signs a fresh challenge using a private key associated with the RP ID. The server verifies the returned assertion using the stored public key.

Browser / authenticator             SaaS backend
        |                                 |
        |---- request sign-in options --->|
        |<--- random challenge + RP ID ---|
        |                                 |
        |---- signed assertion ---------->|
        |                                 | verify challenge, origin,
        |                                 | RP ID, flags, signature
        |<--- authenticated session ------|

The private key is not sent to the service. Depending on the platform and provider, a passkey may be synced across a user's devices or be device-bound. The application usually cannot assume which storage model the user selected, so enrollment and recovery need to accommodate the account's actual policy.

Store credentials as account security records

A user can register more than one credential: for example, a synced passkey plus a hardware security key. Store each credential as a separate record associated with an immutable account identifier, not with a mutable email address.

A typical record includes:

• credential ID and public key;
• account ID and creation timestamp;
• authenticator or transport hints when provided;
• sign counter and backup eligibility/state when supported;
• last successful use and a user-visible label;
• revocation status and the reason it was revoked.

Do not store attestation data or device metadata unless a documented policy requires it. Most consumer applications do not need to identify a particular authenticator model. If the product has enterprise requirements for managed or device-bound credentials, validate the attestation and privacy implications with security and compliance owners first.

Registration: bind the response to the right site and account

The server begins registration by generating a cryptographically random challenge and storing it temporarily against the authenticated session. It sends creation options that identify the RP, the user handle, allowed algorithms, user-verification policy, and any existing credentials to exclude.

After the authenticator returns an attestation response, use a maintained server-side WebAuthn library to verify it. The server should check the challenge, expected origin, RP ID hash, ceremony type, required user-presence and user-verification flags, and credential uniqueness before saving the credential.

The challenge must be single-use and short-lived. A client-provided or reusable challenge defeats replay protection. The Web Authentication Level 3 specification requires relying parties to generate unpredictable challenges in a trusted environment and verify that the returned challenge matches.

Prefer a well-maintained implementation over custom cryptographic parsing. Google's server-side passkey guidance similarly recommends server-side libraries because WebAuthn verification has many interacting requirements.

Authentication: verify all security-relevant fields

For each sign-in, create a new challenge, save it in the server-side session or equivalent state, and return request options. When the assertion arrives, verify:

1. The challenge is the exact one issued for this attempt, is unexpired, and has not already been consumed.
2. The client data type is an authentication assertion and the origin is on the application's explicit allowlist.
3. The RP ID hash matches the relying party configuration.
4. The credential exists, is active, and belongs to the account being authenticated.
5. The signature verifies against the stored public key and signed authenticator data.
6. Required user-presence and user-verification flags are present for the chosen policy.

Do not use a credential ID, email address, or client-reported username as authorization by itself. Discoverable credentials can return a user handle; map it to an internal account only after validating the assertion and ensure the handle does not expose unnecessary personal data.

Counters can help detect some cloned or unusual credential behavior, but they are not a universal clone detector. Synced passkeys and some authenticators may not provide a useful monotonically increasing counter. Treat counter anomalies as one signal in a risk policy rather than rejecting every credential whose counter remains at zero.

RP ID and origin decisions are difficult to change later

The RP ID scopes where a credential can be used. By default, it is derived from the origin's effective domain; it can be configured to a registrable parent domain in allowed cases. Choosing example.com instead of login.example.com changes the credential's scope across subdomains. Choose deliberately, document the domain ownership assumptions, and test the real production origins before enrolling users.

The server should still compare the assertion's origin to an explicit allowlist. Do not accept any subdomain through a broad string suffix check. Review preview environments, tenant-specific custom domains, local development, and staging separately so they cannot accidentally authenticate as production.

Recovery is part of authentication, not a support afterthought

Passkeys reduce phishing exposure for the credential ceremony, but users can still lose access to the provider account, lose a device, or need to move between managed devices. Recovery must be designed to avoid making a weaker email or support workflow the easiest way to take over the account.

Offer a way to register multiple credentials while the user is authenticated, and notify users when credentials are added or removed. For lost-credential recovery, require a process appropriate to account risk: an existing credential, a verified enterprise identity provider, a carefully designed recovery factor, or identity proofing with review. Apply rate limits, delayed high-risk changes, audit logging, and user notifications.

If credentials cannot be synced or backed up under the product's threat model, provide a documented backup-authenticator or recovery path before making passkeys mandatory. The FIDO Alliance deployment guidance emphasizes that recovery and new-device enrollment depend on whether credentials are synced or device-bound.

For workforce SaaS, passkeys may be one factor in the identity provider's authentication policy rather than a replacement for SAML or OIDC federation. Keep organization membership, SCIM lifecycle, session policy, and application authorization separate from the user's passkey credential.

Roll out incrementally and measure the fallback path

1. Start with an optional “add a passkey” flow in authenticated account settings.
2. Support multiple credentials and let users name and revoke them.
3. Add passkey sign-in alongside existing login methods, with a secure fallback and clear support guidance.
4. Track registration completion, sign-in success, cancellation, unsupported clients, recovery requests, and credential revocations without collecting unnecessary device data.
5. Test account enumeration, expired and replayed challenges, wrong origins, RP ID mismatch, revoked credentials, and concurrent sign-in attempts.
6. Review the fallback method's resistance to phishing and takeover before reducing password or OTP availability.
7. Expand gradually by user cohort or organization, and keep an operational path to disable a broken ceremony without locking out existing customers.

Changing a password reset page to a passkey dialog is not a complete migration. Authentication sessions still need secure cookies, CSRF defenses where applicable, session rotation after step-up, and clear controls for revoking active sessions. Sensitive actions such as changing payout details or adding an administrator may require fresh user verification even after sign-in.

Passkeys can improve login security and user experience when the relying-party implementation and recovery process are designed together. BoundLayer builds secure SaaS authentication, identity integrations, and backend account lifecycle systems. We can assess a passkey rollout, implement server-side WebAuthn verification, and align recovery and organization policies with the product's risk model. For adjacent account and tenant controls, see our multi-tenant SaaS architecture guide and fintech MVP engineering guide.

Further reading

• W3C Web Authentication Level 3
• Google: Server-side passkey registration
• Google: Server-side passkey authentication
• FIDO Alliance: Displace password and OTP authentication with passkeys