Passkeys and Password Managers: Relying Party Guide

1. Introduction#

Password managers sit between users and relying parties (RPs) in the passkey ecosystem. Since the introduction of passkeys they have moved from storing passwords to creating, syncing and presenting passkeys, and that changes what RPs have to handle. This article answers two questions about the password manager landscape:

• Passkeys & Password Managers: How do password managers handle passkeys across different devices?

• Passkey Implementation: What are the implications for RPs in supporting passkeys with different implementation approaches?

We’ll explore the nuances of passkey support across platforms, the unique challenges posed by mobile operating systems like iOS and Android, and the strategies RPs can adopt to optimize their passkey integration with password managers while ensuring a seamless user experience.

2. How do password managers handle passkeys?#

Password managers store the private key of a passkey, sync it across the user's devices and present it to the browser or operating system when an RP requests a sign-in. They do this through browser extensions that intercept JavaScript WebAuthn calls or through OS level credential provider APIs. The mechanism decides which devices, browsers and flows can use a stored passkey.

2.1 How Password Managers work with Passkeys#

Password managers act as the bridge between a user's credentials and relying parties. At operating system level they register as credential providers, store and sync passkeys and answer the sign-in request of the browser or app, so the RP never has to handle the private key itself. Their role includes:

• Secure Storage: Storing passkeys in encrypted vaults and utilizing OS-specific secure storage solutions for managing access to them.

• Cross-Device Syncing: Ensuring seamless access to credentials across devices by securely synching them.

• User Convenience: Intercepting browser or app authentication calls to autofill credentials or facilitate passkey login and creation.

• Intercept Key JavaScript Functions: Browser extensions for password managers overload important passkey JavaScript functions such as navigator.credentials.get(), navigator.credentials.create() and isUserVerifyingPlatformAuthenticatorAvailable() to provide seamless integration for passkey creation, retrieval and feature detection workflows. This ensures compatibility without requiring users to manually manage their passkeys.

• Leverage Conditional UI: By interacting with Conditional UI flows (available in modern browsers and native mobile environments), password managers can dynamically handle passkey requests, enabling users to authenticate without needing to explicitly select their credential provider.

Password managers in the context of passkeys are also called Third-Party Passkey Providers. These providers are distinguished from First-Party Passkey Providers, which are built directly into operating systems (e.g., iCloud Keychain on iOS or Google Password Manager on Android) and manage passkeys natively on the user’s device. Third-Party Passkey Providers, on the other hand, operate as external tools that integrate with the operating system via APIs to facilitate the creation, storage and management of passkeys.

Three terms are easy to mix up:

• Password manager: the app the user chooses to store credentials, for example 1Password, Bitwarden, Apple Passwords or Google Password Manager. It holds passwords and passkeys and syncs them across devices. It reaches a passkey request either through a browser extension or as a credential provider.

• Credential provider: the role a password manager takes when it registers with the operating system to create and return passkeys (AutoFill on macOS and iOS, a provider for Android Credential Manager, a passkey provider on Windows 11). The operating system draws the dialog and lists the provider as one option.

• Credential manager: the generic term for whatever answers a WebAuthn request on the device: a browser extension, the browser's built-in manager or a credential provider. Not to be confused with Android Credential Manager, the system API and bottom sheet that sits between apps and the enabled providers.

2.2 Browser Extensions vs. Operating System Integration#

Password managers reach passkeys through two routes. Browser extensions work on desktop browsers by intercepting WebAuthn calls, while operating system integrations use the platform's credential provider API on iOS, Android, macOS and Windows 11. Support depends on OS version and platform constraints, as the summary below shows:

Mobile operating systems, such as iOS and Android, are inherently more contained compared to desktop environments. Unlike desktop platforms, where browser extensions can directly integrate with applications to provide seamless credential management, mobile operating systems do not support plugins for individual apps or browsers. This applies even to Android, which is traditionally considered more open than iOS.

