Passkey Rubric

This rubric was written by the FIDO Alliance UX Working Group to be your consultation in a box. Use this framework to self-audit your passkey deployment. The goal is to help you determine the best path forward and help you scale passkey adoption safely, so that users successfully create and use passkeys.

You can apply the guidelines outlined on this page within your own corporate, regulatory, and security policies.

Self-assessment

The rubric is structured around four tiers: Bronze, Silver, Gold, and Platinum. Tiers are cumulative. For example, in order to meet Gold level requirements, you must also meet the requirements for the Bronze and Silver levels.

Bronze is the required functional baseline, Silver is the recommended launch target, and Gold and Platinum build toward a fully passwordless, hardened account.

To assess your implementation, evaluate how fully it meets each requirement. Select the requirement links to view detailed guidance.

Bronze: functional floor

All four requirements are required.

Requirement	What it checks
Tangible passkey management settings UI	Account security settings include a dedicated passkeys section that displays the following for each passkey: the credential provider's name and icon, the creation date, the last-used date, and a straightforward Delete action.
Visible fallbacks	When a passkey prompt fails or is cancelled, alternative sign-in methods and the account recovery path remain clearly visible. The user is never left at a dead end.
Multiple passkeys allowed	Accounts permit registration of more than one passkey across devices, credential managers, and security keys to prevent lockout.
Consistent passkey term and icon	The credential is named passkey (sentence casing, no custom brand names or jargon) and is shown with a recognizable passkey icon.

Silver: user-centric and optimized

Silver is the recommended launch target.

Requirement	What it checks
Passkey autofill (conditional UI)	Passkeys appear in the browser's autofill suggestions for the username field, or in the equivalent bottom sheets.
Sign-in routing and discovery	The flow uses identifier-first routing, immediate mediation, or smart button placement to check for passkey presence before prompting the user, to help prevent dead ends.
Platform prompt strategy	The flow checks device capabilities. On mobile, the flow then goes to the sign-in dialog provided by the operating system. On desktop, a brief priming screen precedes the operating system dialog.
Contextual, dismissible creation prompts	Passkey creation prompts are generated based on where the user is in their journey (after sign-in, around a key action, during account recovery), use benefit-led copy, offer a clear Not now option, and only reappear after a set cooldown period.
Graceful error handling	On failure, the flow retains the entered username and uses passkey metadata, (such as, Authenticator Attestation Global Unique Identifier (AAGUID) and platform) to suggest either a local retry or cross-device sign-in.
Accessibility	After an operating system prompt resolves, keyboard and screen-reader focus is preserved, state changes are announced through aria-live regions, and fallbacks are reachable by keyboard.

Gold: passwordless north star

Gold adds automated scale and sync.

Requirement	What it checks
Automatic passkey upgrades (conditional create)	After a successful password sign-in, the site asks the credential manager to upgrade an eligible saved password to a passkey, with no extra user steps.
Post-upgrade notification	After a passkey is created automatically, the site notifies the user (in-app message, banner, or email) what was saved and what to expect at the next sign-in.
Signal API integration	The site uses the Signal API to notify credential managers when a passkey is deleted or revoked, or when the user's account details change, so that stale credentials are removed or updated.
Risk-aligned fallbacks and recovery	Alternative sign-in methods and account recovery paths align with the application's risk profile.

Platinum: holistic account security

Platinum is the full rubric plus hardening.

Requirement	What it checks
Account-level hardening	Phishable factors (passwords, SMS OTP) are retired and strong recovery (for example, verifiable digital credentials) is adopted so the whole account is phishing-resistant.
Multi-domain alignment	If your organization uses multiple domains, consider using Related Origin Requests (ROR) to link them together where applicable.

Anti-patterns to avoid

Your implementation, regardless of level, should not include any of the following anti-patterns. Each one is a red flag.

