Passkeys at Scale: WebAuthn, FIDO2, and Passwordless Migration

Passwords have been the default authentication factor for decades, and they remain the weakest link in most consumer and enterprise systems. Passkeys replace shared secrets with public-key credentials bound to a device, platform, or sync fabric. The result is phishing resistance, fewer account takeovers, and a smoother login experience. But moving from password-based authentication to passkeys at scale is not a simple toggle. It requires careful protocol handling, recovery design, rollout strategy, and operational discipline.

This article explains the WebAuthn and FIDO2 foundations behind passkeys, how to implement registration and authentication correctly, how to migrate users without locking them out, and what changes when you go from a pilot to millions of credentials.

What Passkeys Actually Are

A passkey is a FIDO credential that uses public-key cryptography. The authenticator, which may be a phone, laptop, security key, or password manager, creates a key pair. The private key never leaves the authenticator. The relying party, meaning your application, stores only the public key and a credential identifier. During login, the authenticator signs a challenge from the server. The server verifies the signature with the stored public key.

FIDO2 is the umbrella standard. WebAuthn is the browser and platform API that lets web applications create and use those credentials. CTAP is the protocol between the client and external authenticators. In practice, you implement WebAuthn on the server and client, and the browser handles the rest.

Passkeys come in two broad shapes. Synced passkeys are backed up and synchronized by a platform provider or password manager, so they are available across devices. Device-bound passkeys live on a single authenticator, such as a hardware security key. Both are valid. The right mix depends on your risk model, user base, and recovery requirements.

Two flags matter for risk decisions: backupEligible and backupState. They tell the relying party whether a credential can be backed up and whether it currently is backed up. These flags are not a security guarantee by themselves, but they help you distinguish a synced passkey from a hardware-bound one.

The WebAuthn Registration Flow

Registration creates a new credential for a user. The server begins by generating a random challenge and sending a set of options to the browser. Those options include the relying party ID, user ID, username, supported public-key algorithms, timeout, attestation preference, and authenticator selection criteria.

The browser calls navigator.credentials.create(). The authenticator generates a key pair, signs the challenge and client data, and returns an attestation object. The server then verifies the response and stores the credential public key, credential ID, sign counter, transports, AAGUID, and backup flags.

Important checks during registration include:

• Challenge: Verify that the returned challenge matches the one you issued, has not been used, and has not expired.
• Origin: Verify that the origin matches your expected origin exactly. Do not use wildcards.
• RP ID hash: Verify that the authenticator data is scoped to your relying party ID.
• Attestation: If you requested attestation, verify it according to your policy. For most consumer applications, attestation none is simpler and more privacy-preserving.
• Algorithm: Confirm that the public key algorithm is one you support, such as ES256, RS256, or EdDSA.
• User presence and verification: Confirm the flags match your requirements. User verification means the user completed a biometric or PIN check.

After verification, store the credential in a durable database. Treat the credential ID as an opaque unique identifier. Do not derive it from the user ID. Store the public key in its raw COSE format or a well-tested encoding, not as a fragile custom string.

The WebAuthn Authentication Flow

Authentication is the inverse of registration. The server generates a challenge and may include a list of allowed credentials. For a usernameless flow, also called discoverable credentials, the server can omit the allow list and let the authenticator choose a credential for the relying party.

The browser calls navigator.credentials.get(). The authenticator signs the authenticator data concatenated with a hash of the client data with the private key. The server verifies the signature, challenge, origin, RP ID, flags, and sign counter. If everything passes, the user is authenticated.

The sign counter deserves caution. Hardware authenticators often increment it on each use, and a non-increasing counter can indicate a cloned credential. However, synced passkeys may not maintain a reliable global counter. Do not make sign counter the primary clone-detection mechanism. Use it as one signal among many.

For high-security flows, you may require user verification. For lower-risk flows, user presence alone may be enough. The WebAuthn flags distinguish UP from UV. Your policy should be explicit about when each is required and how fallback works.

Architecture for Scale

A passkey system at scale is mostly a state management problem. The cryptography is handled by the browser and authenticator, but you still need reliable storage, challenge lifecycle management, session binding, recovery paths, and observability.

Server Components

• WebAuthn library: Use a mature library rather than implementing COSE parsing and signature verification yourself. Good options include SimpleWebAuthn for Node and TypeScript, python-fido2, go-webauthn, and Yubico java-webauthn-server.
• Challenge store: Keep challenges in a fast, ephemeral store such as Redis with a short time to live, usually two to five minutes. Bind each challenge to the current session or user attempt. Mark it as used after verification.
• Credential database: Store credentials in a durable database with strong backup and point-in-time recovery. Credential loss can mean account loss.
• Session layer: After successful authentication, issue your normal session token or JWT. Passkeys replace the password factor, not your entire session model.
• Policy engine: Decide when to require user verification, when to allow synced passkeys, when to demand hardware-bound credentials, and how to handle recovery.