When passkeys were first introduced, external (third-party) password managers were not supported. Initially, only first-party passkey providers such as Apple’s iCloud Keychain on iOS or Google Password Manager on Android could handle passkey creation and management. Over time, both ecosystems recognized the need to support third-party passkey providers and expanded their APIs to include them.

This evolution now allows users to integrate their preferred password managers into mobile workflows, but this functionality is only available on specific OS versions:

• iOS 17 via the Password Manager API

• Android 14 through the Credential Manager API

By understanding how password managers handle passkeys through browser extensions, OS integrations and the overloading of key JavaScript functions RPs can design implementations that ensure compatibility and usability across platforms.

2.3 Trend: going from First-Party to Third-Party#

As the adoption of passkeys accelerates, major ecosystem players like Apple and Google are expanding their offerings to provide seamless experiences across their own platforms. Initially limited to their own devices, both companies have made strides to enhance cross-platform usability for their passkey solutions.

Google has extended its Google Password Manager into both its Android ecosystem and Chrome browser on other platforms. Apple has introduced a dedicated Password App, marking a significant step toward making its passkey and password management system more accessible and user-friendly across its platforms. These developments signal a growing trend where first-party solutions, traditionally tied to a single ecosystem, are evolving to cater to diverse user needs and platforms.

2.3.1 Google Password Manager#

The Google Password Manager is Google's own credential manager for passkeys. Passkeys saved there sync through the user's Google account, and from Chrome 132 it can also act as a third-party provider on iOS and iPadOS. It plays an important role in Google's ecosystem by providing:

• Seamless Integration: It is tightly integrated with Google Chrome and the Android operating system, making it the default passkey and password management tool for millions of users.

• Passkey Support: Introduced in Chrome 129 for desktop platforms and extended to iOS with Chrome 132. Google Password Manager now supports the creation, management and use of passkeys.

• Cross-Platform Syncing: Passkeys and passwords stored in Google Password Manager sync across Android devices, Chrome browsers (on Windows, macOS, iOS, iPadOS, Linux) and ChromeOS.

• Browser Compatibility: While tightly integrated into Chrome, it allows users to autofill credentials across various websites without requiring separate browser extensions.

Key Features:

• Built-in TPM-based security for passkey storage, ensuring credentials are securely stored on compatible devices.

• Conditional UI Integration to streamline passkey creation and login flows across supported environments.

• Easy-to-use management options in both the browser and Android settings, allowing users to delete, review or share credentials.

With Google Password Manager, Google is closing the gap for Android users by enabling seamless access to passkeys stored on all desktop platforms and vice versa.

2.3.2 Apple Password App#

With iOS 18, iPadOS 18 and macOS Sequoia Apple has taken a significant step by introducing the Password App, a standalone application that consolidates its passkey and password management features that prior was only embedded into the operating feature in the settings. This app represents a more user-centric approach to credential management and shows how important it has become with passkeys.

Core Features:

• Centralized Management: The Password App serves as a single destination for users to view, manage and share their passkeys and passwords.

• iCloud Keychain Integration: It seamlessly integrates with iCloud Keychain, ensuring credentials are securely synced across all Apple devices (iPhone, iPad, Mac).

• Passkey Support: Apple’s Password App supports the creation and use of passkeys, with deep integration into Safari and the operating system. Passkeys are stored securely using Apple’s Secure Enclave and synced across devices via iCloud.

• Credential Exchange: Since iOS 26 and macOS 26, users can move passkeys and passwords between Apple Passwords and third-party managers such as 1Password, Bitwarden and Dashlane, based on the FIDO Credential Exchange standard. Passkeys are no longer locked into the manager that created them.

Additional Capabilities:

• Family Sharing: Apple allows users to share passwords and passkeys securely with family members in the same Family Group, streamlining credential sharing within trusted groups.

• Enhanced Security Features: The Password App includes proactive security alerts for compromised passwords and encourages users to transition to passkeys when available.