Red flag anti-pattern	Why it disqualifies
Hostage modals	Requires an existing user to create a passkey before they can access their account and does not offer a Not now option. This is only acceptable for scenarios with passkey-first sign-up or a planned migration to passwordless accounts. This anti-pattern applies to forcing creation on users who already have an account.
Single-passkey restriction	Limits an account to only one registered passkey.
Security key exclusion	Prevents users from creating passkeys on hardware security keys and removes their choice of where to store a passkey.
Raw error codes	Displays developer error codes (for example, a DOMException message) to end users.
Entirely silent upgrades	Upgrades passwords to passkeys in the background without any post-creation signal or toast.
Calling them something other than passkeys	The canonical term for this credential is passkey. Renaming breaks user recognition.

Passkey sign-in and creation

This section outlines how users discover, learn about, and create their first passkey. You should start by making passkeys easy to find and use.

Passkey autofill (WebAuthn conditional UI)

The traditional sign-in flow is username-first, asking the user to identify themselves before the system presents a challenge. Passkeys enable credential-initiated authentication through WebAuthn conditional UI, commonly referred to as passkey autofill.

What it is: Passkeys appear natively in the browser's standard autofill dropdown or the equivalent bottom sheet on mobile the moment a user selects the username field .

Why use it: Relying parties like PayPal have seen an 8% improvement in passkey sign-in success rates by implementing conditional mediation (Authenticate 2025 - Paypal Presentation, at 6:23). Autofill relies on existing muscle memory, requires little, if any, user education, and serves both password and passkey users in the same space.

Sign-in routing and discovery

If autofill alone does not surface a passkey, check for one before prompting. Any of the following three patterns satisfy this check.

Identifier-first (username-first)

What it is: The user enters only their username on the first screen, which allows the backend to route them to the correct sign-in method on the second screen.

Why use it: Relying parties like Uber saw a 10x improvement in passkey usage rate by waiting until after users entered their email address or phone number (Authenticate 2025 - Uber Presentation, at 7:46) before presenting a sign-in method. This pattern can be especially useful for enterprise and SSO routing and works well for consumer use cases too. It lets the system check if a user actually owns a passkey before triggering a prompt, which prevents dead ends and user confusion. After decades of traditional username-first sign-ins, users might enter usernames from muscle memory.

• Use the Signal API to keep your backend and the user's credential manager synchronized, so that the backend does not route a user to a passkey they no longer have.
• Contrast this with passkey autofill (WebAuthn conditional UI), which naturally avoids this issue by only offering the passkey if it exists on the user's device.

WebAuthn immediate mediation

What it is: The browser instantly checks for a local passkey on page load. If it finds one, it prompts the user to use it immediately. If it does not, it fails silently in the background, and the web page can decide which alternate action to take instead.

Why use it: Immediate mediation is the safest way to trigger automatic, proactive sign-ins. Because it suppresses fallback UIs (such as unwanted cross-device QR codes) if a local passkey is not found, it keeps the experience frictionless.

Platform support note: Immediate mediation is an emerging capability that is rolling out across major platforms, led by Chromium-based browsers in 2026. Check platform compatibility or use feature detection before invoking this mediation type, so that the flow falls back gracefully in browsers that do not yet support this mode.

Refer to Origin trial: WebAuthn immediate mediation for frictionless sign-in and the demo video for more information.

Dedicated passkey button

What it is: A standalone Sign in with a passkey button that is explicitly separated from standard fields.

Why use it: A dedicated button gives the user direct control and builds awareness. It is also the most direct way to intentionally trigger cross-device authentication (for example, showing a QR code to sign in on a new laptop using a phone).

Placement considerations: Placing a dedicated button alongside multiple social sign-in options can introduce decision-making friction, leaving users struggling to recall which method they initially used. Carefully consider where you place the button in your flow.

• On the identifier step: Enables a true zero-typing sign-in and provides parity with social sign-in buttons. However, it introduces an extra decision on the first page when paired with social sign-in options and brings users immediately to a cross-device QR code flow if no local passkey exists on their current device.
• On the password step: Helps in cases where the user types their username or email address first and then uses their passkey to complete sign-in. This placement also allows you hide the button if there is no passkey tied to the account used in the identifier step, which helps prevent dead ends. The downside is that the user must still remember and type their identifier.

Be sure to A/B test by platform, as what works on desktop might not work on mobile.

Refer to Sign In with a Passkey for more information.

Automatic passkey upgrades (conditional create)

