What are Passkeys?

Passkeys are FIDO authentication credentials that use public-key cryptography to let users sign in to websites and applications without entering a password. Instead, the user typically approves the sign-in using the same mechanism they use to unlock their device, such as a fingerprint, face recognition, device PIN, or password. [1][2]

Each passkey is associated with a specific website or application. The service stores a public key, while the corresponding private key is controlled by the user's authenticator. During sign-in, the authenticator uses the private key to produce cryptographic proof that the service can verify with the public key. The private key itself is not sent to the service. [1]

Passkeys are designed to provide phishing-resistant authentication because the credential is bound to the legitimate relying party rather than relying on a password or one-time code that a user can accidentally give to a phishing site. [1][3]

For organizations, the important shift is not simply replacing one sign-in screen with another. Passkeys change the underlying authentication model from transferable credentials, such as passwords and OTPs, to cryptographic authentication. The bigger opportunity is then deciding where passkeys should become the primary method, how customers enroll, and what should happen when a passkey is unavailable.

Passkeys at a glance

How do passkeys work?

Passkeys use asymmetric, or public-key, cryptography.

Instead of the user and service sharing the same credential, a passkey uses a key pair:

• a private key, controlled by the user's authenticator; and
• a public key, stored by the website or application.

The two keys are mathematically related, but the private key does not need to be disclosed to the service for authentication to succeed. [1]

A typical passkey journey has two main stages.

1. Creating a passkey

When a user creates a passkey:

1. The website or application, known in WebAuthn as the relying party, asks the user's device or authenticator to create a new public-key credential.
2. The authenticator creates a cryptographic key pair associated with that relying party.
3. The authenticator retains the private key, while the corresponding public key and credential information are registered with the service.
4. Depending on the implementation, the user may verify themselves locally using a device PIN, password, or biometric recognition.
5. The passkey can then be used for future authentication. [1]

WebAuthn describes passkeys as discoverable credentials, meaning they can be available to an authenticator without the relying party first supplying a specific credential identifier. This can enable sign-in experiences where the user does not need to type a username before selecting a passkey. [1]

2. Signing in with a passkey

When the user returns:

1. The service sends a unique cryptographic challenge.
2. The authenticator identifies an appropriate passkey for that relying party.
3. The user approves use of the passkey, often by unlocking the device using a PIN or biometric.
4. The authenticator signs authentication data associated with the challenge using the private key.
5. The service verifies the signed response using the stored public key.
6. If the cryptographic verification and required authentication checks succeed, access can be granted. [1]

Because each authentication ceremony incorporates a new challenge, previously captured authentication responses cannot simply be replayed in a later authentication attempt. NIST classifies cryptographic authentication using challenges or nonces as replay-resistant. [3]

Why are passkeys phishing-resistant?

Passkeys are phishing-resistant because authentication is cryptographically bound to the legitimate relying party.

A password or OTP can be typed into a convincing imitation of a legitimate website. An attacker can then capture that credential and attempt to use it against the real service.

A WebAuthn credential works differently. The credential is scoped to a relying party identifier, and the authenticator creates its response for that relying party. A phishing site operating under a different domain cannot simply request and reuse the legitimate site's credential. [1]

NIST identifies WebAuthn as an example of verifier name binding, one of the mechanisms it recognizes for providing phishing resistance. In this model, the authentication credential is cryptographically associated with the authenticated domain of the verifier. [3]

FIDO similarly defines passkeys as phishing-resistant credentials based on public-key cryptography. [2]

This changes the security model in an important way. The customer is no longer responsible for recognizing whether a site looks legitimate before deciding whether to enter an authentication code. The authentication protocol itself helps enforce where the credential can be used.

Are passkeys the same as biometrics?

No.

A passkey is a cryptographic credential, not a fingerprint, facial image, or other biometric.

Biometric recognition can be used locally by the authenticator to verify that the person attempting to use the passkey is authorized to do so. A device PIN, pattern, or password can also be used for this purpose. [1][2]

WebAuthn refers to this process as user verification.

When biometric recognition is used, WebAuthn specifies that the biometric data is not revealed to the relying party. The biometric comparison is performed locally and the authenticator indicates whether user verification succeeded as part of the signed authentication response. [1]

This distinction matters when explaining passkeys to customers. A service using passkeys does not necessarily receive or store the customer's fingerprint or facial biometric simply because the customer uses Face ID, a fingerprint reader, or another biometric mechanism to unlock the passkey.

Are passkeys multi-factor authentication?

They can be.

All WebAuthn authenticators demonstrate possession of a cryptographic credential, which represents something the user has. [1]

An authenticator can also perform local user verification using another factor, such as:

• a PIN or device password, representing something the user knows; or
• biometric recognition, representing something the user is.

WebAuthn Level 3 describes passkey authenticators that combine possession of the private key with user verification as capable of passwordless multi-factor authentication. [1]

NIST similarly defines multi-factor cryptographic authentication as possession of an authentication key that requires activation through another factor. [3]