It is much harder for Apple to expand their reach to Windows users, as they don’t have a browser through which they can ship a solution like Google. Now, it remains to be seen if Apple will take the next step, allowing passkeys from iCloud Keychain to be used on Windows and/or Android through a third-party provider approach, but the first step has been made.

3. Which password managers matter for passkeys?#

The password manager landscape for passkeys splits into first-party providers built into the OS or browser, such as iCloud Keychain and Google Password Manager, and third-party managers such as 1Password, Bitwarden or Dashlane. Most third-party managers cover all major operating systems, while the first-party providers work best inside their own ecosystems.

Supporting passkeys at all and supporting every WebAuthn Level 3 feature are two different things, and the second one is tracked per provider in our WebAuthn L3 support matrix.

Most commercial password managers support all major operating systems, including Windows, macOS, Linux and mobile platforms like iOS and Android. On desktop platforms, they achieve compatibility through browser extensions that seamlessly tie into Chrome, Firefox, Edge and Safari. On mobile devices, these password managers integrate directly with the operating system’s APIs, leveraging the native passkey management frameworks we looked at in the last chapter. For passwords they have been around quite some time.

While most password managers deliver consistent functionality across platforms, there are notable exceptions, particularly with Google Password Manager (GPM) and Samsung Pass that work a bit differently. For the time being Apple Password App cannot be classified as password manager as the functionality is still contained in the Apple ecosystem for passkeys. The following table provides an overview of passkey support across various password managers (including open source password managers), offering insight into their cross-platform compatibility and specific requirements.

The password manager landscape has evolved rapidly to meet the demands of modern authentication, particularly with passkeys in the last two years. By understanding the strengths and limitations of these tools, RPs can better align their passkey implementations to ensure compatibility, usability and security. In the next chapter, we will explore the implications of these differences for RPs, with practical guidance on implementing passkey workflows and optimizing user experiences.

3.1 How do Password Manager Extensions change the Passkey Dialog?#

On desktop, a password manager extension replaces the browser passkey dialog with its own interface. We tested six extensions in Chrome on macOS in October 2026, using webauthn.io as a neutral test page: Bitwarden, Proton Pass, NordPass, Dashlane, LastPass and 1Password. Five of the six render their dialog as an overlay inside the web page, only Bitwarden opens a separate popup window. All six support Conditional UI, but only three show it as a menu below the username field. Proton Pass, NordPass and 1Password show it as a card in the top right of the page.

For relying parties this means one login page can produce six different looking passkey prompts on the same laptop, depending on which extension the user has installed. Page copy such as "Use Face ID" or "Your phone will ask you" is wrong for these users. Neutral wording such as "Continue with your passkey" works for every provider.

3.1.1 Bitwarden#

Bitwarden is the only extension in this test that opens a separate popup window instead of an overlay inside the page. The window offers to attach the passkey to an existing login or to save it as a new one. A link at the bottom, "Use your device or hardware key", hands the request back to the browser.

Bitwarden in Chrome on macOS: passkey creation

Bitwarden in Chrome on macOS: passkey login

Bitwarden in Chrome on macOS: Conditional UI

3.1.2 Proton Pass#

Proton Pass shows a card in the top right corner of the page for every step. Before saving, the card shows title, username and website and states that the passkey will be available on every device where Proton Pass is installed. For Conditional UI, the same card appears as soon as the username field gets focus, there is no menu below the field.

Proton Pass in Chrome on macOS: passkey creation

Proton Pass in Chrome on macOS: passkey login

Proton Pass in Chrome on macOS: Conditional UI

3.1.3 NordPass#

NordPass uses a card in the top right with a dark primary button. The creation card lets the user edit the title or switch to a different passkey provider. The login card has a QR code icon for signing in from another device. For Conditional UI, NordPass opens the same card without a click on the login button and lists every passkey stored for the site. The menu inside the username field is a different feature: it only suggests saved email addresses and shows no passkeys.

