Category: FIDO & Passkeys

Passkey Provider

Also known as: Credential Provider, Passkey Manager

Simply put

A passkey provider is a service or app that lets you create, store, and use passkeys, which are a passwordless way to sign in to apps and websites using something like your fingerprint or face. Examples include platform features built into a phone or computer and standalone apps such as an authenticator app. Once enabled, the provider handles the passkey behind the scenes when you log in.

Formal definition

A passkey provider is any entity that enables the creation, management, and use of passkeys, where a passkey is a passwordless FIDO credential used for authentication. Providers can be platform-integrated (for example, an OS-level passkey feature) or third-party applications; on modern mobile platforms, an authenticator app can typically be registered as a passkey provider through OS settings (for example, Autofill & Passwords on iOS, or provider settings on Android). Passkeys managed by a provider are generally either synced across devices or device-bound, and the provider mediates the passkey during authentication ceremonies (typically WebAuthn/FIDO2-based, though exact protocol support depends on the provider and platform). This term concerns credential storage and authentication use; it does not by itself address authorization, provisioning, or governance concerns.

Why it matters

Passkey providers are the practical delivery mechanism for passwordless authentication. A passkey is a FIDO credential that lets a user sign in with an inherence factor such as a fingerprint or facial recognition, or a device unlock gesture, rather than a shared secret like a password. Because the provider handles credential creation, storage, and use during the authentication ceremony, the choice of provider directly shapes the user's authentication experience and, in enterprise contexts, the trust an organization places in a given credential. Understanding what a provider is and where it lives is a prerequisite to reasoning about the assurance of any passkey-based sign-in.

The distinction between platform-integrated providers (an OS-level passkey feature) and third-party providers (a standalone authenticator app registered through OS settings) matters for both deployment and portability. On modern mobile platforms, an authenticator app can typically be registered as a passkey provider through OS settings, for example, Autofill & Passwords on iOS or provider settings on Android. This flexibility lets organizations and users select a provider that fits their ecosystem, but it also means the security and recovery properties of a passkey depend on which provider mediates it, not on the passkey concept alone.

Equally consequential is whether the passkeys a provider manages are synced across devices or device-bound, since this affects recovery, portability, and the assurance model. A synced passkey may be available across a user's devices through the provider, easing recovery, while a device-bound passkey stays on a single authenticator. Teams evaluating passkey providers should treat these characteristics as first-class decision inputs rather than assuming all providers behave identically.

Who it's relevant to

IAM Engineers and Security Architects

Those designing passwordless authentication flows need to understand where passkeys are created, stored, and mediated. The choice between platform-integrated and third-party providers, and between synced and device-bound passkeys, affects assurance, recovery, and portability decisions. Because provider behavior and protocol support vary, architects should validate WebAuthn/FIDO2 support and provider registration paths per platform rather than assuming uniform behavior.

System Administrators

Admins responsible for enrolling users in passwordless authentication may need to guide registration of a third-party authenticator app as a passkey provider through OS settings, for example, Autofill & Passwords on iOS or provider settings on Android. Understanding the registration path and whether resulting passkeys are synced or device-bound helps in planning enrollment and account recovery support.

Compliance and Identity Governance Leads

While a passkey provider concerns authentication and credential storage rather than authorization, provisioning, or governance, governance leads still need to account for how authentication credentials are provisioned and recovered within their broader IGA program. The synced-versus-device-bound distinction, in particular, is relevant when documenting credential handling and assurance assumptions, though enforcement of what an authenticated user may access remains out of scope for this term.

Inside Passkey Provider

Credential Store

The secure storage where the passkey's private key material is held, typically bound to a device secure element, TPM, or a cloud-synchronized keychain depending on the provider implementation.

Authenticator Function

The component that performs WebAuthn/FIDO2 authenticator operations, generating key pairs and producing signed assertions in response to relying party challenges. A passkey provider can act as a platform authenticator (built into the OS/device) or expose credentials to relying parties via WebAuthn.

Synchronization Fabric

In sync-capable providers (as with many passkey implementations), the mechanism that replicates discoverable credentials across a user's devices under a single account, distinguishing synced passkeys from device-bound credentials that never leave hardware.

Relying Party Interface

The WebAuthn API surface through which the provider registers new credentials and responds to authentication ceremonies for a given relying party (identified by RP ID), returning attestation and assertion data as defined by the WebAuthn specification.

User Verification Mechanism

The local gesture (biometric inherence factor, device PIN as a knowledge factor, or similar) used to unlock the passkey before it signs, which contributes the user-verification signal to the relying party.

