Restrict Passkey Authenticators: AAGUID Policy Guide

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 those questions with 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. You get a policy model, the pros and cons of restricting, a provider-by-provider assessment, test criteria and a rollout plan.

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 verdict 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, the AAGUID is part of the attested credential data. Community registries such as the passkey-authenticator-aaguids repository map it to a provider name and logo, which is how we build the passkey list in our password manager guide. Microsoft's Entra passkey documentation 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 statement, see why some platforms do not support attestation.
• 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 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. 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.

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 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 2-3% of credentials in Corbado's CIAM data, because first-party providers hold 95-99%. Blocking first-party providers affects most of your customers. The shares below count credentials, not unique customers, and they are not a forecast of rejected enrollments.

Two conclusions follow:

• Restricting third parties is cheap in volume. Blocking all eight reviewed managers and both Mac profile labels at once would touch roughly 2-3% of credentials.
• Restricting first parties is expensive. Two providers, iCloud Keychain and Google Password Manager, hold roughly 80-90% of credentials. 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.

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.

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

5. Which providers should you accept?#

Prefer first-party providers at onboarding and qualify third-party managers by implementation instead of by brand. Our review accepts all five first-party providers as candidates, accepts Dashlane and NordPass, splits 1Password and Bitwarden by surface and holds LastPass and Proton Pass until user verification is proven. Each verdict is a support and risk decision. A hold describes missing assurance, not a claim of compromise.

5.1 How do first-party providers compare?#

All five first-party providers are accept candidates. 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. Shares are the provider's portion of all credentials in the aggregate data.

5.2 How do third-party password managers compare?#

Third-party managers are split by implementation. We tested user verification on six browser extensions: four report UV without verifying the user when the vault is unlocked, and two always require the master password. Native and app-linked paths behave differently from extensions, so an AAGUID-level rule cannot separate good from bad paths of the same vendor.

Three details matter more than the labels:

• Implementation beats brand. 1Password and Bitwarden both split 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. 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 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.

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 is the reference we use.

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.

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.

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

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 and WebKit announced it for Safari 26.

8.3 How do the benefits and costs compare?#

The table pairs each benefit with the cost you pay for it. The orphaned passkey on the client and the credential exchange gap are the two costs that most teams underestimate, so weigh them first when you decide whether a restriction is worth the friction for your customer base.

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 and device-bound versus 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 four KPIs per credential manager and platform for each tested cohort:

• Failed enrollments: passkey registrations that fail.
• Failed logins: orphaned passkeys that no longer match an account.
• Fallback rate: customers who fall back to phishable methods after a veto.
• 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 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, the authentication observability layer, shows what the restriction will cost before you enforce it.

See Authenticator Inventory in Corbado Observe →

• 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 95-99% of credentials 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 verdicts as vendors ship.

About Corbado

Corbado is the Passkey Intelligence Platform for large-scale CIAM teams running consumer authentication. We help you see what IDP logs and generic analytics tools can't: where passkeys, passwords, OTP, social login and fallback journeys succeed, stall or fail, which devices and browsers create friction, and when an OS update silently breaks login. Two products: Corbado Observe layers process mining and observability across authentication journeys. Corbado Connect adds managed passkeys with analytics built in alongside your IDP. VicRoads runs passkeys for 5M+ users with Corbado (+80% passkey activation). Talk to a Passkey Expert →

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 credential data from CIAM deployments, first-party providers account for roughly 95-99% of credentials. Even a hard block on eight reviewed third- party password managers plus Chrome and Edge profiles on Mac would touch roughly 2-3% of credentials. Credentials 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.