NordPass in Chrome on macOS: passkey creation

NordPass in Chrome on macOS: passkey login

NordPass in Chrome on macOS: Conditional UI

3.1.4 Dashlane#

Dashlane keeps both dialogs short, with one entry and a Confirm button in a card in the top right. Conditional UI appears as a branded "Log in as" menu directly below the username field, with a link to use a different passkey.

Dashlane in Chrome on macOS: passkey creation

Dashlane in Chrome on macOS: passkey login

Dashlane in Chrome on macOS: Conditional UI

3.1.5 LastPass#

LastPass shows an "Add to LastPass?" card in the top right that combines the save action with a short product message. Login works through a similar card with options to use a different passkey. Conditional UI appears as a menu below the username field that looks close to Chrome’s own autofill.

LastPass in Chrome on macOS: passkey creation

LastPass in Chrome on macOS: passkey login

LastPass in Chrome on macOS: Conditional UI

3.1.6 1Password#

1Password shows a compact card in the top right and lets the user choose the vault before saving. Login is a single "Sign in" button per passkey. For Conditional UI, 1Password reuses the same card in the top right instead of a menu below the field.

1Password in Chrome on macOS: passkey creation

1Password in Chrome on macOS: passkey login

1Password in Chrome on macOS: Conditional UI

3.1.7 Does the Extension look different in Edge, Firefox or Safari?#

Bitwarden looks the same in Chrome, Microsoft Edge and Firefox on macOS. We repeated the Bitwarden test in Edge and Firefox: the save window, the login window and the Conditional UI menu match the Chrome version, Firefox only adds the extension name to the window title. We did not repeat this comparison for the other five managers. Extensions also draw their own UI in Safari: the 1Password extension offers its saved passkeys in the same card it uses in Chrome. Bitwarden also supports passkeys in its Safari extension.

Bitwarden in Microsoft Edge on macOS: passkey creation

Bitwarden in Firefox on macOS: passkey creation

1Password extension in Safari on macOS: passkey login

3.2 How does the native Credential Provider look?#

When a password manager works as native credential provider instead of through a browser extension, the operating system draws the passkey dialog and the password manager only appears as an option in a system list. Every manager therefore looks almost the same. The captures below use 1Password as third-party provider on macOS, iOS and Android.

3.2.1 macOS#

With 1Password enabled under System Settings > General > AutoFill & Passwords and no extension active, Safari shows the macOS system sheet with 1Password preselected under "Save In". "More Options" switches to Apple Passwords or a security key.

1Password as native provider in Safari on macOS: passkey creation

With more than one provider switched on, for example Apple Passwords and 1Password, macOS first asks where to save the passkey.

1Password and Apple Passwords in Safari on macOS: provider picker on passkey creation

3.2.2 iOS#

Safari on iOS shows a system sheet that lists every enabled provider. The user picks 1Password or Apple Passwords and confirms with Face ID.

1Password and Apple Passwords in Safari on iOS: passkey creation

3.2.3 Android#

Chrome on Android shows the Credential Manager bottom sheet "Save passkey to". It lists the enabled providers, Google Password Manager under "Other password managers" and an option to save the passkey on another device.

1Password and Google Password Manager in Chrome on Android: passkey creation

3.2.4 Windows 11#

Since the November 2025 update, Windows 11 accepts third-party passkey providers. The user enables them under Settings > Accounts > Passkeys > Advanced options, and they then appear as an option in the Windows Hello dialog. 1Password ships this in its Microsoft Store version, Bitwarden offers it in beta. Windows 10 has no OS-level third-party passkey support, so the browser extension is the only path there.

In Edge, the Windows Security dialog names 1Password as the save location. "Change" switches to another enabled provider, such as Microsoft Password Manager.

1Password in Microsoft Edge on Windows 11: passkey creation