However, organizations should not assume that every use of every WebAuthn credential automatically represents MFA. Whether an authentication event satisfies a particular MFA or assurance requirement depends on the authenticator, whether user verification was performed, the relying party's configuration, and the requirements of the relevant framework.

The more useful question is therefore not simply "are passkeys MFA?" but what assurance does this passkey authentication event provide?

What is the difference between synced and device-bound passkeys?

Passkeys can generally be divided into two models: synced passkeys and device-bound passkeys. [2]

Synced passkeys

A synced passkey can be made available across multiple devices through a passkey provider's synchronization service.

For example, a passkey created on one device may become available on another device associated with the same passkey provider account. This also makes it possible for passkeys to be restored when a customer replaces a device. [2]

NIST refers to this category as syncable authenticators. Under its current guidance, authentication keys stored in a synchronization service must be protected by defined cryptographic and access controls, and private-key authentication operations must still occur locally on the user's device. [4]

Syncing can make passkeys much more practical as a password replacement because customers are less dependent on one physical device.

Device-bound passkeys

A device-bound passkey remains associated with a particular authenticator rather than being synchronized to other devices.

Examples can include credentials stored on a hardware security key or within a device or application where the authentication key cannot be exported.

This distinction can matter in higher-assurance environments. Under NIST SP 800-63B-4, syncable authenticators can support authentication up to AAL2 when the relevant requirements are met. Because synchronization requires an authentication key to be exportable, a syncable authenticator cannot meet NIST's AAL3 requirement for a non-exportable private key. [3][4]

That does not make one passkey model universally "better" than the other. Synced credentials can provide significant usability and recovery advantages, while device-bound credentials may be preferable where stronger control over key exportability is required.

The authentication architecture should reflect the level of assurance required for the interaction rather than treating all passkeys as identical.

Can passkeys work across different devices?

Yes.

A synced passkey may already be available on another device through the user's passkey provider. FIDO also defines cross-device authentication for situations where the passkey is available on one device but the customer is signing in on another. [2]

For example, a person signing in on a laptop may be able to use a passkey stored on their phone. FIDO's cross-device authentication mechanism uses CTAP hybrid transport and can use a QR-code-based flow to establish the interaction between the devices. [2]

This is important for consumer authentication because customers do not always sign in from the same device or operating environment.

A passkey strategy therefore needs to consider more than the initial enrollment experience. It should also account for new devices, cross-device access, lost devices, platform changes, and customers who temporarily do not have access to their usual authenticator.

Passkeys vs passwords and OTPs

Passkeys, passwords, and OTPs use fundamentally different authentication models.

NIST does not classify passwords or manually entered OTP authentication as phishing-resistant. Properly configured WebAuthn cryptographic authentication can provide phishing resistance through verifier name binding. [3]

For organizations moving away from password-plus-OTP journeys, this is an important distinction. Passkeys are not simply another second factor added after a password. They can replace the password itself and, where appropriately configured with user verification, provide multi-factor authentication through a single authentication interaction. [1]

What happens if a user loses their device?

Device loss does not necessarily mean loss of the passkey.

With a synced passkey, the credential may be available on another device associated with the user's passkey provider or restored to a replacement device through that provider's synchronization process. [2][4]

A device-bound credential, by definition, may not be transferable in the same way.

This makes recovery design an important part of a passkey rollout.

Organizations should consider:

• whether customers can register multiple passkeys;
• whether synced passkeys are accepted;
• how customers authenticate from a new device;
• what happens when no existing passkey is available;
• how additional passkeys can be added securely; and
• whether fallback methods introduce a weaker path back into the account.

The last point is particularly important. Moving the primary sign-in journey to phishing-resistant authentication provides limited value if account recovery still relies on a method that an attacker can easily exploit.

A strong passkey strategy therefore treats enrollment, routine authentication, additional-device registration, and recovery as one authentication lifecycle, rather than optimizing the sign-in screen in isolation.

Standards and regulatory considerations for passkeys

Passkeys are based on open authentication standards rather than a proprietary authentication protocol.

WebAuthn and FIDO2

The W3C Web Authentication specification defines the web API used to create and use public-key credentials.

WebAuthn Level 3 became a W3C Recommendation on August 25, 2026. It defines the creation and use of scoped, public-key-based credentials by web applications and formally recognizes discoverable credentials, including passkeys. [1]

WebAuthn works with the FIDO Client to Authenticator Protocol (CTAP). Together, WebAuthn and CTAP form the standards commonly referred to as FIDO2. [2][5]

The standards separate the relying party, client, and authenticator roles, allowing passkeys to work across different browsers, operating systems, authenticators, and service providers.

NIST Digital Identity Guidelines

NIST SP 800-63B-4 recognizes WebAuthn cryptographic authentication as capable of providing phishing resistance through verifier name binding. [3]

The 2025 revision also formally incorporated requirements for syncable authenticators, including synced passkeys. [4]