Automatic passkey upgrades, also called conditional create, provide apps and websites with a zero-friction way to create passkeys for users. This feature upgrades the password in a user's password manager into a passkey after a successful password sign-in. The credential manager typically shows a brief system notification, but you should also notify the user. Relying parties like PayPal (75,000 additional enrollments per month) and Adidas (8% increase in enrollments) have shared meaningful wins.

Considerations:

• A password must already be saved in a password manager. The conditional create feature only works if the password is saved in a compatible credential manager. If the user is ineligible, the background request fails silently without breaking the sign-in flow.
• Build trust and awareness. Be careful with entirely silent upgrades. While frictionless background creation is convenient, users can become confused if they are later prompted to sign in with a passkey they do not remember setting up. An email, an in-app notification, or a notification during sign-in can let a user know what happened:
  • Acknowledge the creation. Let them know a passkey has been successfully created in their credential manager.
  • Define it simply. Explain what a passkey is (for example, A fast and secure way to sign in using your fingerprint, face, or screen lock instead of a password).
  • Set expectations. It can be helpful to suggest they will use a passkey next time, and tie it to the experience (for example, You'll use your fingerprint, face, or screen lock instead of a password).

Refer to Help users adopt passkeys more seamlessly for more information.

Contextual, dismissible creation prompts

When you introduce passkeys to users, avoid technical explanations of public-key cryptography. They are not useful to a typical user.

Ways to tailor your prompts:

• Tailor by touchpoint. Keep the user's mindset in mind and try to match the user's emotional state at that point in the journey.
• Tailor to the application. E-commerce platforms typically see higher conversion when they lead with speed and convenience. Conversely, financial institutions or healthcare portals might see better success when they lead with security.

The context of your flow matters:

• Post-sign-in timing can work well. Real-world relying party data shows that the moment immediately following a successful sign-in is a strong touchpoint for passkey creation. The user's session is securely established, and the friction of typing a password is fresh in their mind, which makes the value proposition (Sign in faster next time) immediately relevant.
• Keep prompts contextual and non-blocking. If you display an explicit creation prompt (rather than an automatic background upgrade), present it as a clean, dismissible banner or contextual card on the post-sign-in dashboard rather than a blocking modal. Always provide a clear Not now or Skip option with a smart cooldown before re-prompting.

Best practices by touchpoint:

Touchpoint	User mindset	Good example of copy	Avoid
Just after sign-in	The user just experienced the friction of signing in. Focus on future speed and convenience.	Sign in faster next time. Save a passkey to your device to skip typing your password on your next visit.	Technical descriptions, or treating passkeys as the product (for example, Generate a passkey for future authentication).
Around key actions or during onboarding	The user has high intent to complete a specific action. Keep it frictionless and highlight time savings.	Enable fast checkout. Use your face, fingerprint, or PIN next time.	Long explanations that distract from completing their purchase.
After a security event, such as account recovery or a password reset	The user wants reassurance and protection. Pivot messaging strictly to security.	Protect your account. Set up a phishing-resistant passkey to ensure only your trusted devices can sign in.	Focusing only on speed or convenience when the user is actively worried about security.

Platform prompt strategy

• On mobile (direct-to-prompt): Skip introductory screens. Bring the user directly to the native operating system prompt to get them signed in as fast as possible.
• On desktop (prime-before-prompt): Show a clean, descriptive page first (for example, Use your face, fingerprint, or PIN to sign in) with an explicit trigger button. This ensures they expect the browser prompt when it appears.

Unlike mobile, where biometrics are highly integrated and always present, desktop environments are highly fragmented (for example, closed laptop lids, external monitors, or browser extension overrides). If a user does not have a local user verification method ready, going direct-to-prompt instantly triggers a cross-device QR code flow, which can be jarring if the user has not been prepared for it first.

Your desktop priming screen copy provides an opportunity to address the psychological barriers that might come up for your audience. Your research helps you identify where the concerns of your audience lie. Common examples include:

• Fear of lockout: Reassure the user that backup paths exist. This can be a good opportunity to set up a recovery path with your users.
• Biometric privacy: Clarify that biometrics stay on the device (for example, Your fingerprint or face data is kept private by your device and is never shared with us).
• Low familiarity: Define the benefit in simple, plain language (for example, Passkeys are a faster way to sign in that's safer than passwords or SMS codes).

If a user cancels or dismisses a native prompt on either platform, gracefully return them to a visible fallback screen that lists alternative sign-in methods (for example, password or security key). Never let a failed prompt result in a dead end.

Considerations:

• Classify platforms accurately. Implementing this strategy requires reliable, accurate platform classification.
• Check support first. Before rendering any passkey UI, use the getClientCapabilities() method to silently detect if the user's current environment supports passkeys.
• Validate with testing. Use the mobile and desktop playbook above as your default baseline, but every audience and relying party is unique. Run targeted research like A/B tests to verify the best way to introduce passkey prompts into your flow.

Day-to-day passkey experience

This section covers steps you can take to enhance the user experience with regards to account access and recovery.

Support resilient account recovery

A successful authentication experience requires that users can always sign in, even if they lose access to their passkeys. As we examine ways to enhance the user experience, you will want to think of account recovery in terms of two possible situations:

• Sign-in friction happens when a user experiences a situational or motivational barrier during a sign-in attempt. For example, they do not have immediate access to their passkey because their phone is in another room, or they do not want to stop what they are doing to complete a cross-device prompt. In these moments, the user does not need a full recovery flow. They need a highly visible, instant way to choose an alternate sign-in method for that session.
• Account recovery is necessary when a user permanently loses access to their credential manager (for example, they lost access to their credential manager account) or device (for example, a corrupted key). This is a permanent trust event where you must guide the user to securely re-verify their identity, enroll a new passkey, and revoke access to their lost credentials.

Allow multiple passkeys

The first line of defense against lockout is to allow users to set up more than one passkey. This can include allowing users to create passkeys across platforms, such as a passkey on their phone or in different credential managers. If they cannot sign in with one passkey they can still sign in using a passkey on another device or credential manager.

Maintain visible fallbacks

If a passkey sign-in fails or is cancelled, make clear what options the user has. A simple UI alert can guide a user to the next step to use a fallback method or invite them to try again with their passkey.

Choose risk-aligned fallbacks and recovery

Account recovery is all about managing risk. While SMS OTP remains one of the most widely used and accessible recovery methods, it does not offer the same phishing-resistant protection as a passkey. Deprecate SMS OTP discusses this in more detail.

Following the principles of the IDPro account recovery framework, your recovery path should match your application's risk profile and take into account your location, industry, regulatory requirements, country, application, customers, and customs. Use the IDPro reference to establish a recovery flow that matches your organization's security policies and specific needs. Refer to Account Recovery (v3), IDPro Body of Knowledge for more information.

Design for graceful errors and edge cases

To protect user privacy, WebAuthn returns a generic error when a passkey prompt fails. The error is the same whether the user cancels, the biometric sensor fails, or the device lacks compatible hardware.

Instead of showing generic errors or no message at all, you can use the client's current environment and the registered passkey's AAGUID to diagnose the problem and provide dynamic, contextual advice.

To achieve this:

• Compare the platform and the passkey location. If a WebAuthn prompt fails, check the user's current platform and compare it against their saved passkey's location in your database (using the AAGUID).
  • If their passkey is on a different ecosystem, suggest cross-device sign-in (for example, Try signing in with the phone where your passkey is saved).
  • If their passkey is on the same ecosystem, suggest a quick biometric retry or screen lock fallback (for example, Try again, or use your device's backup PIN).
• Maintain context. If an error occurs, do not clear the username field or force the user to restart the entire sign-in flow. Keep all entered information intact.
• Keep fallbacks visible. Ensure that alternative authentication methods remain available so users can pivot without getting stuck in a retry loop.

Allow the same passkey across all of your websites

If your brand operates multiple websites (for example, yourbrand.com and yourbrand.ca for Canada), you can link them together behind the scenes using a feature called Related Origin Requests (ROR).

Instead of asking a user to create a new passkey for every domain you own, this feature lets them create one passkey and use it to sign in to all of your connected sites. You must configure your domains correctly for this to work securely. Refer to Related Origin Requests, passkeys.dev for more information.

note

ROR has not been fully adopted by the ecosystem yet (for example, by browsers and credential managers), so make sure alternative authentication methods are available for users when ROR is not available.

Accessibility

While passkey biometric prompts, autofill UI, and other native elements are handled by the operating system or browser, the relying party can have a big impact on the connective tissue between identity-related prompts.

Implementations can address the following to improve passkey accessibility:

• Focus management: Keyboard and screen reader focus must be logically preserved or intentionally redirected after a native operating system prompt resolves, whether it results in success, failure, or user cancellation. Users must never lose their place on the page.
• Dynamic announcements: Non-visual state changes and custom error messages (for example, Passkey failed, try another method) must be wrapped in aria-live regions to ensure immediate announcement by screen readers.
• Cognitive priming: Clear, text-based context provided before invoking an operating system prompt can help prevent jarring context switches for users with cognitive disabilities or those using assistive technologies.
• Accessible fallbacks: Alternative authentication routes must remain highly visible, clearly labeled with ARIA attributes where necessary, and easily navigable by keyboard.

Settings and lifecycle management

Building a successful passkey experience also requires that you examine the ongoing lifecycle of passkeys in your ecosystem. This includes using consistent passkey terminology and iconography, providing visual UI passkey management options to the user, and ensuring that your Signal API keeps passkey information up to date.

Maintain consistent passkey terminology and familiar iconography

Familiarity drives confidence and aligning with the broader ecosystem helps everyone.

• Iconography: Show a recognizable passkey icon wherever the term appears. Take inspiration from the recognizable elements of the FIDO Alliance passkey icon, and adapt its styling to match your brand's design system. The FIDO-provided icon is a directional, optional, additive tool to help build recognition, not a strict design constraint.
• Terminology: Consistently refer to the credential as a passkey (lowercase, except when starting a sentence). Avoid highly technical jargon like WebAuthn credentials or cryptographic tokens, which can alienate users. Also avoid custom terms like Fingerprint Login or FaceID Key, which fail to capture the growing ecosystem of passkeys.

Refer to Passkey Management UI: Best Practices for Combining All Passkey Types for more information.

Provide a visual and tangible passkey management settings UI

Unlike passwords, which can be visualized as dots or strings, passkeys are invisible cryptographic key pairs. Making passkeys feel tangible helps with comprehension and recognition.

Create a dedicated section in the account security settings with a clean layout. Each passkey should display:

• The credential provider's name and icon (for example, Saved in Apple Passwords or Google Password Manager).
• The date of creation.
• A timestamp of the last time it was used.
• A clear, visible Delete action (rather than Revoke or Disable).

Refer to Passkey Management UI: Best Practices for Combining All Passkey Types for more information.

Sync deleted and renamed passkeys with the Signal API

When a user changes their username, resets their password, or goes through account recovery, their credential manager can accumulate stale, orphaned credentials that no longer match how the user can sign in.

Integrate the Signal API to run background updates. When a username or display name changes, an account is deleted, a user deletes a passkey, or a passkey is revoked server-side, send a background signal to the credential provider to update or remove the passkey. This keeps the user's autofill dropdowns clean and reduces sign-in failures for your website or app.

If a passkey is determined to be invalid at sign-in, you can immediately send a Signal API call to clean up the stale passkey on the spot.

Refer to Keep passkeys consistent with credentials on your server with the Signal API for more information.

tip

Before implementing the Signal API, eBay observed that users frequently encountered sign-in failures when attempting to use passkeys that had been deleted server-side (for example, following a password reset or account recovery flow). This happened because the user's credential manager did not know these credentials were invalid, so users went through the entire authentication flow only to be rejected after completing it. This experience compounded over time as old credentials accumulated. Implementing the Signal API resolved this, keeping credential managers in sync with the server.

Account hardening

To realize the full security benefit of passkeys, do not stop with a phishing-resistant credential. Make the whole account phishing-resistant. The account is only as secure as its weakest credential, so removing passwords, SMS, and other phishable credentials can close security gaps. Consider implementing verifiable digital credentials for account recovery as well.