4. What do password managers mean for your passkey implementation?#

How password managers impact your implementation is largely determined by your current passkey implementation approach. The two most common approaches are a simple “passkey button” or an identifier-first flow that automatically detects available passkeys after asking for email/identifier. Each approach has different implications for both user experience and technical complexity. Below, we’ll break down these options and offer guidance on what relying parties (RPs) should consider regarding password manager.

4.1 Differentiating: Passkey Button and an Identifier-First Flow#

An RP can offer passkeys through a passkey button or through an identifier-first flow. The button is simple and needs no platform checks but delivers lower adoption, while identifier-first detects passkeys after the user enters an identifier and delivers very high adoption at the cost of more logic. The trade-off decides how much password manager support you need.

The passkey login best practices cover both flows in detail.

4.1.1 Passkey Button#

A passkey button shows a direct "Sign in with passkey" action on the login screen. It triggers a passkey ceremony with an empty allowCredentials list and usually relies on Conditional UI as well. It needs no platform capability checks, which keeps it simple but gives low passkey login adoption. The implications are (see allowCredentials and Conditional UI):

• Client-Side Responsibility: Because password manager can intercept the ceremony on the user’s device (via a browser extension on desktop, or via the OS on mobile), the user is primarily responsible for having the passkey available whether in a first-party (OS-level) or third-party (password manager) vault. In case the Password Manager is not available on this device authentication will fail, because the passkey is not accessible.

• Fallback Handling: If the passkey ceremony fails or aborts (e.g., the user cancels or the password manager has the wrong credential), RPs should gracefully revert to a traditional username/password or MFA-based flow.

• Lower Complexity: This button-based approach is relatively straightforward to implement. RPs do not need to do extensive checks to see if a passkey is “likely” to exist.

In this approach, from a passkey implementation perspective, there are no implications directly affecting the passkey ceremony.

4.1.2 Identifier-First#

In an identifier-first flow, you request the user’s email or username before initiating the passkey ceremony. Once the system has the identifier, it can attempt to detect if a passkey is available for that account and is likely accessible. Implications are here:

• Auto-Detection: This flow can improve user experience by automatically prompting for a passkey without the user having to worry about where the passkey is stored. In case a passkey cannot be available due environment limitations the user can directly be redirected to the fallback.

• System Constraints: You must incorporate logic to understand whether the current environment supports passkeys in a third-party or OS-level manager. Using the table in Section 2.2 can help gauge whether the user’s platform (iOS, Android, Windows, etc.) can actually provide the passkey.

• Enhanced Complexity: This approach requires more sophisticated checks on the server side (e.g., looking up a user’s passkey registration status) and on the client side (e.g., determining if the OS or the password manager is capable of presenting the passkey).

In the Identifier-First approach, there are several implications because you need to be aware of the accessibility of passkeys and continuously monitor their development and changes.

4.2 List Passkeys with Password Manager Logo#

RPs can show which password manager stored a passkey by reading the AAGUID at registration and mapping it to a name and logo from a community registry. This lets users identify and manage their passkeys and makes clear where a passkey lives. An RP cannot detect which credential manager will answer before the prompt opens. It only learns it from the AAGUID, once the passkey has been created on the client side and sent to the server for storage. Here is how to achieve this:

• Differentiating Passkeys via AAGUID: The Authenticator Attestation GUID (AAGUID) uniquely identifies the authenticator model used to create a passkey. By extracting the AAGUID during the registration ceremony and associating it with the stored passkey, RPs (Relying Parties) can differentiate passkeys. The AAGUID is particularly useful for mapping metadata such as the device model, manufacturer and capabilities (e.g., platform or roaming authenticators). These details enrich the user experience by providing clear distinctions between different passkeys.

• Retrieving Metadata and Logos: To visually represent passkeys, the repository Passkey.dev offers a curated JSON file containing AAGUID mappings. This file includes metadata from the MDS (Metadata Service) and additional data for First-Party- and Third-Party-Provider. By leveraging this resource, developers can display the device logo, model name and security attributes, ensuring a user-friendly passkey management interface.

