Reference Guide

Passkey Management

Five stores, three of which sync, none of which fully interoperate — with recovery as the unsolved middle. Where a passkey lands is decided the first time you create one, and migration is the part that still does not work.

← Back to Reference Hub

Best for: Someone who is genuinely all-Apple and intends to stay that way.

Sync scope: Apple devices only, end-to-end encrypted
Requires: 2FA on the Apple Account plus a device passcode
Managed in: the standalone Passwords app (iOS/iPadOS/macOS 18+)
Third-party AutoFill providers supported, several at once
CXP import and export shipped in iOS/macOS 26 — biometric-gated, app-to-app
Attestation: none — consumer passkeys report a zeroed AAGUID

Limitations: On Windows it is reachable only through iCloud Passwords plus a browser extension — there is no OS integration. The zeroed AAGUID means an enterprise relying party cannot verify which authenticator holds the key, so iCloud Keychain is structurally unusable where attestation is a requirement.

SyncsApple onlyCXP on iOS 26

Best for: Windows users who understand that "Microsoft passkeys" is not one thing.

(1) Windows Hello — device-bound, Hello container, no sync
(2) Microsoft Password Manager — syncs across Windows via a personal Microsoft account
(3) Third-party as system provider — KB5068861, Windows 11 24H2 and 25H2
In mode 3, Hello does the biometric unlock; the third-party app holds the credential
Enterprise: Entra passkeys in Windows Hello reached GA from late April 2026 (worldwide ~mid-June; GCC High/DoD Oct 2026)
Microsoft mandates passkeys in Entra by February 2027 and is retiring SMS and voice MFA

Limitations: Entra passkeys in Windows Hello are device-bound only — register per device, no sync, no attestation support, and they do not cover device sign-in. Windows Hello for Business remains the recommendation for managed devices. Microsoft has shipped no export mechanism on any platform, and third-party provider mode needs the full desktop app rather than a browser extension.

Three storesNo exportEntra deadline Feb 2027

Best for: Anyone whose common denominator across machines is Chrome rather than an operating system.

Runs on all six platforms: Android, ChromeOS, Windows, macOS, iOS/iPadOS, Linux
Rides Chrome, not the OS — the browser is the common denominator
Android 14+ can hand the default to another provider via Credential Manager
Android 17 shipped CXP: ProviderEventsManager importCredentials / registerExport
Theft hardening: "Mark as lost" in Find Hub, harder PIN throttling
Advanced Protection uses FIDO2 credentials as the enrollment baseline

Limitations: On iOS it only works if Chrome is set as an autofill provider in System Settings — otherwise passkeys land in iCloud Keychain and the user usually does not notice. On macOS the GPM-or-Keychain choice is made per credential, which is how a collection ends up split. See the callout below for the August 2026 Unit 42 research into GPM sync-key handling on Windows.

SyncsAll six platformsSee security note

Best for: Anyone who lives on more than one ecosystem — this is the configuration that survives contact with reality.

Indifferent to platform — the same vault on Windows, macOS, Linux, iOS, and Android
System-provider status: Windows 11 (Nov 2025), Android 14+, iOS AutoFill
1Password and Bitwarden co-authored the FIDO Alliance CXP specification
Smaller managers — Bitwarden, Proton Pass, KeePass — still allow plaintext file export
Recovery runs through the vault password and the recovery kit

Limitations: The trade-off is not that the single point of failure goes away, it is that it moves — from the platform vendor to the manager vendor. The vault password and recovery kit become the master key for everything. The majors deliberately do not offer plaintext export, so leaving a major manager on desktop is currently not a supported operation.

SyncsCross-platformVendor is the master key

Best for: Break-glass recovery, and any enterprise that needs to prove which authenticator holds the key.

Device-bound: no sync, no cloud, nothing to breach remotely
Attestation that an enterprise relying party can verify
Storage is finite: ~25 discoverable credential slots on older YubiKey 5s, 100 on firmware 5.7+
A human present to touch the key is a workable path for supervised automation
Standing advice: enroll two keys everywhere

Limitations: No recovery. Lose the key and the credentials on it are gone — which is why the two-key rule is not optional advice. When the slots fill up, adding a credential means deleting one.

Device-boundAttestationNo recovery

Best for: Galaxy owners who want to know why they were asked three times where to save a passkey.

Stores passkeys and plugs into the Android Credential Manager
Now under the Samsung Wallet umbrella
On a Galaxy it competes with GPM and any installed third-party manager
Behaves as a standard Credential Manager provider to the relying party

Limitations: It is a fourth default on a device that already had three. The risk is not the store itself but the split collection that results when the user picks a different provider each time the prompt appears.

Android onlyFourth default

Best for: Workforce credentials, where the requirements are the inverse of the consumer ones.

Requirement is inverted: device-bound plus attestation, not synced plus convenient
Attestation proves which authenticator holds the credential
Entra is both an IdP here and one of the three Microsoft stores
Hardware keys are the store that satisfies the enterprise requirement cleanly

Limitations: The result is two worlds that cannot see each other: workforce credentials and the same employees’ personal passkeys live in separate systems with no bridge. An enterprise cannot attest a consumer store, and a consumer store will not become attestable, because the zeroing is the feature.

Device-boundAttestationCannot see personal passkeys

The August 2026 Unit 42 research into Google Password Manager on Windows

