--- url: 'https://www.corbado.com/blog/restrict-passkey-authenticators-aaguid' title: 'Restrict Passkey Authenticators: AAGUID Policy Guide' description: 'Restrict passkey authenticators with AAGUID policies: what an AAGUID proves, how many credentials a block affects and how to roll it out without lockouts.' lang: 'en' author: 'Vincent Delitz' date: '2026-10-03T21:43:39.691Z' lastModified: '2026-10-03T22:44:19.851Z' keywords: 'restrict passkey authenticators, aaguid allowlist, passkey provider policy, fido mds attestation, synced passkeys banking' category: 'Passkeys Strategy' --- # Restrict Passkey Authenticators: AAGUID Policy Guide ## Key Facts - An **AAGUID** without trusted attestation is a self-asserted label. It cannot prove the provider, the build, the signing surface or theft-protection settings. - In Corbado's aggregate CIAM data, **92-98%** of passkeys sit with five first-party providers. Third-party managers add **1-2%**, up to 3-6% on desktop. - A defensible policy **prefers first-party providers at onboarding**, qualifies the rest by implementation, restricts proven failures and defers unresolved risks with a review path. - A rejected passkey still exists on the user's device. Plan its cleanup and measure in **report-only mode** before you enforce. ## 1. Introduction Regulated entities such as banks, insurers and payment providers keep asking us the same question: can we restrict which authenticators our customers use for passkeys, and what does it cost us if we do? Behind it sit three concerns. Compliance wants to name the approved providers, security wants to exclude implementations with weak user verification and product wants to know how many customers a restriction locks out. This guide answers eight questions: - **What can an AAGUID tell you about a passkey, and what does attestation add?** (section 2) - **How many credentials does a restriction actually affect?** (section 3) - **Which policy lanes should you use, and should you choose an allowlist or a blocklist?** (section 4) - **Which providers should you accept?** (section 5) - **Which tests should a provider pass before approval?** (section 6) - **What happens when users move passkeys with CXP and CXF?** (section 7) - **What are the pros and cons of restricting, and why does a refused passkey stay on the device?** (section 8) - **How do you roll out a restriction without lockouts?** (section 9) The answers rest on data. We reviewed 13 credential providers (five first-party and eight third-party password managers), ran our own user verification tests on six browser extensions and combined the results with Corbado's aggregate credential intelligence data from CIAM deployments. One limit up front: apart from the user verification tests, **this is a source and documentation review, with no live conformance tests.** Vendor behavior changes with every release, so treat each assessment as a starting point for your own build-pinned tests and not as a certification. ## 2. What can an AAGUID tell you about a passkey? An AAGUID identifies the make and model of an authenticator, and the relying party (RP) receives it during registration. It works as a label for display, policy and telemetry. It does not prove which provider, build or configuration actually created the passkey, because without a valid attestation signature the value is self-asserted and can be manipulated. As defined by the [W3C WebAuthn Level 3 specification](https://www.w3.org/TR/webauthn-3/), the AAGUID is part of the attested credential data. Community registries such as the [passkey-authenticator-aaguids repository](https://github.com/passkeydeveloper/passkey-authenticator-aaguids) map it to a provider name and logo, which is how we build the [passkey list in our password manager guide](https://www.corbado.com/blog/passkey-implementation-password-managers). Microsoft's [Entra passkey documentation](https://learn.microsoft.com/en-us/entra/identity/authentication/how-to-authentication-passkeys-fido2) treats AAGUID lists as policy guidance for the same reason. Four properties make the AAGUID a weak access control on its own: - **It is a claim, not proof.** Consumer synced passkeys from Apple and Google do not ordinarily deliver an [attestation](https://www.corbado.com/glossary/attestation) statement, see [why some platforms do not support attestation](https://www.corbado.com/faq/why-some-platforms-do-not-support-attestation-for-passkeys). - **It is a snapshot.** The AAGUID describes the provider at registration. Assertions do not report a fresh AAGUID, so a credential that was synced, shared or exported can be used from a surface the AAGUID does not describe (see section 7 for credential exchange). - **It identifies a provider, not a configuration.** It says nothing about PIN strength, recovery factors, Stolen Device Protection or Identity Check settings. - **It does not equal user verification.** The signed [user verification](https://www.corbado.com/glossary/user-verification) flag shows that the authenticator claims to have verified the user. It does not prove biometrics or that the account owner performed the check. The consequence: an AAGUID list is a good tool for **policy, support and telemetry**. As the only security barrier, it is weak. In practice nearly all credential managers report their AAGUID correctly, so a list reliably guides average consumers even though it is no hard security control. Whatever assurance you need beyond that has to come from required user verification, validated attestation where it exists and an independent control for sensitive actions. ### 2.1 How do none, self, trusted and enterprise attestation differ? Attestation covers four levels of evidence. None gives you a label only, self attestation proves possession of a key, trusted attestation lets you verify the authenticator model against the FIDO Metadata Service and enterprise attestation adds the identity of the individual device. Which level you receive decides what an AAGUID policy can enforce. | **Level** | **What the RP receives** | **What you can verify** | **Typical source** | | ---------------------- | ------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------ | | None | A statement in the "none" format. The AAGUID may be present, zeroed or spoofed. | Nothing about the model. The AAGUID is a label. | Consumer synced passkeys, most password managers | | Self attestation | A statement signed with the credential's own key. | Possession of the new key only, no information about the model. | Some software and virtual authenticators | | Trusted attestation | A statement signed by a manufacturer key with a certificate chain. | The chain validates to a trusted root, the model appears in the FIDO MDS with a current status and certification level. | Hardware security keys | | Enterprise attestation | Trusted attestation plus uniquely identifying data such as a serial number. | Which individual device registered. Only works for RP IDs the authenticator or the device management allows. | Managed fleets such as workforce security keys and managed devices | Trusted attestation answers "which model is this and is it certified". Enterprise attestation answers "which exact device is this" and needs an agreement between the RP and whoever manages the device, so it rarely fits a public CIAM deployment. NIST's [appendix on syncable authenticators](https://pages.nist.gov/800-63-4/sp800-63b/syncable/) also discourages making attestation a barrier for public-facing services. For consumer providers, the realistic setup is an AAGUID used as a label, combined with required user verification. ## 3. How many credentials does a restriction affect? A restriction on third-party managers and browser profiles touches roughly 1-2% of passkeys in Corbado's CIAM data, because first-party providers hold 92-98%. On desktop the exposure is higher, up to roughly 3-6%. Blocking first-party providers affects most of your customers. The shares count passkeys, not unique customers, and they are not a forecast of rejected enrollments. | Category | Share of passkeys | Providers | | --------------------------------- | ----------------- | -------------------------------------------------------------------------------------------------- | | First-party providers | 92-98% | iCloud Keychain, Google Password Manager, Windows Hello, Samsung Pass, Microsoft Password Manager | | Third-party password managers | 1-2% | 1Password, Bitwarden, LastPass, Dashlane, Proton Pass, NordPass, Keeper, Kaspersky | | Chrome and Edge profiles on Mac | under 1% | Chrome on Mac, Edge on Mac | | No AAGUID reported | 0.5-1% | All-zero AAGUID | | Other and unclassified | under 0.1% | Generic Chromium, smaller managers, virtual and test authenticators | Two conclusions follow: - **Restricting third parties is cheap in volume.** Third-party managers and browser profiles together are 1-2% of passkeys, with a desktop peak of roughly 3-6%. - **Restricting first parties is expensive.** The five first-party providers hold the vast majority of passkeys. A policy that excludes them is a business decision about most of your customer base. The dataset has no unique-customer counts, no OS mix per customer and no view of how many logins a restriction would affect. That is why section 9 recommends measuring in report-only mode before you enforce anything. ### 3.1 Where do new passkeys live on each platform? Platform providers store over 90% of new passkeys on every operating system. The exception is Windows, where the browser decides: Chrome defaults to Google Password Manager, Edge to Microsoft Password Manager and Firefox to Windows Hello. Third-party managers account for 1-2% of new passkeys overall and up to roughly 6% on desktop. | **Platform** | **Largest providers (share of new passkeys)** | **Device-bound share** | | -------- | -------------------------------------------------------------------------------------------------- | ------------------ | | iOS | iCloud Keychain about 94%, Google Password Manager 1-5%, third-party managers about 1% | Mostly synced | | Android | Google Password Manager 66-96%, Samsung Pass 4-32%, third-party managers under 1% | Mostly synced | | macOS | iCloud Keychain 53-61%, Google Password Manager 30-37%, outdated Chrome profile store 3-6% | About 8% | | Windows | Google Password Manager 44-54%, Windows Hello 22-26%, Microsoft Password Manager 10-25% | About 26% | The figures come from two CIAM deployments, so ranges are wide. Across all platforms only 5-6% of new passkeys are device-bound, and on Windows 60-75% are already synced. On macOS most device-bound passkeys come from the outdated Chrome profile store. ### 3.2 How far does each provider's passkey reach? A passkey follows the customer only as far as its provider reaches. A restriction that pushes customers from one provider to another changes where they can sign in without a detour, so check the reach before you shrink the allowlist. | **Passkey stored in** | **iPhone** | **Android** | **Mac Safari** | **Mac Chrome** | **Windows Chrome** | **Windows Edge** | | ---------------------------------- | ------------------------ | ---------------- | --------------- | ---------- | -------------- | ------------ | | iCloud Keychain | Synced | QR only | Synced | Synced | QR only | QR only | | Google Password Manager | Setup: Chrome as AutoFill | Synced | QR only | Synced | Synced | QR only | | Microsoft Password Manager | No | No | QR only | QR only | Setup: Windows 11 plugin | Synced | | Windows Hello | No | No | No | No | This PC only | This PC only | | Samsung Pass | QR only | Galaxy only | QR only | QR only | QR only | QR only | | 1Password, Bitwarden, Dashlane | App or extension | App or extension | App or extension | App or extension | App or extension | App or extension | "QR only" means the customer needs the phone and the cross-device route and has no passkey on day one. "Setup" means the customer must enable a provider first. ## 4. Which policy lanes should you use? Use three lanes: a consumer lane for synced passkeys that relies on required user verification and a qualified provider catalogue, a security-key lane that relies on validated attestation and the FIDO Metadata Service and an explicit unknown class for everything else. A single allowlist cannot express these different assurance levels. ### 4.1 What belongs in the consumer lane? The consumer lane applies the same server-side checks to every provider, first-party or not, and adds a catalogue that records which provider paths you accept. Treat the catalogue as a product-support and risk decision. Where you cannot verify the AAGUID, say so in the policy and do not present the allowlist as an enforcement guarantee. - Require user verification for the passwordless journey and verify the signed flag. - Validate challenge freshness, origin and RP ID binding and the signature. - Record for each provider which paths (extension, native iOS, native Android, Windows plugin) you accept, based on the test criteria in section 6. ### 4.2 How do security keys qualify through FIDO MDS? A security key qualifies when its attestation chain validates and its model appears in the FIDO Metadata Service with a fresh, acceptable status. Required user verification must also be satisfied. Any vendor can qualify, and the bank decides the certification threshold, because MDS membership alone is not a quality bar. - Request direct attestation and validate the format, signature and certificate path against appropriate roots. - Check the model against the signed BLOB of the [FIDO Metadata Service](https://fidoalliance.org/specs/mds/fido-metadata-service-v3.1-ps-20250521.pdf) and apply status reports by effective date, affected version and batch. An `UPDATE_AVAILABLE` status does not prove that the registering device has updated. - Require user verification. A touch-only U2F key can be a valid second factor, but it does not qualify for UV-required standalone passwordless login. - Optionally pre-register a preferred model, such as a YubiKey 5 series key shipped to customers, so the bank controls the model and the enrollment. ### 4.3 How should you treat unknown AAGUIDs? Create an explicit unknown class with a review route instead of a silent default. Some registrations never resolve to a provider: generic "Passkey" labels, a Chromium build, an SDK or the all-zero AAGUID, which accounts for roughly 0.5-1% of registrations in Corbado's data. These are not malicious by themselves, so do not label them insecure. Route the class to an independent bank verification or a replacement path where you need stronger confidence, and never fold it silently into the security-key lane. ### 4.4 Which policy options exist? There are five options, from no list at all to a managed catalogue. The bank's rationale is usually to protect unsuspecting customers from bad storage, but fewer allowed providers do not make passkeys safer by default. In practice the question is whether the bank supports the top three or the top six password managers, and whether it accepts that the UV flag of some extensions can be unreliable, which is a valid concern for transactions (see the [known issues on passkeys.dev](https://passkeys.dev/docs/reference/known-issues/)). 1. **No list:** accept every AAGUID the browser or OS returns. 2. **First-party providers only:** iCloud Keychain, Google Password Manager, Windows Hello, Samsung Pass and Microsoft Password Manager. 3. **First-party providers plus browser profiles:** adds Chrome on Mac and Edge on Mac, which store keys with the Secure Enclave. 4. **First-party providers, browser profiles and selected third-party providers:** each third-party provider is assessed against the criteria in section 6. 5. **All security keys with MDS attestation:** an addition to any of the options above. Our recommendation is a managed allowlist that always allows first-party providers and attested security keys, with security deciding per provider on browser profiles and third-party managers. ### 4.5 Should you use an allowlist or a blocklist? Both need the same product changes: error handling after creation, an FAQ of supported providers and a process to maintain the list. Only an allowlist also excludes the long tail of virtual, unknown and generic AAGUIDs, so it is the stronger choice when you operate a managed catalogue. | **Criterion** | **No restriction** | **Managed allowlist** | | ---------------- | ------------------------------------------------------ | -------------------------------------------------------- | | Security control | No control over virtual, unknown or generic authenticators | The bank decides which providers qualify | | Customer choice | Customers keep the manager they chose | Vetoed managers are blocked, most visible on desktop | | Product changes | None, standard passkey flow | Error message after creation, FAQ of supported providers | | Friction | No refusals at passkey creation | Refused customers hit friction and may fall back | | Maintenance | No AAGUID list to watch | List and MDS updates to monitor | | Testing scope | Widest set of authenticators in scope | Smaller, assessed set | ## 5. Which providers should you accept? Always allow the first-party providers and attested security keys, which together cover about 98% of registrations, and let security decide per provider on browser profiles and third-party managers. Third-party managers differ more by implementation than by brand, and an AAGUID rule alone cannot separate good paths from bad paths of the same vendor. Set a review date for every decision. ### 5.1 How do first-party providers compare? All five first-party providers sit in the always-allow group. They differ in theft protection, recovery and in what the bank can observe about the credential. Windows Hello is device bound, while the other four sync. | **Provider** | **Key points** | | -------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------- | | iCloud Keychain | End-to-end encrypted sync. [Stolen Device Protection](https://support.apple.com/en-us/120340) helps on iPhone but must be active before theft. It does not apply to macOS. | | Google Password Manager | Assess Android and desktop separately. Android [Identity Check](https://blog.google/security/android-theft-protection-feature-updates/) is not desktop protection, and desktop cloud-authenticator research needs a remediation review. | | Windows Hello | Local, device-bound credentials. Residual risk is a known Hello PIN, and recovery needs a spare passkey. Hardware-TPM and software variants differ. | | Samsung Pass | Resolve recovery, PIN fallback and the actual theft-protection coverage. | | Microsoft Password Manager | Confidential-computing and HSM architecture is meaningful, but internal attestation is not provenance visible to the bank. | ### 5.2 How do third-party password managers compare? We assessed eight third-party managers on six criteria: user verification, key protection, stolen-device behavior, recovery, sharing and export and the latest verified release. User verification is the criterion with the largest spread: in our tests four of six extensions report UV without verifying the user on an unlocked vault, because WebAuthn treats UV as a fresh check while password managers treat it as an open vault. The full assessment is available on request. Three details matter more than the labels: - **Implementation beats brand.** 1Password and Bitwarden both differ by surface. The same vendor can pass on a native mobile provider and fail on an older extension. - **Cached user verification is not a defect.** A valid, bounded cached authorization is a legitimate behavior under the [FIDO authenticator security requirements](https://fidoalliance.org/specs/fido-security-requirements/fido-authenticator-security-requirements-v1.6-fd-20250312.pdf). A fresh biometric prompt on every operation is a stronger bank policy, not a universal rule. - **Chrome and Edge on Mac are a weaker target than they look.** Chrome's Mac profile stores keys with the Secure Enclave, as described in [Chrome's announcement](https://developer.chrome.com/blog/passkeys-on-icloud-keychain) and visible in the Chromium source. The missing attestation applies equally to the other consumer providers you accept. Blocking only these two is a support or scope decision. [Request the full assessment](https://www.corbado.com/contact) if you want the per-provider results. ### 5.3 Which AAGUIDs identify these providers? The AAGUIDs below come from the community registry and the FIDO MDS. Only the Windows Hello entries carry an MDS record, and for the others the value is self-reported, so an allowlist built on them steers enrollment without proving custody. Verify each value against the current registry before you deploy a list. The [passkey-authenticator-aaguids repository](https://github.com/passkeydeveloper/passkey-authenticator-aaguids) is the reference we use. | **Provider** | **AAGUID** | | ---------------------------- | -------------------------------------- | | Apple Passwords | `fbfc3007-154e-4ecc-8c0b-6e020557d7bd` | | iCloud Keychain (managed) | `dd4ec289-e01d-41c9-bb89-70fa845d4bf2` | | Google Password Manager | `ea9b8d66-4d01-1d21-3ce4-b6b48cb575d4` | | Windows Hello (hardware) | `08987058-cadc-4b81-b6e1-30de50dcbe96` | | Windows Hello (TEE) | `9ddd1817-af5a-4672-a2b9-3e3dd95000a9` | | Windows Hello (software) | `6028b017-b1d4-4c02-b4b3-afcdafc96bb2` | | Samsung Pass | `53414d53-554e-4700-0000-000000000000` | | Microsoft Password Manager | `d3452668-01fd-4c12-926c-83a4204853aa` | | Chrome on Mac | `adce0002-35bc-c60a-648b-0b25f1f05503` | | Edge on Mac | `771b48fd-d3d4-4f74-9232-fc157ab0507a` | | 1Password | `bada5566-a7aa-401f-bd96-45619a55120d` | | Bitwarden | `d548826e-79b4-db40-a3d8-11116f7e8349` | | LastPass | `b78a0a55-6ef8-d246-a042-ba0f6d55050c` | | Dashlane | `531126d6-e717-415c-9320-3d9aa6981239` | | Proton Pass | `50726f74-6f6e-5061-7373-50726f746f6e` | | NordPass | `b84e4048-15dc-4dd0-8640-f4f60813c8af` | | Keeper | `0ea242b4-43c4-4a1b-8b17-dd6d0b6baec6` | | Kaspersky Password Manager | `a10c6dd9-465e-4226-8198-c7c44b91c555` | | No AAGUID reported | `00000000-0000-0000-0000-000000000000` | ## 6. Which tests should a provider pass before approval? A provider should pass the same tests regardless of vendor: required user verification that fails closed, a clear behavior on an already-unlocked vault, a defined theft scenario, tested recovery and a known sync and export path. Run each test on every surface and pin the build, because a result on one surface does not transfer to another. The most common surprise is user verification. WebAuthn treats it as a fresh check on every request, while password managers optimize for vault unlock and the vault often stays open. Like autofill of a password or TOTP code, a passkey request on an unlocked vault often triggers no new verification. Browser extensions also cannot trigger Secure Enclave or TPM operations, so verification and signing stay in software, whereas native apps that use the OS provider APIs can invoke OS user verification. | **Area** | **What to test** | | ----------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- | | User verification | Request required, preferred and discouraged. Cancel and fail verification, then confirm that "required" never returns a successful assertion with UV=true. | | Already-unlocked vault | Assert twice without locking. Check whether verification is repeated, cached with a bounded lifetime or skipped. | | Fail-closed behavior | Quit the desktop app during extension use and make sure a UV-required request does not silently downgrade. | | Stolen locked phone | Test without the passcode, then with the known device passcode, then with an already-unlocked vault. Compare identical attacker capabilities across providers. | | Recovery and new device | Test account login, the decryption or recovery secret, lost-all-devices recovery and trusted-device enrollment. | | Compromised endpoint | Review extraction from a decrypted vault, malicious extensions or native code and signature misuse. Hardware wrapping, cloud-enclave signing and nonexportable keys give different guarantees. | | Sync, sharing, export | Test sync, sharing, export and import, credential ID continuity and bank-side revocation after a copy exists. | ## 7. What happens with credential exchange (CXP and CXF)? Nothing is evaluated. The FIDO Alliance's Credential Exchange Protocol (CXP) and Credential Exchange Format (CXF) move a passkey between providers without a new registration ceremony, so your server never sees an AAGUID for the move. The credential keeps its ID and public key while your record still shows the provider from the original registration. Support is arriving on the major platforms. Apple provides OS-mediated credential exchange, Google Play services documents phone import and export of passkeys and 1Password supports export on its mobile apps. For an AAGUID policy this matters a lot, because **a transfer is not a registration**. | **Scenario** | **What your server sees** | **Consequence for the policy** | | ------------------------------------------------------------- | ----------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | User registers in a blocked provider | A registration with a blocked AAGUID | The registration is rejected (but see section 8 for what remains on the client) | | User registers in an accepted provider and exports to a blocked one | Nothing at transfer time. Later assertions arrive without an AAGUID. | Your record still says "accepted" while the signing surface is now a provider you block | | User registers in a blocked provider elsewhere and imports into an accepted one | Nothing at transfer time. Assertions look like an accepted provider's. | A credential from a provider you would have rejected is now active under an accepted label | | User moves a credential between two accepted providers | Nothing | Usually harmless, but the stored AAGUID no longer describes the current provider | The credential ID, the public key and the RP binding survive the move, and your server never gets a ceremony in which it could evaluate the AAGUID. Three consequences follow: - **The stored AAGUID is historical attribution.** Treat it as a registration record and not as a statement about where the credential lives today. - **An allowlist protects registration, not the credential lifecycle.** If you need assurance that outlasts registration, combine required user verification with sign-in risk signals such as a new device or a changed environment, and use an independent control for sensitive actions. - **Device-bound credentials stay put.** Credentials that cannot be exported, such as local Windows Hello passkeys or hardware security keys, are unaffected. That is one more argument for the security-key lane when you need provenance. If you suspect that a credential was copied, revoke it on the bank side. Removing it from the provider's vault or sharing group does not revoke the copy. ## 8. What are the pros and cons of restricting authenticators? The main benefit is a documented, defensible list of accepted providers. The main cost is that a refused passkey is created on the client before your server can say no, so it stays on the device and keeps confusing customers. Weigh both against the small share of credentials a restriction actually touches. ### 8.1 What are the pros of restricting authenticators? Restricting authenticators gives you a documented, defensible list of accepted providers and lets you exclude implementations with demonstrated user verification failures. It also creates a measurable basis for fraud and support analysis. The benefits are real but modest, because the restriction only touches the small share of credentials outside the first-party providers. - **Audit-ready provider list:** compliance gets a reviewable list of accepted providers with an owner and a review date for every decision. - **Targeted exclusion of weak paths:** you can keep out older standalone extensions while still accepting the same vendor's native app. - **Measurable impact:** enrollment rejections, fallbacks and login outcomes per provider give fraud and support teams a clear baseline. - **Fit with an independent control:** a catalogue pairs well with a separate control for sensitive actions, so provider assurance and transaction assurance stay decoupled. - **Defensible against NIST:** accepting qualified syncable authenticators up to AAL2 follows the NIST guidance. ### 8.2 What are the cons of restricting authenticators? The main cost of restricting authenticators is that the refusal comes too late. The passkey already exists on the user's device and keeps appearing in login prompts. Further costs are false confidence from unverifiable AAGUIDs, a gap through credential exchange, extra support contacts and list upkeep. Most of these costs land on customers and on the support team. - **The refused passkey stays on the client:** it remains in the user's provider unless the WebAuthn Signal API removes it, which often fails for third-party managers. In conditional UI the browser keeps offering it and the login fails (see 8.2.1). - **False confidence:** an AAGUID without attestation cannot verify the provider, so the list steers enrollment without proving custody. - **Credential exchange gap:** credentials can move past a registration-time check (see section 7). - **Support and fallback cost:** every blocked enrollment adds support contacts and a fallback to weaker methods such as passwords or SMS. - **Upkeep:** the list and the MDS statuses need continuous monitoring and a review date for every veto. - **NPS risk:** customers who avoid Big Tech authenticators are vocal about restrictions, and a veto is most visible on desktop. - **Inconsistency risk:** restricting first-party providers affects most customers, and rules such as blocking only Chrome and Edge on Mac while accepting other unattested providers erode the policy. - **Hard to justify as a blanket rule:** blocking all third-party managers is difficult to defend against NIST guidance on syncable authenticators. #### 8.2.1 Why does a refused passkey stay on the device? The restriction runs on your server after the user has already finished the ceremony. The credential manager has saved the passkey and confirmed success, and the server then refuses to store the public key because the AAGUID is not on the list. The passkey remains in the user's provider unless something deletes it. At the next login the OS or browser still offers it. Conditional UI and a passkey button that sends an empty `allowCredentials` list both surface the orphaned passkey, while a request with an `allowCredentials` list does not. The effects reach beyond the first refusal: - **Several local passkeys.** Each retry can add another entry, depending on the credential manager, and none of them works. - **Failed logins.** The biometric succeeds and the login fails, because the server refuses the passkey. - **Helpdesk calls.** The customer cannot tell which entry works and cannot delete the refused one from your site. Plan for this in your error messaging and fallback flows. #### 8.2.2 Which credential managers act on the Signal API? Apple and Google act on the WebAuthn Signal API, while most third-party managers do not yet. The API lets an RP tell the provider which credentials to remove, but a refused 1Password or Bitwarden passkey stays in autofill in our tests, and every call resolves silently. | **Credential manager** | **Chrome and Edge desktop** | **Chrome Android** | **Safari 26 and iOS 26** | **Refused passkey in autofill** | | -------------------------- | ----------------------- | -------------- | -------------------- | --------------------------- | | iCloud Keychain | No effect | Not applicable | Acts, with a known bug | Removed in Safari only | | Google Password Manager | Acts | Acts | Not applicable | Removed after the signal | | Samsung Pass | Not applicable | No effect | Not applicable | Still shown | | Windows Hello | No effect | Not applicable | Not applicable | Still shown | | Microsoft Password Manager | No effect | Not tested | Not applicable | Still shown | | 1Password, Bitwarden, Keeper, Proton Pass, NordPass | No effect | Not tested | Not tested | Still shown | | Dashlane | No effect | Not tested | Vendor-supported | Platform-dependent | The results come from Corbado's own tests of Chrome 151 on macOS, Windows 11 and Android. Chrome documents the API for [Chrome 132 and later](https://developer.chrome.com/docs/identity/webauthn-signal-api) and WebKit announced it for [Safari 26](https://webkit.org/blog/16993/news-from-wwdc25-web-technology-coming-this-fall-in-safari-26-beta/). ### 8.3 How should you weigh the two sides? The policy we find most defensible sits between the extremes: **prefer first-party providers at onboarding, qualify the alternatives by implementation, restrict demonstrated failures and defer unresolved high-risk cases with a documented review path.** Apply the same evidence standard to first-party providers. For background on assurance levels, see our guides on [NIST and passkeys](https://www.corbado.com/blog/nist-passkeys) and [device-bound versus synced passkeys](https://www.corbado.com/blog/device-bound-synced-passkeys). ## 9. How do you roll out a restriction without lockouts? Pilot in report-only mode, apply the policy to new registrations first, migrate existing credentials only after a replacement works and keep an independent control for the highest risk. Every targeted restriction needs an owner, evidence, a review date and a customer path to recover. Never mass-revoke credentials because of a registration-time AAGUID. ### 9.1 Why start in report-only mode? Report-only mode shows you the cost of a restriction before customers feel it. The inventory shares from section 3 will not predict it, and only measurement does. Track these five KPIs per credential manager and platform (OS and browser) for each tested cohort. They are default measures in Corbado Observe: - **Failed enrollments:** passkey registrations that fail, which also gives you the impact on the passkey enrollment rate. - **Failed logins:** orphaned passkeys that are used after a failed enrollment, in Conditional UI or on a passkey button. - **Fallback rate:** customers who fall back to phishable methods after a veto without switching to an accepted provider. - **UX impact:** errors that customers see with blocked authenticators. - **Drop-off:** abandoned logins at any step of the flow. Add recovery, customer contacts and confirmed fraud to the same cohort view. ### 9.2 How do registration, login and sensitive actions differ? Treat new registration, ordinary login and sensitive-action authorization as three separate decisions, because each can carry a different rule. A provider you accept for login may still need an independent control for a high-value payment. Setting the rules separately avoids surprise lockouts and keeps the strictest checks where the risk is. ### 9.3 How do you migrate existing credentials? Let the customer enroll a replacement from an accepted provider, confirm it works and only then retire the old credential. Registration AAGUIDs are historical attribution, so do not mass-revoke. Where the browser supports it, call the WebAuthn Signal API to ask the provider to remove credentials your server rejected, and treat that as best effort. ### 9.4 When do you need an independent control? You need one for payments and other sensitive actions where the provider cannot give runtime assurance. A same-vault TOTP is not an independent answer to a compromised vault. Use a separate trusted control such as transaction signing or a device-bound security key. ## 10. How Corbado can help [Corbado Connect](https://www.corbado.com/connect) lets you allow or block authenticators by AAGUID, so the policy from section 4 runs in your enrollment flow and not in a spreadsheet. [Corbado Observe](https://www.corbado.com/observe), the [authentication observability](https://www.corbado.com/blog/authentication-observability) layer, shows what the restriction will cost before you enforce it. [Video: Authenticator inventory](https://www.corbado.com/videos/features/authenticator-inventory.mp4) ([See Authenticator Inventory in Corbado Observe](https://www.corbado.com/observe/authenticator-inventory)) - **Authenticator inventory**: Observe resolves registered credentials to provider and model and shows the share of each in your own user base. - **AAGUID allow and block lists in Connect**: define which providers may register and adjust the list as vendors ship fixes. - **Impact measurement**: rejected enrollments, fallbacks and login outcomes per provider appear in Observe, so a pilot gives you the rejection rate that inventory shares cannot. ## 11. Conclusion An AAGUID restriction is a useful tool when you treat it for what it is: a provider label that supports policy, support and telemetry. First-party providers carry 92-98% of passkeys in our CIAM data, so the practical question is rarely "which password managers do we block" and more often "which assurance do we require from every provider". Require user verification everywhere, validate attestation where it exists, qualify third parties by implementation, keep an independent control for sensitive actions and measure in report-only mode before you enforce. Remember the scope of this review: it rests on documentation and source analysis of the current data we have and on our own user verification tests for six extensions, with no other live conformance tests. Pin versions, run the tests from section 6 and revisit the assessments as vendors ship. ## Frequently Asked Questions ### How do I restrict which passkey providers can register with my service? Read the AAGUID from the registration response and compare it against an allowlist you maintain. A managed allowlist is stronger than a blocklist because it also excludes unknown and generic AAGUIDs. The control is only reliable with trusted attestation, which consumer synced passkeys such as iCloud Keychain and Google Password Manager do not deliver. Combine it with required user verification and an independent control for high-risk actions. ### What happens to a passkey that my server rejects? It stays on the user's device. The server rejects the registration after the user has already saved the passkey, so the credential manager keeps it. Conditional UI and passkey buttons without an allowCredentials list keep offering it and the login then fails. The WebAuthn Signal API can request deletion, but today mainly Google Password Manager and Apple's Safari act on it. ### Is an AAGUID reliable enough to enforce a security policy? Only with trusted attestation, which means a statement signed by the manufacturer and validated against a trusted root. Without it the AAGUID is self-asserted and can be manipulated. It cannot prove the provider build, the signing surface or theft-protection settings. A credential that was later synced, exported or moved with the Credential Exchange Protocol can also be used from a different surface. ### Can I block synced passkeys for banking? You can, but the evidence does not support a blanket block. NIST guidance allows appropriately configured syncable authenticators up to AAL2. A more defensible policy prefers first-party providers at onboarding, qualifies third-party providers by implementation, restricts proven failures and routes unresolved cases to an independent control. ### How many users does an AAGUID restriction affect? In Corbado's aggregate data from CIAM deployments, first-party providers account for roughly 92-98% of passkeys. A hard block on all third-party password managers would touch roughly 1-2% of passkeys, up to 3-6% on desktop. Passkeys are not users and the share is not a forecast of rejected enrollments, so run a report-only pilot before enforcing. ### What happens to existing passkeys when I restrict an authenticator? Apply the policy to new registrations first. For existing credentials, let the user enroll a replacement from an accepted provider, confirm it works and only then retire the old one. Every targeted restriction needs an owner, evidence, a review date and a customer path to recover. ### What happens to my AAGUID policy when users move passkeys with CXP or CXF? Nothing is evaluated. The Credential Exchange Protocol and Format move a passkey between providers without a new registration ceremony, so your server never sees an AAGUID for the move. The credential keeps its ID and public key, and your record still shows the provider from the original registration. Rely on required user verification, risk signals and an independent control for sensitive actions.