Common questions

Answers to the questions practitioners most commonly ask about Passkey Provider.

Is a passkey provider the same as a password manager?

Not exactly. While many password managers now also act as passkey providers, the two roles are distinct. A password manager stores knowledge-factor secrets, whereas a passkey provider stores and manages FIDO2/WebAuthn credentials (discoverable credentials) and performs the cryptographic signing operations during authentication ceremonies. A single product may perform both functions, but being a password manager does not by itself make something a passkey provider, and vice versa.

Does using a passkey provider mean my passkeys are less secure because they can be synced across devices?

Not inherently, though it depends on the provider and configuration. Passkeys managed by a provider are typically synced passkeys, meaning the private key material is backed up and available across the user's devices, in contrast to device-bound passkeys that never leave a single authenticator. Synced passkeys trade some hardware-binding assurance for recoverability and usability. Whether this is acceptable depends on your risk model; relying parties can, depending on the standard profile and available signals, apply policy based on authenticator characteristics.

How does a relying party know which passkey provider was used and whether it meets policy?

During registration and authentication, WebAuthn can surface signals such as the authenticator's AAGUID and, in some flows, attestation data. Depending on configuration and the provider, these signals may allow a relying party to identify the provider or authenticator model and apply policy. Support and reliability of these signals vary by platform, browser, and provider, so relying parties should not assume attestation is always available.

What happens to a user's passkeys if they lose access to their passkey provider?

This depends on whether the passkeys are synced or device-bound. For synced passkeys, recovery typically flows through the provider's account recovery mechanisms, meaning the security of the passkeys is tied to the security of that provider account. For device-bound credentials, loss of the device generally means the credential cannot be recovered and the user must re-register a new passkey. Relying parties should plan account recovery and re-enrollment flows accordingly and not rely solely on a single passkey.

Can users register passkeys from multiple providers with the same relying party?

In most deployments, yes. A relying party can allow a user account to have multiple registered WebAuthn credentials, which may originate from different passkey providers or authenticators. This is generally recommended to support recovery and cross-ecosystem access. The relying party is responsible for managing the credential list associated with each account and for presenting appropriate options during authentication.

How should relying parties handle passkey provider interoperability across platforms?

Passkey providers operate within platform and browser ecosystems, and cross-platform use often depends on features such as cross-device authentication flows. Relying parties should implement standards-conformant WebAuthn and avoid assumptions tied to a specific provider or platform. Behavior can vary by browser, operating system, and provider, so testing across the target environments is advisable, and support details should be verified against current platform documentation rather than assumed.

Common misconceptions

A passkey provider handles authorization for the applications a user logs into.

A passkey provider participates in authentication, proving the user controls a registered credential. What the authenticated user is permitted to do is a separate authorization decision made by the relying party or its policy engine, and is out of scope for the provider itself.

All passkeys are synchronized across devices by the provider, so they are interchangeable with cloud passwords.

Whether passkeys sync depends on the provider and configuration. Some providers offer synced, discoverable credentials replicated across a user's devices, while device-bound passkeys remain on a single hardware authenticator. FIDO2, WebAuthn, and passkeys are related but not interchangeable terms: WebAuthn is the API, FIDO2 encompasses the broader set of specifications, and passkeys are FIDO credentials, some of which are synced.

Because a passkey uses cryptographic keys, the assertions it produces are encrypted end to end.

WebAuthn assertions are digitally signed to prove possession of the private key; signing establishes integrity and origin, not confidentiality. Signing is not the same as encryption, and the private key typically never leaves the authenticator regardless.

Best practices

Treat the passkey provider as part of the authentication layer only, and keep authorization decisions in a separate policy decision point rather than assuming provider selection implies any entitlement grant.

Clarify per relying party whether synced or device-bound passkeys are acceptable, since the two carry different assurance and recovery characteristics depending on provider and configuration.

Configure relying parties to require and evaluate the user-verification signal where the risk profile warrants it, so the local inherence or knowledge factor is actually enforced rather than assumed.

Define account recovery and passkey re-enrollment flows in advance, because loss of a device-bound authenticator or a synchronization account can otherwise strand users.

Validate attestation and RP ID handling in your WebAuthn integration to ensure credentials are scoped to the intended relying party, and confirm your integration follows the WebAuthn specification as implemented by your chosen provider.

Where step-up authentication is needed, integrate the passkey ceremony as one factor within a broader MFA strategy rather than assuming a passkey alone satisfies every assurance requirement.