Most of the time, a passkey list is among the standard features of any passkey implementation; therefore, this should not create additional overhead. In general, it is helpful to communicate where a passkey has been stored, even during passkey creation. Show the provider name and logo in the confirmation message and in the passkey list, for example "Passkey created with 1Password". Let users rename the entry and show when it was created and last used. The technical prerequisites:

The same AAGUID can also drive policy. Regulated relying parties such as banks sometimes want to restrict which providers may register. Keep in mind that an AAGUID without trusted attestation is a self-asserted label, which makes it a good basis for policy and telemetry and a weak security barrier on its own. As defined in the W3C WebAuthn Level 3 specification, the AAGUID is part of the attested credential data. Our guide to restricting passkey authenticators by AAGUID covers the policy model, the provider-by-provider assessment and the relative impact of a restriction.

4.3 How Corbado can help#

Corbado Connect decides what to do about third-party password managers before the prompt fires, on top of your existing login. You get an up-to-date view of which passkeys are reachable on the device in front of you without maintaining it yourself.

See how Corbado Connect ships this →

• Passkey Intelligence: tracks OS and browser versions and whether the credential provider is a browser, the platform or a third-party manager, to judge if a stored passkey is reachable.
• Adaptive workflow: after a successful passkey login, Corbado records the user, device and environment. If attempts keep failing, the flow falls back automatically and that environment stops being asked.
• Identifier-first: components with the server-side and client-side logic for an identifier-first flow.
• Authenticator policy: in regulated environments, Connect lets you allow or block authenticators by AAGUID during enrollment. The AAGUID policy guide explains how to design the rules.
• Passkey list: the CorbadoConnectPasskeyList component lets users view, add and delete their passkeys on your account page, including those in third-party managers.

Corbado Observe, the authentication observability layer, reports which managers your users bring, where each succeeds and what a restriction would cost.

5. How should relying parties approach password managers?#

Offer passkeys on every platform that can plausibly support them and monitor for friction. This optimistic but cautious approach works because most password managers behave consistently, while a few limitations apply to the identifier-first approach, namely iOS 17+ and Android 14+ for third-party managers. In regulated environments, qualify providers instead of blocking them wholesale.

The identifier-first approach has the details.

This is true for nearly all password managers. At the time of the last update there are the following additional limitations that should be taken into account (October 2026):

Additional Limitations for Identifier-First Approach:

• Google Password Manager: Google Password Manager is available on Windows and MacOS starting from Chrome 129 and on iOS & iPad OS from Chrome 132 (can also be used as Third-Party-Password Manager). Keep in mind to offer such passkeys only on browser versions new enough or fallback to cross-device usage.

• Samsung Pass: Samsung Pass passkeys are only available on Samsung Devices and should only be offered there.

• Apple Password App: Apple Password App with passkeys cannot be used outside the Apple platforms.

• Microsoft Password Manager: Edge saves and syncs passkeys in Microsoft Password Manager since Edge 142 (November 2025), for personal Microsoft accounts only. Work and school accounts and mobile devices are not supported yet.

Password manager ecosystems evolve faster since passkeys. Keep an eye on new releases from major players (Google, Apple, Samsung and third-party managers) to ensure your integration remains compatible and user-friendly and no dead ends exist. Microsoft has since shipped both synced passkeys in Edge and third-party provider support in Windows 11, so Windows now behaves much more like macOS.

Regulated environments: if you must limit which providers your customers can use, prefer first-party providers at onboarding and qualify third-party managers by implementation instead of blocking them wholesale. Providers differ more by surface (extension vs. native app) than by brand. NIST's appendix on syncable authenticators allows appropriately configured syncable passkeys up to AAL2, and the FIDO Metadata Service covers attested security keys. See how to restrict passkey authenticators by AAGUID for the data behind this recommendation.