In August 2026, Palo Alto Unit 42 published three attack paths against Chrome’s Google Password Manager on Windows machines with a TPM. Pass-ta-key extracts Chrome’s device identity key and signs requests without the User Verified flag. Silver Pass-ta-key forces re-enrollment in order to install an attacker verification key. Golden Pass-ta-key extracts the 32-byte Security Domain Secret from Chrome memory and decrypts synced passkeys. State the scope precisely in both directions: all three require malware already running on the machine, so this is a post-compromise escalation rather than a remote attack — and equally, no CVEs have been assigned, Chrome 142 was vulnerable, only partial fixes are documented, and Google has not publicly commented. This does not break passkeys as a standard. It breaks Google Password Manager’s sync-key handling on Windows, and that distinction is the whole point.

Capability	iCloud Keychain	Microsoft (Hello / MPM)	Google Password Manager	Third-party managers	Hardware keys
Sync scope	Apple devices only	Hello: none · MPM: Windows only	All six platforms	Every platform	None — device-bound
Third-party provider support	Yes — AutoFill, several at once	Yes — KB5068861, Win 11 24H2/25H2	Yes — Credential Manager, Android 14+	N/A — is the third party	N/A — is the authenticator
CXP portability	iOS 26 yes · macOS API unimplemented	None on any platform	Android 17 yes · desktop no	Co-authored CXP; mobile only in practice	No — nothing to export
Recovery model	Apple Account — lose it, lose all	Hello: none · MPM: Microsoft account	Google account	Vault password + recovery kit	None — enroll two keys
Attestation available	No — AAGUID zeroed	No — Entra Hello passkeys lack it	No	No	Yes — verifiable
Works on Linux	No	No	Yes — rides Chrome	Yes	Yes — the practical answer on Linux

Three of these stores sync and none of them fully interoperate. CXP — the FIDO Alliance specification that was meant to make passkeys movable — works on exactly two platforms as of mid-2026, iOS 26 and Android 17, both mobile. Desktop has nothing: the macOS ASCredentialImportManager API exists but no major manager has shipped an implementation, so the export menus are non-functional, and Windows has zero CXP implementation. Edge deliberately blocks passkey export everywhere and supports import only on iOS.

Mac + Windows + Android, and you want one store for all of itA third-party manager — 1Password or Bitwarden. iCloud Keychain reaches Windows only through iCloud Passwords plus a browser extension, and Microsoft Password Manager does not leave Windows. Google Password Manager is the only platform store that spans all three, but on macOS you choose GPM or iCloud Keychain per credential, which is how collections split. Add one hardware key as break-glass. Decide before you create the first passkey — migration is the part that still does not work.

Phone lost or replaced — what survivesAnything synced survives, anything device-bound does not. iCloud Keychain restores on the next Apple device once 2FA and the passcode are satisfied; Google Password Manager restores through the Google account, and on Android you should first use "Mark as lost" in Find Hub, which biometrically locks the device even if the thief knows the PIN. A third-party vault restores from the vault password and recovery kit. Windows Hello credentials do not survive at all — they live in the Hello container on that machine. Hardware keys are unaffected because they were never on the phone, which is exactly why the two-key rule exists.

Enterprise facing the February 2027 Entra passkey mandateWindows Hello for Business on managed devices, plus hardware keys where attestation genuinely matters. Entra passkeys in Windows Hello reached GA from late April 2026 (worldwide around mid-June, GCC High and DoD in October 2026) but they are device-bound only: register per device, no sync, no attestation support, and they do not cover device sign-in. Microsoft is also retiring SMS and voice MFA, so plan the recovery path deliberately — removing the weak fallback without building a strong one is how a mandate becomes a helpdesk event. Note that employees’ personal passkeys are in a world your IdP cannot see, and will stay there.

Your passkey button fails inside an in-app browserDetect the WebView and route out of it. Instagram, TikTok, Facebook, and LinkedIn WebViews either fail silently or throw NotAllowedError; the user sees a button that does nothing. Send them to the default browser or to the native Credential Manager instead. While you are there, check the neighbours: cross-origin iframes need allow="publickey-credentials-get" plus a matching Permissions-Policy header, and Safari rejects create() in an iframe outright, so enrollment must be top-level. If creation throws SecurityError, look at the RP ID — a public-suffix domain breaks it, and *.vercel.app preview domains break passkey creation for exactly this reason. You need a custom domain.

An agent or CI job hits a passkey wall and has no handsStop trying to get through the passkey. A passkey requires a user-verification gesture on a device with a biometric sensor or PIN entry, and a browser agent, a headless CI job, or an automated test has none. There is no supported machine path through a synced passkey. The three workable patterns are service accounts with API tokens, device-bound hardware keys where a human is present to touch them, or a password/OTP fallback reserved for automated paths — which is itself a security trade-off, and should be made deliberately rather than by accident.

Choose your provider before you create your first passkey

Migration is the part that still does not work. CXP runs on iOS 26 and Android 17 and nowhere else — macOS has an API no major manager has implemented, Windows has no implementation at all, and Edge blocks export everywhere. Whichever store catches your first passkey is likely to keep it, so the choice is effectively permanent even though nothing in the interface says so. For anyone on more than one ecosystem, a cross-platform manager plus one hardware key as break-glass is the configuration that survives contact with reality. And treat recovery as the design problem it is: a synced passkey is only as strong as the account holding it, so losing the Apple ID or Microsoft account loses every passkey at once — while a single device-bound passkey with no fallback is the most common Windows Hello lockout.

Passkey Management

Apple — iCloud Keychain

Microsoft — three separate stores

Google — Google Password Manager

Third-party managers

Hardware keys

OEM — Samsung Pass

Enterprise IdPs

The August 2026 Unit 42 research into Google Password Manager on Windows

Choose your provider before you create your first passkey