Credential Database Schema

A minimal schema looks like this:

CREATE TABLE passkey_credentials (
  id UUID PRIMARY KEY,
  user_id UUID NOT NULL,
  credential_id BYTEA NOT NULL UNIQUE,
  public_key BYTEA NOT NULL,
  sign_count BIGINT NOT NULL DEFAULT 0,
  transports TEXT[],
  aaguid UUID,
  backup_eligible BOOLEAN,
  backup_state BOOLEAN,
  nickname TEXT,
  created_at TIMESTAMPTZ DEFAULT NOW(),
  last_used_at TIMESTAMPTZ
);

Add indexes on user_id, credential_id, and last_used_at. Keep an audit trail of credential creation, use, revocation, and recovery events. That trail is essential for incident response and user support.

Challenge Management

Challenges must be unpredictable and single-use. Generate at least 16 random bytes, preferably 32. Store the challenge server-side with the user ID, session ID, type, and expiration. Never trust a challenge that comes back from the client without checking your own record. If you support multiple tabs or devices, bind the challenge to the specific authentication attempt.

At scale, use a dedicated keyspace or collection for challenges. Do not mix them with long-lived sessions. Set a hard TTL and delete on use. If Redis is unavailable, fail closed rather than allowing a weaker fallback unless your policy explicitly permits it.

Migration Strategy Without Lockouts

The biggest mistake in passkey adoption is treating it as a hard cutover. Most user bases cannot switch overnight. A staged migration lets you add passkeys, measure adoption, and keep recovery paths intact.

Phase 1: Additive Enrollment

Keep passwords working. After a successful password login, offer passkey creation. Explain the benefit in one sentence: faster login and better phishing resistance. Let users name the credential so they can recognize it later. Support multiple passkeys per account from day one.

Use conditional UI where available. Conditional UI lets the browser offer passkeys in the autofill prompt next to passwords. This reduces friction and increases discovery. The user does not need to click a separate button before seeing the passkey option.

Phase 2: Passkey-First Login

Make passkeys the primary button or the first option, with password as a fallback. Track the fallback rate by user segment, device type, and geography. If fallback is high on a specific platform, investigate the user experience before forcing adoption.

Enable usernameless login where it makes sense. With discoverable credentials, a user can tap the passkey option, choose an account, and authenticate without typing a username. This is excellent for consumer apps, but it can be confusing in shared-device environments. Provide clear account labels and allow users to manage credentials.

Phase 3: Deprecate Passwords Carefully

Only remove passwords when you have strong evidence that users can recover accounts without them. Even then, consider keeping a password fallback for a long tail of users, regulated accounts, or emergency access. For many organizations, the goal is passwordless by default, not password impossible.

Recovery Is the Hard Part

Passkeys reduce phishing risk, but they shift risk to account recovery. If a user loses all devices, how do they get back in? A weak recovery flow becomes the new weakest link. Use a layered approach:

• Multiple passkeys: Encourage users to register more than one device or security key.
• Backup codes: Generate single-use recovery codes at enrollment. Store them hashed. Let users regenerate them after identity verification.
• Trusted devices: Allow recovery from a previously trusted device with additional verification.
• Identity proofing: For high-value accounts, use document verification, video calls, or in-person checks rather than SMS alone.
• Admin recovery: For enterprise accounts, provide a help desk flow with strict authorization and audit logging.

Avoid SMS-only recovery. SIM swapping and SS7 attacks remain real. If you must use SMS, treat it as one signal among several, not as a standalone reset mechanism.

Security Considerations

Passkeys are phishing-resistant because the credential is scoped to your origin and the private key never leaves the authenticator. That does not mean the rest of your application is automatically secure. The following details matter.

Origin and RP ID Binding

WebAuthn credentials are bound to a relying party ID, usually your registrable domain. Subdomains share the RP ID if configured correctly, but you must plan for this. Changing your RP ID later can invalidate existing credentials. Choose a stable domain and document it.

Attestation and Privacy

Attestation can prove which authenticator model created a credential. That is useful for enterprise device policy, but it can also leak hardware identifiers and reduce privacy. For consumer applications, attestation none is usually appropriate. If you require attestation, verify it against a curated trust store and explain the policy to users.

User Verification and User Presence

User presence means someone interacted with the authenticator. User verification means the authenticator confirmed the user, such as with a biometric or PIN. Requiring UV for every login can frustrate users who rely on synced passkeys with a device unlock. Match the requirement to the risk. For step-up authentication, require UV. For low-risk login, UP may be enough.