6. Conclusion#

Passkeys are changing authentication by simplifying how credentials are stored, synced and accessed across devices. Both password managers and Relying Parties (RPs) play key roles in ensuring a seamless user experience for passkeys with password managers. In this article we have answered the two main questions:

• How do password managers handle passkeys across different devices? Password managers, whether built into operating systems (e.g., Google Password Manager, Apple Password App) or third-party tools (e.g., 1Password), store passkeys securely and sync them across devices. They integrate with platforms like iOS and Android through system APIs and provide smooth experiences on desktops via browser extensions. By managing passkeys behind the scenes, they make authentication simple and consistent for users that want to use Third-Party-Password Managers.

• What are the implications for RPs in supporting passkeys? RPs can choose between a Passkey Button, which offers simplicity but may result in lower usage, and an Identifier-First Flow, which automatically detects available passkeys after a user provides their email or username. The Identifier-First approach offers a smoother experience and higher adoption but requires more planning to integrate Password Managers. In all cases adding features like logos and metadata improves clarity and user confidence where passkeys have been stored, while fallback options ensure accessibility for all users.

Passkeys represent the future of secure, user-friendly authentication. By understanding how password managers work and choosing thoughtful implementation strategies, RPs can provide a smooth login experience, encourage passkey adoption and lead the way in modern authentication practices.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (more than 80% passkey activation rate). Talk to a Passkey Expert →

Frequently Asked Questions#

How do I decide between a passkey button and an identifier-first flow for my login page?#

A Passkey Button is simpler to implement and requires no platform capability checks, but delivers low passkey login adoption. An Identifier-First flow automatically detects available passkeys after collecting the user's email, yielding very high adoption, but requires server-side and client-side logic to verify platform support such as iOS 17+ or Android 14+.

Which iOS and Android versions support third-party password managers like 1Password or Bitwarden for passkeys?#

Third-party password managers require iOS 17+ via the Password Manager API or Android 14+ via the Credential Manager API. Older mobile OS versions only support first-party providers such as iCloud Keychain on iOS or Google Password Manager on Android. Browser extensions, which work on desktop, are not a viable passkey integration path on mobile.

What browser version requirements must I account for when offering Google Password Manager passkeys in an identifier-first flow?#

Google Password Manager supports passkeys from Chrome 129 on Windows and macOS and from Chrome 132 on iOS and iPadOS. RPs using an Identifier-First flow must verify the user's Chrome version meets these thresholds before presenting GPM passkeys, or fall back to cross-device authentication for unsupported versions.

Does Samsung Pass work across all Android devices and should I surface it to all users?#

Samsung Pass passkeys are only available on Samsung devices and should only be offered in that context. RPs implementing an Identifier-First flow must detect the Samsung device environment and avoid presenting Samsung Pass passkeys to users on non-Samsung Android hardware to prevent authentication dead-ends.

How can I display which password manager stored a user's passkey in my account management interface?#

Extract the AAGUID (Authenticator Attestation GUID) during the registration ceremony and look it up in the passkey-authenticator-aaguids JSON file maintained at passkey.dev. This file maps AAGUIDs to password manager logos, device model names and security attributes, enabling clear visual distinctions between passkeys in a management UI.

Can I restrict which password managers or passkey providers my users can register?#

Yes, by comparing the AAGUID from the registration response against an allowlist or blocklist. The AAGUID is only a reliable control when you also validate attestation, and consumer synced passkeys such as iCloud Keychain and Google Password Manager do not ordinarily deliver an attestation statement. Use the AAGUID for policy and telemetry. Require user verification and run a report-only pilot before enforcing.

Keep in mind that the passkey is still created on the client when the server rejects it. It stays in the user's provider unless it is removed through the WebAuthn Signal API, which often does not work for third-party credential managers. See our guide to restricting passkey authenticators for the full policy model.