Passkey Providers: Sync, Recovery and Enterprise Controls

A synced passkey is only as strong as the provider that stores it, because the provider decides where the private key travels, how a user gets it back on a new device and what an organisation can see or control. The cryptography of WebAuthn is the same everywhere, but sync scope, recovery factors and enterprise controls differ by platform, and those differences decide whether a passkey belongs on a personal phone, a managed laptop or a security key. This guide explains the provider security model in practitioner terms, what the relying party can and cannot learn about a provider (AAGUIDs, backup flags, attestation), how the WebAuthn Signal API keeps provider state in step with your accounts, and the documented behaviour of the three major platform providers. It builds on the consumer-level Passkeys for Everyone Guide and is written for identity architects, IAM engineers and security teams setting passkey policy.

Source note: standards and vendor facts on this page are taken from the official documents listed under Standards and references, checked in November 2026. Provider policy choices, rollout steps and checklist items are NHI Mgmt Group recommendations. Confirm against the official text before relying on it.

Platforms are listed alphabetically; the order is not a ranking.

Key takeaways

The sync fabric is part of your authenticator. NIST SP 800-63B-4 treats synced passkeys as AAL2 at most and sets requirements on the sync fabric itself: encrypted keys, access control, and AAL2 authentication to add new devices.
Recovery is the provider's weakest link. Each provider protects key recovery with a device passcode or similar knowledge factor plus attempt limits; your account recovery must not undo that.
An AAGUID without attestation is a label, not proof. WebAuthn Level 3 no longer zeroes the AAGUID when attestation is none, so you can see which provider a user chose, but only verified attestation proves it.
Enterprise control comes from the identity provider and device management. Policy on passkey type, attestation and allowed providers is set where the relying party checks registrations, supported by managed-device features on each platform.
Use the Signal API to keep providers clean. signalUnknownCredential, signalAllAcceptedCredentials and signalCurrentUserDetails let the relying party tell providers about deleted credentials and renamed accounts.

What a passkey provider is responsible for

A provider (also called a credential manager or authenticator) creates the key pair, stores the private key, unlocks it with the user's biometric or PIN, and, for synced passkeys, copies it to the user's other devices. In WebAuthn terms, a synced passkey is a multi-device credential (Backup Eligible flag set) and a device-bound one is a single-device credential. NIST's syncable authenticator appendix to SP 800-63B-4 is the clearest statement of what a provider must do for a synced passkey to count at AAL2:

Provider area	NIST SP 800-63B-4 syncable appendix	Question to ask of any provider
Storage in the sync fabric	Keys exported to a sync fabric shall only be stored encrypted, and should be encrypted with a user-controlled secret	Is the encryption end to end, with keys the provider cannot read?
Access to the sync fabric	Keys in the sync fabric shall be protected by access control mechanisms; AAL2 authentication should be required to add new authenticators for access to the sync fabric	What does an attacker need to add a new device to the user's provider account?
Federal enterprise use	Access controlled by agency-managed accounts; devices protected by mobile device management or configuration controls that prevent syncing keys to unauthorised devices or fabrics	Can sync be limited to managed accounts and managed devices?
Assurance ceiling	Syncing violates AAL3 non-exportability; syncable authenticators may be used up to AAL2	Which users need device-bound passkeys instead?
Recovery	Bind multiple authenticators at AAL2 and above to support recovery	Does every user have a second way in that is not a password?

For accounts that need AAL3, a synced provider is the wrong tool whatever its quality; see the Device-Bound Passkeys guide.

What the relying party can see about a provider

When a user registers a passkey, the relying party receives authenticator data and an attestation object. Three fields matter for provider policy:

Field	What it says	How far to trust it
AAGUID	A 128-bit identifier for the authenticator model or provider. WebAuthn Level 3 lists as a change that the AAGUID is no longer zeroed when attestation preference is `none`	Useful to label credentials ("saved in provider X") in account settings. Without verified attestation it is self-reported and can be spoofed by a modified client
BE and BS flags	Backup Eligible (bit 3) is fixed at creation; Backup State (bit 4) shows whether the credential is currently backed up	Tells you synced or not as reported by the authenticator. NIST says verifiers may use BE to restrict syncable authenticators, and that agencies should not condition acceptance on BS for public-facing applications
Attestation statement	With `direct` or `enterprise` conveyance, a signature chaining to the manufacturer	Strong evidence of model, but many synced providers do not return attestation; Microsoft's Entra documentation states that synced passkeys do not support attestation

The practical position for most relying parties: record the AAGUID, BE and BS for every credential and show the provider name to the user, but do not treat an AAGUID list as a security boundary unless attestation is enforced. Microsoft's Entra guidance makes the same point, advising that AAGUID lists be used as a policy guide rather than a strict control when attestation is not enforced. See the FIDO2 and WebAuthn Internals Guide for the data structures.

