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

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

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 the large majority 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 per-platform split, the device-bound share and the shift from local to synced passkeys on Windows come from two CIAM deployments. On macOS most device-bound passkeys come from the outdated Chrome profile store. Request the platform data if you need the figures for your own business case.

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

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.

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.

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

Request the full assessment if you want the per-provider results.

5.3 Which AAGUIDs identify these providers?#

The AAGUIDs of all providers in this guide are published in one reference list. Use that list to build your allowlist and check each value against the community registry before deployment, because an AAGUID is self-reported for every provider except the Windows Hello entries, which carry an MDS record.

Our AAGUID glossary is the reference list. For single providers see iCloud Keychain, Google Password Manager, Windows Hello and Chrome on Mac. The passkey-authenticator-aaguids repository is the community source behind most of these values. Map the entries to three classes:

• Always allow: the five first-party providers, including the three Windows Hello AAGUIDs, and security keys with valid MDS attestation.
• Security decides: Chrome and Edge on Mac, the third-party managers and the all-zero AAGUID, which accounts for 0.5-1% of registrations.
• Not allowed: generic Chromium builds, virtual and test authenticators, unknown AAGUIDs, unattested security keys and anything not on the list (default deny, with a review route for the unknown class).

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

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

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