Under the NIST model:

• appropriately configured syncable cryptographic authenticators can be used up to AAL2;
• phishing-resistant authentication is required to be available at AAL2 under specified conditions;
• syncable authenticators cannot be used at AAL3 because their private keys are exportable by design; and
• non-exportable cryptographic authenticators can potentially support AAL3 when the other AAL3 requirements are met. [3][4]

These classifications should be read in the context of NIST's Digital Identity Guidelines rather than treated as universal regulatory requirements.

The practical takeaway is that "supports passkeys" does not answer every assurance question. Organizations should understand the type of credential being accepted, whether user verification occurred, how keys are managed, and what level of assurance the protected interaction requires.

When should organizations use passkeys?

Passkeys are particularly well suited to replacing passwords for routine account access and other journeys where phishing-resistant authentication and a lower-friction experience are valuable.

However, rolling out passkeys does not require every other authentication method to disappear immediately.

Customers may be at different stages of enrollment, may use different devices and channels, or may encounter situations where their passkey is unavailable. Higher-risk actions may also require different policy decisions from routine sign-in.

A practical approach is to make passkeys the preferred authentication method where they provide the appropriate assurance, while retaining the ability to orchestrate other methods when the customer, channel, or risk context requires them.

For example:

• a returning customer may use a passkey for routine sign-in;
• a customer without an enrolled passkey may use another method before being prompted to create one;
• a new or unusual interaction may trigger additional risk evaluation;
• a sensitive account change may require fresh authentication or another verification step; and
• recovery may follow a separate higher-assurance path.

The objective should be moving more authentication toward phishing-resistant methods without making the customer journey dependent on a single method or device.

What should organizations consider when implementing passkeys?

A passkey implementation is as much an authentication-journey project as it is a technical integration.

Define where passkeys fit in the authentication journey. Decide whether passkeys will be optional, preferred, or required for particular users and interactions, and how that changes over time.

Make enrollment easy to understand. A user cannot benefit from a passkey they never create. The timing, wording, and context of enrollment prompts can be as important as the underlying WebAuthn implementation.

Decide what assurance you require. Determine whether user verification must be performed and whether synced or device-bound passkeys are appropriate for the protected interaction. WebAuthn allows relying parties to specify whether user verification is required, preferred, or discouraged. [1]

Support more than one device where appropriate. Customers replace phones, use laptops and mobile devices interchangeably, and may move between ecosystems. Synced passkeys, multiple registered credentials, and cross-device authentication can all help address this. [2]

Design recovery alongside sign-in. Recovery should not become the weakest path into a passkey-protected account. Consider how users prove control when their usual authenticator is unavailable and how new passkeys are bound to the account.

Keep fallback methods deliberate. Passwords, OTPs, contact-center verification, or other methods may remain necessary for some users or journeys, but their presence can affect the security of the overall account.

Consider passkeys alongside risk. A phishing-resistant passkey provides strong authentication, but risk signals can still provide useful context about the device, session, transaction, or behavior surrounding the authentication event.

Plan for gradual adoption. Consumer populations rarely move to a new authenticator overnight. The strongest rollout is often one that can support passkeys alongside existing methods while progressively increasing enrollment and usage.

This is where authentication orchestration becomes useful. Passkeys can become the preferred method without forcing every customer through exactly the same journey, while policy determines when another authentication or verification method is appropriate.

Related authentication terms

WebAuthn: The W3C specification that defines an API for creating and using public-key credentials for web authentication.

FIDO2: The combination of the W3C WebAuthn specification and FIDO Alliance CTAP specifications used for FIDO authentication.

Public-key cryptography: A cryptographic model using mathematically related public and private keys. In passkey authentication, the service stores the public key while the authenticator controls the private key.

Relying party (RP): The website or application that relies on WebAuthn authentication.

Authenticator: The component that creates and uses the cryptographic credential. It may be built into a device or exist as an external authenticator.

User verification: Local verification performed by an authenticator, such as a PIN, password, pattern, or biometric recognition.

Discoverable credential: A WebAuthn credential that can be discovered by the authenticator without the relying party first identifying a specific credential. Passkeys are discoverable FIDO credentials.

Synced passkey: A passkey that can be synchronized through a passkey provider and made available across multiple user devices.

Device-bound passkey: A passkey whose authentication key remains associated with a particular authenticator or device rather than being synchronized.

Phishing-resistant authentication: Authentication designed to prevent authentication credentials or valid authentication output from being captured and reused by an impostor verifier.

Passwordless authentication: Authentication that does not require the user to enter a password. Passkeys can provide passwordless authentication.

Passkeys are an important shift in authentication because they improve the security model and the customer experience at the same time. The long-term opportunity is not simply to add "Sign in with a passkey" alongside an existing password flow. It is to make phishing-resistant authentication the normal path for routine access while retaining the flexibility to apply risk-based step-up, recovery, and other verification methods when the interaction requires something different.

Frequently asked questions