Keeping providers in step: the WebAuthn Signal API

Providers do not know when a relying party deletes a credential or renames an account, so users are offered dead passkeys and stale usernames. WebAuthn Level 3 adds three static signal methods on PublicKeyCredential:

signalUnknownCredential: tells providers that a credential ID was not recognised, for example after the user deleted it. It does not require the full credential list, which avoids leaking account information to an unauthenticated caller, so it suits a failed sign-in page.
signalAllAcceptedCredentials: sends the full list of credential IDs accepted for a user handle, so providers can hide or remove others. Call it only after the user has signed in.
signalCurrentUserDetails: updates the user name and display name a provider shows, for example after an email change.

Two properties shape how you use them. Signals are opportunistic: the specification states that the returned promise only means the options were well formed, not that any provider acted, and authenticators may ignore or ask the user about a change. So signals are hygiene, not revocation. Revoking a credential still means deleting it server side and rejecting it at sign-in. Second, related origin rules apply, so the call must come from an origin entitled to the RP ID.

Platform providers

The sections below describe each provider's own documentation as of November 2026. Each covers sync scope, recovery and the controls an organisation can apply.

Apple (iCloud Keychain)

Sync scope: Apple's "About the security of passkeys" states that passkeys sync across a user's devices using iCloud Keychain, which is end-to-end encrypted with keys not known to Apple, and that any Apple Account using iCloud Keychain requires two-factor authentication.
Recovery: passkeys can be recovered through iCloud Keychain escrow. Apple states the escrowed keychain is protected by a strong passcode, that devices allow only 10 attempts, and that after the tenth failed attempt the escrow record is destroyed. Signing in on a new device requires the Apple Account password and a six-digit verification code.
Enterprise controls: Apple Platform Deployment documents a Passkey Attestation declarative configuration (iOS 17, iPadOS 17 and macOS 14 user scope, through Device Enrollment or Automated Device Enrollment) that lets an organisation verify a passkey was created on a managed device, using an attestation identity delivered by ACME, SCEP or PKCS #12. Only relying party domains listed in the configuration can request that attestation. See the Apple Declarative Device Management and Managed Device Attestation Guide.

Google (Google Password Manager)

Sync scope: Google's developer documentation states that Google Password Manager synchronises passkeys between the user's Android devices and Chrome browsers, that passkeys are encrypted on-device before syncing, and that secrets are end-to-end encrypted so Google cannot use them to impersonate users. Android 14 and later lets users store passkeys in a compatible third-party credential manager instead.
Recovery: Google's security blog post on passkey security describes recovery on a new device using the screen lock PIN, password or pattern of an existing device, with the verification data held in secure hardware enclaves on Google's servers that limit attempts to no more than 10. Creating or using passkeys requires a screen lock.
Enterprise controls: Google Account Help notes that Google Workspace administrators decide whether users may sign in with just a passkey ("Skip password when possible"). Google also advises removing a passkey from the Google Account after losing a device or creating one on a shared device by mistake. See the Google Workspace Security Guide.

Microsoft (Windows Hello and Microsoft Authenticator)

Sync scope: Microsoft's "Support for passkeys in Windows" states that private keys are stored securely on the user's device and unlocked with Windows Hello (biometrics or PIN), and that cross-device sign-in authorises another device over Bluetooth without copying the passkey. Windows 11 version 22H2 with KB5030310 adds native passkey management. Entra documentation lists Microsoft Authenticator on iOS and Android among device-bound passkey examples, where the private key never leaves the device.
Recovery: Microsoft's page describes the private keys as stored on the user's device; our reading is that recovery therefore relies on another registered passkey or the relying party's own recovery process; plan a second authenticator per user.
Enterprise controls: Microsoft Entra ID passkey profiles (up to three, including the default) set attestation, passkey type (device-bound or synced) and AAGUID restrictions per group. Entra documents that attestation is enforced only at registration, and that removing a previously allowed AAGUID stops existing users of it from signing in. On Windows, organisations that restrict Bluetooth can allow pairing only with passkey-enabled FIDO2 authenticators through the Bluetooth and DeviceInstallation policy CSPs. See the Workforce Passkeys in Entra ID and Okta guide.

Provider summary

Platform	Where keys live	Recovery factor described in vendor docs	Organisation control point
Apple	iCloud Keychain, end-to-end encrypted, synced across the user's Apple devices	iCloud Keychain escrow protected by a passcode, 10 attempts	Passkey Attestation declarative configuration on managed devices
Google	Google Password Manager, end-to-end encrypted, synced across Android and Chrome	Existing device screen lock, verified in secure hardware, 10 attempts at most	Workspace admin passkey sign-in setting; third-party provider choice on Android 14+
Microsoft	On the device with Windows Hello; Microsoft Authenticator device-bound passkeys	Second registered passkey or relying party recovery	Entra ID passkey profiles; Windows Bluetooth and device installation CSPs

