2025 Wrap-Up: Passkey Upgrades and Improvements

January 15, 2026

Passkeys are rapidly moving from a promising new technology to the clear industry standard for simple and secure authentication. Organizations implementing passkeys usually face two challenges: driving user adoption and delivering a seamless user experience.

The good news is that the passkey ecosystem continues to evolve with these challenges in mind. Here are six new capabilities implementers should know about.

1. The frictionless upgrade: Conditional Create

The challenge: One of the biggest hurdles in passkey adoption is first-time creation. Asking a user to Create a passkey immediately after logging in can add friction to their sign-in process, or relies on them taking an extra step to go into account settings to find that option. This can result in slow adoption, even for enthusiastic users.

The new capability: Conditional Create (also known as automatic password upgrade or automatic password creation) is a simple and effective new flow. It allows relying parties to request the creation of a passkey for a user immediately after they successfully sign in with their password, without additional user confirmation steps. In order for Conditional Create to work, the user must have used a credential manager to sign in with a password, either via browser autofill or platform API. There are additional factors (such as user settings, feature availability, or others) that may block creation of a passkey.

The user flow (please note that the behavior may change depending on the platform or credential manager):

1. User signs in to the app or website using a password saved in their credential manager.
2. Immediately after signing the user in, the app or website silently requests the creation of a passkey via a WebAuthn conditional creation request.
3. The WebAuthn client checks whether the user recently used a password for that account.
4. If the checks are successful, the client allows the passkey creation request to be executed, and if a passkey is successfully created, the user is typically notified via their credential manager. If the checks are not successful, then an error is returned to the app or website without any UI shown to the user.

Why it matters:

• Broader adoption, less friction: Instead of prompting users to create a passkey, relying parties can silently upgrade them to passwordless authentication immediately after they prove their identity.
• A better welcome: The next time that user visits your site, their passkey will simply be there, ready to use. You've transitioned them to a more secure and simpler sign-in without ever forcing them to make a decision or navigate through settings menus.
• Strategic benefit: This feature is an effective tool for migrating current users from passwords to passkeys.

Learn more:

• Android: Create a passkey - 4
• iOS: WWDC25: What’s new in passkeys and ASAuthorizationPlatformPublicKeyCredentialRegistrationRequest.RequestStyle.conditional
• Web: Help users adopt passkeys more seamlessly

2. The housekeeper: Signal APIs

The challenge: When a user creates a passkey it appears as an option during subsequent sign-ins. But what happens when a user deletes their passkey from your service? Or if they change their username or email address? Lingering references to old user identifiers can cause confusion across a passkey’s lifespan.

The new capability: The Signal API is essentially a housekeeping tool. It allows relying parties to communicate changes to a user’s passkeys and metadata on its end to the user's credential manager (such as Google Password Manager or Apple Passwords) about a change, while preserving privacy.

As a relying party (RP), you can now send a signal to the client, which in return sends it to credential managers, to:

• Delete a passkey: When a user deletes their public key from a relying party’s UI, the relying party can ask the client to tell credential managers that a passkey is no longer linked to an account, and it can be deleted. This ensures the deleted passkey is no longer offered as a sign-in option. Many credential managers “soft delete” the passkey, allowing it to be restored for a period of time (for example, 30 days), in case there is an issue.
• Update passkey metadata: When a user changes their username or other account metadata, relying parties can signal the credential manager to update this information. The next time they sign in, the browser and credential manager UIs will correctly display their new username.

Why it matters:

• A more reliable user experience: This API eliminates the confusion and frustration of stale passkeys. The passkeys your users see are more likely to be up to date and functional.
• Reduced Support Tickets: Failed sign-in attempts due to outdated credentials are a common source of user frustration and support costs. The Signal API helps clean this up and ensures a more reliable experience.

Learn more:

• Android: SignalCredentialStateRequest
• iOS: ASCredentialUpdater
• Web: Keep passkeys consistent with credentials on your server with the Signal API

3. The brand unifier: Related Origin Requests

The challenge: Many organizations operate across multiple domains (for example, mycompany.com, mycompany.co.uk, and support.mycompany.ca). Because passkeys are tied to a specific RP ID, users may need to create a separate passkey for each site, even if the domains are tied to the same account. This can be confusing for users, and creates authentication-time friction for both users and relying parties.