Sign Counter and Cloning

The sign counter is a weak signal. Many synced passkeys do not guarantee a monotonically increasing counter across devices. If you see a counter regression, you may flag it for review, but do not automatically lock the account. Combine it with device intelligence, impossible travel, and rate limiting.

Credential Revocation and Management

Users need a page to view, rename, and revoke passkeys. When a device is lost, revocation should be immediate and should not break other credentials. Provide a clear last-used timestamp and, where possible, approximate device information without exposing sensitive fingerprints. For enterprise, integrate revocation with device management and identity governance.

Implementation Checklist

Use this checklist as a starting point for production readiness.

• Generate cryptographically random challenges of at least 16 bytes.
• Store challenges server-side with TTL and single-use semantics.
• Verify challenge, origin, RP ID hash, type, and flags on every response.
• Use a well-maintained WebAuthn library for attestation and assertion verification.
• Store public keys in a documented, tested encoding such as COSE or a library-specific format.
• Support multiple passkeys per user and multiple devices per passkey where applicable.
• Implement conditional UI and usernameless login where the platform supports it.
• Design recovery before launch, not after the first lockout.
• Instrument enrollment, login, fallback, error, and recovery metrics.
• Provide clear user education and support tooling.

Operationalizing Passkeys

Once passkeys are live, operations matter as much as protocol correctness. You need visibility into what is happening and the ability to roll back if something goes wrong.

Metrics That Matter

• Enrollment rate: Percentage of eligible users who create a passkey after a prompt or login.
• Login success rate: Passkey login attempts that succeed, segmented by platform and browser.
• Fallback rate: Users who choose password instead of passkey when both are available.
• Recovery rate: How often users need account recovery and which methods they use.
• Error distribution: WebAuthn errors by name, such as NotAllowedError or InvalidStateError.
• Latency: Time from challenge to verified assertion, including network and authenticator time.

Feature Flags and Rollout

Use feature flags to control passkey enrollment, passkey-first login, conditional UI, and usernameless flows. Roll out by percentage, platform, or user cohort. Keep a kill switch that falls back to passwords without deleting existing credentials. Monitor for increases in support tickets, not just technical errors.

Support and Incident Response

Train support teams on passkey concepts. They should know how to guide a user through adding a second device, revoking a lost device, and using recovery codes. For security incidents, they need a clear escalation path for suspected credential compromise. Audit every recovery action. A recovery flow that is too easy is a backdoor; one that is too hard creates account lockouts.

Compliance and Standards

Passkeys can help meet NIST SP 800-63B requirements for phishing-resistant authentication and PSD2 strong customer authentication when implemented with user verification. They also support GDPR data minimization because biometric data stays on the user device. Document your authentication assurance level, recovery policy, and credential lifecycle. Regulators and auditors increasingly expect that level of detail.

Common Pitfalls

Most passkey failures are not cryptographic. They are design and operational mistakes. Watch for these.

• Not binding challenges to the session: This enables replay and confusion attacks.
• Trusting the client: Never accept a credential ID, user ID, or attestation object without server-side verification.
• Using the user ID as the credential ID: Credential IDs must be random and unique. User IDs are not secrets but they should not be reused as credential identifiers.
• Ignoring conditional UI: Without autofill integration, many users never discover passkeys.
• Requiring a single authenticator type: This locks out users and increases support load.
• Weak recovery: The recovery path becomes the preferred attack path if it is weaker than passkey login.
• Not supporting multiple passkeys: One device failure should not mean account loss.
• Treating synced passkeys as less secure by default: For most consumer risk models, synced passkeys are a major security improvement over passwords.
• Forgetting accessibility: Ensure screen readers and keyboard users can complete enrollment and login.

The Future of Passwordless

Passkey support is now widespread across major browsers and platforms. Conditional UI, cross-device authentication, and platform credential managers continue to improve. The WebAuthn Signal API allows relying parties to report credential changes and help sync fabrics stay consistent. Enterprise attestation and managed recovery are maturing, but they are not yet uniform.

The next frontier is not just replacing passwords on the web. It is extending passkeys to native apps, call centers, kiosks, and regulated workflows where identity proofing and recovery must be explicit. Organizations that treat passkeys as one component of a broader identity architecture will get the most value. Those that treat them as a checkbox will struggle with lockouts, support costs, and inconsistent security.

Start small. Add passkeys alongside passwords. Measure. Improve recovery. Then move the default. Passwordless migration is a journey, but the destination is worth it: fewer shared secrets, fewer phishing successes, and a login experience that users actually prefer.