Third-party credential managers that act as providers on these platforms follow the same model: an encrypted vault synced to the user's devices, unlocked by an account secret and device factor. Assess them with the same NIST questions. See the Password Manager Buyer's Guide.

Choosing provider policy

Customers: accept any provider. NIST says the unavailability of attestation should not block syncable authenticators for broad public-facing applications. Record AAGUID and flags for support and fraud analysis only.
General workforce on managed devices: accept synced passkeys, prefer providers tied to managed or organisation-owned accounts, and require phishing-resistant authentication to add a passkey. Show the provider name in the user's security settings so unexpected providers stand out.
Personal devices (BYOD): a synced passkey in a personal provider account leaves your control when the person leaves. Pair it with device-bound credentials for sensitive applications and with offboarding that deletes credentials server side.
Privileged and AAL3 users: device-bound only, attestation enforced, AAGUID allow list of assessed models.

Small organisations can usually run two policies, everyone and administrators. Large organisations should map provider policy to device ownership (managed, BYOD) and role, and test that the identity provider can express each combination before announcing it.

Rolling out provider policy

Inventory current credentials: export registered passkeys with AAGUID, BE and BS to see which providers users already chose.
Decide policy per population as above, and write down which providers you treat as managed.
Pilot in report mode: where the identity provider supports it, log registrations that would be blocked before enforcing; watch for users whose only device would be excluded.
Enforce at registration, then re-enrol credentials registered before enforcement that do not meet policy, because attestation checks do not apply retroactively.
Add signals: call signalUnknownCredential on failed sign-ins and signalAllAcceptedCredentials after successful ones, and update user details after renames.
Rollback: keep previous policy versions; relaxing an AAGUID list is immediate, while tightening it can lock users out, so announce removals in advance.

Where identity fits

The provider account is itself an identity that guards every passkey in it. An attacker who takes over a user's provider account and adds a device inherits all their synced passkeys. Protect provider accounts with their own phishing-resistant sign-in, and treat a new device joined to a provider account like a new authenticator registration. For administrators who manage service principals, CI/CD secrets and other non-human identities, keep privileged passkeys out of personal provider accounts altogether. See the Passkey account recovery guide.

Detection and measurement

Log AAGUID, BE, BS, attestation result and user verification for every registration and sign-in.
Alert when a privileged user registers a backup-eligible credential, or a credential from an AAGUID outside policy.
Alert on a burst of new passkey registrations for one account, or registration shortly after a recovery or help desk event.
Track share of sign-ins by provider and by synced versus device-bound, per population.

Metric	Why it matters
Users with two or more registered passkeys	Recovery without falling back to passwords
Privileged credentials with BE = 1	Should be zero
Credentials with unknown or unexpected AAGUIDs	Shows unmanaged providers and possible client tampering
Recoveries completed without a password reset	Shows recovery is not undoing phishing resistance
Signal API calls per failed sign-in with an unknown credential	Confirms provider hygiene is wired in

Framework mapping

Practice	NIST SP 800-53 Rev. 5	NIST CSF 2.0
Provider and passkey type policy per population	IA-5 Authenticator Management	PR.AA-01
Phishing-resistant sign-in	IA-2(8) Access to Accounts: Replay Resistant	PR.AA-03
Registration and sign-in logging	AU-2 Event Logging	DE.CM-03
Managed devices for workforce passkeys	CM-8 System Component Inventory	ID.AM-01

Common failure patterns

Treating the AAGUID as proof: a provider allow list without attestation blocks honest users of other providers but not a tampered client.
Weak recovery behind strong passkeys: the relying party lets users reset by email link, so the provider's escrow and attempt limits never matter.
Privileged passkeys in personal provider accounts: an administrator's passkey syncs to a family tablet and leaves with the employee.
No second passkey: device-bound Windows Hello or Authenticator passkeys are the only credential, so a laptop refresh becomes a password reset.
Treating signals as revocation: the relying party calls signalUnknownCredential but keeps accepting the deleted credential server side.
Retroactive policy assumptions: attestation or provider restrictions are enabled after broad registration and nobody re-enrols the existing credentials.

Practitioner checklist

Record AAGUID, BE, BS and attestation result for every passkey you hold.
Set provider policy per population: customers, workforce, BYOD, privileged.
Keep privileged users on device-bound, attested passkeys only.
Require phishing-resistant sign-in to register a new passkey.
Make sure every user has a second passkey or a recovery path that does not reintroduce passwords.
Implement the three WebAuthn signal methods, and still revoke server side.
Use managed-device features (Apple Passkey Attestation configuration, Entra passkey profiles, Workspace passkey settings) where they match your policy.
Review provider documentation each quarter, because sync and recovery behaviour changes.

Passkey Providers: How Sync, Recovery and Enterprise Controls Shape Security