Passkeys and Password Managers: Relying Party Guide

Since the introduction of passkeys, the password manager landscape has changed. As passkeys gain traction as a secure, user-friendly authentication method, password managers play an important role in in the passkey ecosystem between users and relying parties (RPs). In this article, we will address two key questions:

• 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.

Passkeys have introduced a new way in authentication, expanding the way password managers function. As they integrate passkey support, they are tasked with securely storing, syncing, and facilitating access across devices and platforms for private keys. This section explores how password managers handle passkeys, their reliance on browser extensions, OS-level integrations, and critical aspects like the interception of JavaScript for a seamless user experience.

Password managers function as the bridge between a user’s credentials and Relying Parties (RPs). Their role includes on operating system level:

• 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 passley JavaScript functions such as navigator.credentials.get(), navigator.credentials.create() and navigator.credentials.get() 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.

Password managers interact with passkeys differently across platforms due to varying levels of OS support and technical constraints. Below is a summary of these differences:

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.

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.

The Google Password Manager 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.

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.

• Cross-Platform Expansion: While primarily available on Apple devices, Apple has laid the groundwork for potential expansion into other platforms, making passkey interoperability a likely future development.

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.

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 diffently. 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, 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.

How Password Manager impact your implementation is largely determined by your current passkey implementation appraoch. 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.

As organizations consider adopting passkeys, understanding the trade-offs between implementation approaches is crucial for balancing user convenience and technical feasibility. Two primary flows using a direct passkey button or an identifier-first workflow each offer unique advantages and challenges.

In this model, you provide a direct “Sign in with passkey” button on your login screen. Behind the scenes, this triggers a passkey ceremony (with an empty allowCredentials) in addition those implementations usually also rely on Conditional UI. Implications are here:

• 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.

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.

To ensure users can easily identify and manage their Password Manager passkeys, integrating identifiable logos and metadata enhances clarity and usability. Here’s how this can be achieved:

• 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.

Corbado’s platform streamlines passkey adoption by actively monitoring passkey ecosystem capabilities, including those offered by various password managers. Our solution:

• Passkey Intelligence: We maintain an up-to-date database of platform capabilities (e.g., whether iOS 17 is present, if the user’s device supports Android ≥ 14, if Chrome is at version 129+). This intelligence helps determine if passkey that is stored in a third-party password manager is likely accessible on a given device.

• Adaptive Workflow: Once a user completes a successful passkey login, Corbado creates an association between the device and the environment. If multiple attempts fail (indicating the passkey is unavailable) the system can auto-fallback to alternative flows or “blacklist” that environment from attempting passkey flows in the future, reducing friction.

• Identifier-First: If your organization needs a more advanced identifier-first flow, Corbado provides server-side and client-side logic via Components. These dynamically check whether a passkey is available and accessible based on the user’s platform, browser and then the user is guided accordingly.

• Passkey list: The CorbadoConnectPasskeyList component is a user interface component designed by Corbado to enable enterprises to integrate passkey management functionality into their systems easily. This component allows end users to view, add, and delete their passkeys directly from their account management pages. It adapts dynamically to the user's platform and environment, ensuring compatibility across devices and browsers. This also includes Password Managers.

By integrating Corbado, you gain both real-time insights into the ever-shifting passkey/password manager landscape and your tooling automatically adapts to new versions without needing to change your systegm. This ensures that RPs can confidently implement Identifier-First passkey flows minimizing user friction and support overhead.

We recommend an optimistic approach in which you offer passkeys on all platforms that can plausibly support them, while monitoring for potential friction. There are some limitations for Identifier-First approach (iOS17+ / Android 14+).

This is true for nearly all Password Manager, at the time of the last update there are the follwing additional limitations that should be taken into account (January 2025):

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.

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 deadends exist. This will get even more interesting when Microsoft releases synched passkeys on Windows which will also come with Third-Party-Provider support.

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.