Skip to main content
Authenticator Policies let you define which passkey providers qualify for enrollment in your application. Corbado Connect evaluates newly created credentials against your policy and guides users to a supported alternative when enrollment is declined. For regulated organizations, this connects the security team’s authenticator requirements to the customer’s enrollment experience. You define the criteria for user verification, key protection and recovery. Connect applies the acceptance decision and handles the next step in CorbadoConnectAppend. Passkey Intelligence decides when and how to offer enrollment. It can detect many password managers present in web environments and skip enrollment when a detected manager is excluded by your policy. Authenticator Policies evaluate any resulting credential before acceptance.
An AAGUID without trusted attestation is a reported provider identifier. Filtering it helps guide users toward qualified providers, but cannot reliably stop an authenticator that impersonates an accepted provider. Cryptographic assurance requires validating the credential’s attestation against an accepted trust anchor. Finding its AAGUID in FIDO Metadata Service (MDS) alone is insufficient.

​
Qualification criteria

Assess providers against your application’s requirements. User verification (UV) deserves particular attention: a provider’s behavior can differ between a standalone browser extension, a native app and an extension connected to that app. Record each assessment with its tested platform, browser, provider version and integration mode. Grade it as meets requirements, meets requirements under specified conditions, does not meet requirements or not assessed. Record the evidence separately as tested behavior, vendor documentation or validated attestation with trusted metadata. An assessment is evidence for your acceptance decision. An AAGUID does not necessarily distinguish versions or configurations, so a conditional grade is only actionable when you can establish that its conditions hold. Membership in a first-party or third-party category does not by itself determine qualification.

​
Enrollment policy options

Policies use AAGUIDs to map returned credentials to assessed providers or authenticator models. An AAGUID identifies a model or provider, rather than an individual device or person. Define how to handle unknown and all-zero AAGUIDs. An unknown identifier means the provider cannot be classified from that signal; it is not evidence that the provider is unsafe. If your policy declines it, offer a known, supported alternative. For example, an RP might accept selected platform providers based on a documented assessment, decline a provider whose tested UV behavior falls short and accept selected security-key models only with trusted attestation and required UV. This is an RP-specific decision, not a universal list of approved providers.

​
Security guarantees and limits

​
Reported AAGUIDs guide users

For an unattested credential, Connect can apply your policy to the reported AAGUID. This helps ordinary users avoid enrolling with a provider that your organization has not qualified. It does not prove the provider’s identity, active settings or continuing custody of the private key. A manipulated identifier can bypass that classification. A mixed policy that accepts some unattested providers retains this limitation, even if it also validates attestation for security keys. Requiring attestation for one branch does not make every accepted credential attested. See AAGUID identification and its limits.

​
Validated attestation supports model restrictions

For an attestation requirement, Connect validates the registration’s attestation statement and certificate chain against an accepted trust anchor, checks the binding to the authenticator model and evaluates relevant metadata and status reports against your policy. Missing, untrusted or unacceptable attestation causes enrollment to be declined under that requirement. FIDO MDS provides metadata and trust information for this evaluation. An MDS lookup alone does not authenticate a presented AAGUID. With trusted attestation, an RP can restrict enrollment to qualifying security-key models with cryptographic evidence of their provenance. See WebAuthn registration verification and FIDO Metadata Service.

​
UV requirements and provider assessment work together

Require user verification for the relevant ceremonies and verify the returned UV flag server-side. The flag reports that the authenticator performed user verification; it does not identify the exact biometric or PIN method or independently prove that a fresh prompt appeared. Metadata describes supported verification methods. Provider assessment addresses the behavior you expect in practice. Neither an AAGUID nor a capability list proves the user’s current configuration. See FIDO verification metadata.

​
Avoiding friction before enrollment

Connect Passkey Intelligence can detect many password managers present in web environments before showing the passkey enrollment screen. When it detects a manager that your Authenticator Policy excludes, it can skip showing the passkey enrollment screen and continue the user’s authenticated journey. This avoids asking the user to create a passkey only to decline it afterward, reducing unnecessary prompts and unusable local credentials. Detection coverage varies by manager, browser and environment. Detecting a manager does not prove which provider the user would select, and an undetected manager may still be present. This check guides the experience; server-side policy evaluation still applies whenever enrollment proceeds. An early skip triggers onSkip with skip-implicit and should be measured separately from a decline after creation.

​
When enrollment is declined

The browser or credential manager may save a passkey before Connect receives the registration response. Connect evaluates the policy before accepting that credential for authentication. Declining enrollment therefore prevents its use with your application, but does not prevent the local save.
Passkey Intelligence checks for password managers before showing enrollment. A detected excluded manager skips the enrollment screen and continues the existing session. Otherwise the user creates a passkey and Connect checks its AAGUID and required attestation. Accepted credentials can be used for future login. Declined enrollment offers a supported provider for retry or continuation in the existing session. A declined passkey may remain stored locally.Passkey Intelligence checks for password managers before showing enrollment. A detected excluded manager skips the enrollment screen and continues the existing session. Otherwise the user creates a passkey and Connect checks its AAGUID and required attestation. Accepted credentials can be used for future login. Declined enrollment offers a supported provider for retry or continuation in the existing session. A declined passkey may remain stored locally.

Detection can avoid an enrollment offer. Credentials created afterward still pass server-side policy checks.

CorbadoConnectAppend shows a dedicated decline screen with supported alternatives. It keeps the existing application session intact and lets the user retry or continue without adding a passkey. A policy decline is not an enrollment success and should be measured separately from technical errors and user cancellations. A refused credential can remain in the provider and appear in later passkey selection. The component provides removal guidance and uses supported cleanup signals where available. Signal API behavior depends on the browser and provider; a successful API call is not proof of removal. See the Append decline experience and Signal API behavior.

​
Define and review your policy

Agree the policy with your security team and Corbado before enabling it. Record the accepted or restricted AAGUIDs, attestation requirements, unknown-provider behavior and supported alternatives. Give each restriction an owner, reason and review date. Test both acceptance and decline paths across the environments your customers use. Include an unlocked vault, an unknown AAGUID, missing or invalid attestation, repeated retries and a refused credential offered at a later login. Measure early skips due to detected managers, accepted enrollments, policy declines after creation, successful retries with another provider and abandonment. Evaluate any increase in subsequent password or OTP use alongside the benefit of the restriction. This enrollment policy does not automatically revoke previously accepted passkeys. Decide separately how existing credentials should be treated when requirements change, with a migration and recovery path for affected users. The flow described here covers web enrollment through CorbadoConnectAppend; agree coverage for settings-page enrollment and native SDKs before applying the same policy across those journeys. Authenticator Policies support your organization’s defined acceptance requirements. Regulatory compliance remains a broader assessment of enrollment, authentication, sessions and recovery.