The new capability: Relying parties can now declare a list of valid related origins for a given relying party ID. For example, this feature allows a user who has a passkey for mycompany.com (relying party ID is mycompany.com) to log in using that passkey at mycompany.ca (where the origin is mycompany.ca) as long as mycompany.com declares mycompany.ca as a related origin.

Why it matters:

• One account, one passkey: This aligns the passkey experience with user expectations. They create one passkey and can use it across your brand.
• Critical for large organizations: This feature is essential for any business with multiple web properties as it removes a significant adoption hurdle.
• Builds trust: It provides a seamless, consistent, and branded sign-in experience as users move between your various sites and services.

Learn more:

Related Origin Requests outlines this capability, how it works, and important considerations.

4. The scout: Webauthn getClientCapabilities

The challenge: WebAuthn supports many different features, such as suggesting passkeys in autofill or frictionlessly upgrading passwords to passkeys. However, different browsers and authenticators have varying levels of feature support. This can be a challenge for developers, as currently the only way to check if a feature is available or not is to rely on feature specific availability methods, making it difficult to customize the experience to the actual setup the user has.

The new capability: The getClientCapabilities() method acts as a standard query mechanism. It allows relying parties to ask the client (the browser or OS) exactly which WebAuthn features it supports before starting an authentication ceremony. You can check for capabilities like offering a passkey in the autofill dialog, creating and authenticating with a credential on a platform authenticator, or available extensions.

Why it matters:

• Smart, Adaptive UI: You can dynamically tailor the sign-in page. For instance, if the device supports offering passkeys in the autofill dialog, use that; and if it doesn’t, use an alternative treatment like a Sign in with Passkey button.
• Future-Proofing: As the WebAuthn standard grows, this API provides a consistent way to detect new features without rewriting your detection logic for every browser update.

Learn more:

The article Simpler WebAuthn feature detection covers additional details and implementation guidance.

5. The UI director: WebAuthn Client Hints

The challenge: When a user selects Create a passkey, the client typically displays a dialog asking where to save it, and generally defaults to the device's default credential manager. This can be an issue in environments where use of approved hardware security keys is required, such as high-security or workforce scenarios. In this case, users who choose to create a passkey in the device’s credential manager will have an unsuccessful experience, as the passkey created will be rejected by the relying party’s server, and the user will have to create the passkey again (this time, on a compatible security key).

The new capability: The WebAuthn Client Hints feature allows the relying party (your website) to provide information to browsers about what kind of authenticator is preferred. During the call to create the passkey, the website can pass a parameter such as hints: ["security-key"] to request that the browser show the UI for a USB security key first, instead of the default Save to credential manager option. When set to only allow security keys, Client Hints can be used to reduce confusion during sign-in as well.

Why it matters:

• Reduces user confusion: It guides the user to the correct passkey creation/authentication method, aligning the UI with the server's security policy.
• Supports enterprise policy: This is essential for workforce and high-assurance scenarios, where passkeys must be stored on specific hardware tokens.
• Streamlined UX: This allows developers to create dedicated buttons, like Create passkey on this device vs. Create passkey on security key, where each button calls the API with a different hint to provide a predictable experience.

Learn more:

Client Hints explains more about this capability, how it works, and important considerations.

6. The escape hatch: Credential Exchange

The challenge: Lock-in is a concern for users and relying parties. If a user creates a passkey on their computer, what happens if that same credential manager isn't available on their phone? They may worry about easy access to their passkeys. This concern can make users hesitant to adopt.

The new capability: The new Credential Exchange feature allows users to securely export passkeys (and other credentials) from one credential manager to another.

The FIDO Alliance, as an industry forum, collaborated with credential managers and platforms to ensure that Credential Exchange meets industry requirements. The feature is based on the credential exchange specifications and is expected to be implemented by all credential managers. No action is required from relying parties for this feature to work.

Why it matters:

• Removes a key adoption blocker: For any executive or high-level decision-maker, this addresses"lock-in". With this feature you can confidently recommend passkey implementation while ensuring that users will have the option to migrate to a new credential manager in the future.
• Empowers user choice: This new capability puts users in control of their digital identity. This trust is important for passkey adoption.

Learn more:

You can find more details about the credential exchange specifications on the FIDO Alliance website.

Conclusion

Beyond the core sign in experience, the release of these new capabilities helps make the transition from passwords to passkeys smoother for users and easier to manage for relying parties.