---
url: 'https://www.corbado.com/blog/passkey-implementation-password-managers'
title: 'Passkeys and Password Managers: Relying Party Guide'
description: 'Discover passkey implementation implications by password managers across platforms. This guide helps relying parties (websites / apps) to handle them properly.'
lang: 'en'
author: 'Vincent Delitz'
date: '2025-01-20T13:40:57.787Z'
lastModified: '2026-03-27T07:01:09.987Z'
keywords: 'password manager passkey integration, third-party passkey providers, browser extension passkey integration, identifier-first authentication flow'
category: 'Passkeys Strategy'
---

# Passkeys and Password Managers: Relying Party Guide

## Key Facts

- RPs choose between a **Passkey Button** (simple, low adoption) and an **Identifier-First
  flow** (very high adoption) when implementing passkeys with password manager support.
- Third-party password managers on mobile require **iOS 17** (Password Manager API) or
  **Android 14** (Credential Manager API); browser extensions are not viable on either
  mobile platform.
- **Google Password Manager** supports passkeys from Chrome 129 on desktop and Chrome 132
  on iOS, requiring browser version checks before offering these flows to users.
- The **AAGUID** extracted at registration maps each passkey to a specific password
  manager logo and metadata, clarifying which provider stored the credential in account
  management UIs.

## 1. Introduction

Since the introduction of passkeys, the
[password manager](https://www.corbado.com/blog/passkeys-vs-password-managers) landscape has changed. As passkeys
gain traction as a secure,
[user-friendly authentication](https://www.corbado.com/faq/passkey-user-experience-benefits-non-technical-audience)
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](https://www.corbado.com/blog/webauthn-errors) and
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android), and the strategies RPs can adopt to
optimize their passkey integration with password managers while ensuring a seamless user
experience.

## 2. Password Manager 101 for Passkeys

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.

### 2.1 How Password Managers Work with Passkeys

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](https://www.corbado.com/blog/passkey-login-best-practices) 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](https://www.corbado.com/blog/passkey-creation-best-practices), retrieval and feature
  detection workflows. This ensures compatibility without requiring users to manually
  manage their passkeys.

- **Leverage Conditional UI:** By interacting with
  [Conditional UI](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/passkey-providers), which are built directly into operating
systems (e.g., [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) on
[iOS](https://www.corbado.com/blog/webauthn-errors) or
[Google Password](https://www.corbado.com/blog/how-to-use-google-password-manager) Manager on
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-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.

[Watch on YouTube](https://www.youtube.com/watch?v=V1Pc4Gl0xKc)

### 2.2 Browser Extensions vs. Operating System Integration

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:

| **Platform**       | **Integration Requirements**                                                        | **Key Challenges**                                                                                   | **Notes**                                                                                 |
| ------------------ | ----------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
| **iOS (≥ 17)**     | Third-party password managers must integrate via the OS-level Password Manager API. | Browser extensions are not supported, making native integration essential for passkey functionality. | Limited to iOS versions that support the Third-Party Password Manager API.                |
| **Android (≥ 14)** | Uses Android’s Credential Manager API for third-party integration.                  | Similar to iOS, browser extensions are not viable. Requires native integration for passkey handling. | Works well for devices running Android ≥ 14; older versions lack passkey manager support. |
| **Windows**        | Browser extensions enable passkey handling.                                         | Requires robust browser integration to work across Chrome, Edge, Firefox, and other major browsers.  | Microsoft has announced Third-Party-Provider support with synched passkeys for 2025.      |
| **macOS**          | Browser extensions offer compatibility across supported browsers.                   | Like Windows, browser support is crucial for a smooth experience.                                    | Native implenentation is available from MacOS ≥ 14 but not yet used.                      |
| **Linux**          | Typically out of scope for mainstream passkey support.                              | Lack of OS-level integration; relies on advanced users and community-developed tools like KeePassXC. | Linux users are often "expert" users managing their own setups.                           |

Mobile operating systems, such as [iOS](https://www.corbado.com/blog/webauthn-errors) and
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-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](https://www.corbado.com/blog/passkey-providers) such
as Apple’s [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) on iOS or
[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager) on Android could
handle [passkey creation](https://www.corbado.com/blog/passkey-creation-best-practices) and management. Over
time, both ecosystems recognized the need to support third-party
[passkey providers](https://www.corbado.com/blog/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](https://www.corbado.com/blog/how-to-use-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** 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](https://www.corbado.com/blog/how-to-use-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](https://www.corbado.com/blog/passkey-creation-best-practices) 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](https://www.corbado.com/blog/ios-18-passkeys-automatic-passkey-upgrades), 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](https://www.corbado.com/glossary/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](https://www.corbado.com/blog/user-transition-passkeys-expert-strategies) 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](https://www.corbado.com/glossary/icloud-keychain) to be used on Windows and/or Android through
a third-party provider approach, but the first step has been made.

## 3. The Password Manager Landscape for Passkeys

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](https://www.corbado.com/blog/samsung-passkeys) Pass that work a bit diffently. For the time being Apple
Password App cannot be classified as
[password manager](https://www.corbado.com/blog/passkeys-vs-password-managers) 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](https://psono.com/)), offering insight into their
cross-platform compatibility and specific requirements.

![password manager landscape](https://www.corbado.com/website-assets/password_manager_landscape_174c8b5111.png)

The [password manager](https://www.corbado.com/blog/passkeys-vs-password-managers) 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.

## 4. Passkey Implementation Implications

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.

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

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](https://www.corbado.com/blog/passkey-login-best-practices) or an identifier-first workflow each
offer unique advantages and challenges.

#### 4.1.1 Passkey Button

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](https://www.corbado.com/glossary/allowcredentials)) in addition those implementations usually
also rely on [Conditional UI](https://www.corbado.com/glossary/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.

#### 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](https://www.corbado.com/faq/identifier-first-approach-passkey-login), 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

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](https://www.corbado.com/glossary/authenticator)
  [Attestation](https://www.corbado.com/glossary/attestation) GUID (AAGUID) uniquely identifies the
  [authenticator](https://www.corbado.com/glossary/authenticator) model used to
  [create a passkey](https://www.corbado.com/blog/passkey-creation-best-practices). By extracting the
  [AAGUID](https://www.corbado.com/glossary/aaguid) during the registration ceremony and associating it with the
  stored passkey, RPs (Relying Parties) can differentiate passkeys. The
  [AAGUID](https://www.corbado.com/glossary/aaguid) is particularly useful for mapping metadata such as the
  device model, manufacturer, and capabilities (e.g., platform or roaming
  [authenticators](https://www.corbado.com/glossary/authenticator)). 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](https://github.com/passkeydeveloper/passkey-authenticator-aaguids/blob/main/combined_aaguid.json)
  offers a curated JSON file containing [AAGUID](https://www.corbado.com/glossary/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.

### 4.3 How Corbado Can Help

Corbado’s platform streamlines [passkey adoption](https://www.corbado.com/blog/passkey-adoption-business-case) 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](https://www.corbado.com/blog/apple-passkeys-integration) 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](https://www.corbado.com/blog/passkey-login-best-practices), 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.

## 5. Recommendation for RPs: Be Optimistic but cautious

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](https://www.corbado.com/faq/identifier-first-approach-passkey-login)
(iOS17+ / Android 14+).

|                                        | **Passkey Button** | **Identifier First**       |
| -------------------------------------- | ------------------ | -------------------------- |
| **Passkey Login Adoption**             | Low                | Very High                  |
| **SMS cost savings**                   | Low                | Very High                  |
| **Implement Passkey List with Icons**  | Yes                | Yes                        |
| **Provide Fallback on Error/Abortion** | Yes                | Yes                        |
| **Automatically offer for Login**      | No                 | Yes (iOS 17+, Android 14+) |
| **Additional Limitations**             | None               | See below (GPM/Samsung)    |

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](https://www.corbado.com/blog/samsung-passkeys) Pass passkeys are only available on
  [Samsung](https://www.corbado.com/blog/samsung-passkeys) 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.

## 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](https://www.corbado.com/blog/1password-passkeys-best-practices-analysis)), 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](https://www.corbado.com/blog/passkey-login-best-practices), 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](https://www.corbado.com/faq/identifier-first-approach-passkey-login) 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](https://www.corbado.com/faq/passkey-user-experience-benefits-non-technical-audience).
By understanding how password managers work and choosing thoughtful implementation
strategies, RPs can provide a smooth login experience, encourage
[passkey adoption](https://www.corbado.com/blog/passkey-adoption-business-case), and lead the way in modern
authentication practices.

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