Category: Authentication Methods

Passkey

Also known as: FIDO passkey, passwordless credential

Simply put

A passkey is a way to sign in to apps and websites without typing a password, using something like your fingerprint, face recognition, or a device PIN instead. It is a digital credential tied to your account and to a specific website or application. It is intended to offer a more convenient and secure alternative to traditional passwords.

Formal definition

A passkey is a cryptographic credential bound to a specific user account and a relying party (website or application), used for passwordless authentication. The credential is unlocked locally through a user gesture such as biometric verification (fingerprint or facial recognition) or a device PIN, which authorizes use of the underlying key material rather than transmitting a shared secret. Passkeys are designed to be usable across a user's devices to streamline sign-in. Note that the evidence provided does not detail the underlying protocol mechanics, and passkey behavior, syncing, and security properties depend on the specific implementation; confirm technical details against the relevant published specifications.

Why it matters

Passwords remain one of the weakest points in account security. They can be phished, guessed, reused across sites, or stolen in bulk from breached databases, and traditional password-based multi-factor methods such as one-time codes can still be intercepted or socially engineered. Passkeys are intended to address these problems by replacing the shared secret model with a cryptographic credential that is unlocked locally by a user gesture such as a fingerprint, facial recognition, or a device PIN, rather than by transmitting a password that an attacker could capture or reuse.

For payment security and fraud teams, authentication weaknesses are frequently the entry point for account takeover, which can in turn enable card-not-present fraud and unauthorized transactions. A credential that is bound to a specific relying party (website or application) may help reduce certain phishing and credential-reuse risks that drive account takeover. However, a passkey addresses sign-in authentication only; it is a distinct control from EMV chip authentication, 3-D Secure, and transaction-level strong customer authentication, and it does not by itself eliminate fraud that originates from other vectors such as malware on an authorized device, first-party or friendly fraud, or compromised recovery flows.

The evidence provided describes passkeys at a general level and does not detail the underlying protocol mechanics, syncing behavior, or specific security guarantees. Because passkey behavior and security properties depend heavily on the particular implementation and platform, teams evaluating passkeys for their own environments should confirm technical and assurance details against the relevant published specifications rather than assuming uniform behavior across vendors.

Who it's relevant to

Fraud and account risk teams

Because account takeover is a common precursor to card-not-present fraud, teams monitoring for unauthorized access may treat passkey adoption as one factor that could help reduce phishing- and credential-reuse-driven takeover. It should be evaluated alongside, not as a replacement for, other detection controls, and its coverage should not be assumed to extend to fraud vectors outside of sign-in authentication.

Identity and authentication engineers

Engineers implementing passwordless sign-in need to understand that a passkey is bound to a specific relying party and unlocked by a local user gesture rather than a transmitted secret. Because syncing, recovery, and security properties depend on the implementation, they should confirm behavior against the relevant published specifications and platform documentation before relying on assumed guarantees.

Compliance and security officers

Those assessing authentication controls should distinguish passkey-based sign-in authentication from transaction-oriented controls such as 3-D Secure, strong customer authentication, and EMV chip authentication, which address different risks at different points. Passkeys may support authentication objectives but should be documented and validated according to the specific standards and requirements that apply to a given environment.

Product and platform teams

Teams building consumer-facing sign-in experiences may consider passkeys as a more convenient and potentially more secure alternative to passwords, using biometrics or a device PIN to streamline access across a user's devices. They should account for enrollment, cross-device usability, and account recovery flows, since these vary by implementation and can introduce their own risks.

Inside Passkey

FIDO2/WebAuthn credential

A passkey is a discoverable FIDO credential built on the FIDO2 and WebAuthn specifications, replacing shared secrets like passwords with a public-private key pair bound to a specific relying party (origin).

Public-private key pair

Authentication relies on asymmetric cryptography: the private key stays on the user's device or authenticator, and only the public key is registered with the relying party. The private key is never transmitted during authentication.

Authenticator

The component that stores the private key and performs the signing operation. It may be a platform authenticator (built into a device, such as a phone or laptop with biometric hardware) or a roaming authenticator (an external security key).

User verification (local factor)

Access to the private key is typically gated by a local gesture such as a biometric or device PIN. This local verification unlocks the authenticator but is not itself transmitted to the relying party.

Origin binding

Passkeys are cryptographically scoped to the relying party origin for which they were created, which is intended to help resist phishing and credential reuse across sites.

Synced vs. device-bound passkeys

Some passkeys are synced across a user's devices through a provider's cloud keychain, while others are bound to a single hardware authenticator and do not leave it. The two models carry different recovery, portability, and assurance trade-offs.

Common questions

Answers to the questions practitioners most commonly ask about Passkey.

Does a passkey count as multi-factor authentication on its own?

Not automatically. A passkey is a FIDO/WebAuthn credential based on public-key cryptography, and whether it satisfies a multi-factor authentication requirement depends on how it is implemented and unlocked. A single passkey authentication can combine possession of the device holding the private key with a local user verification step such as a biometric or PIN, but you should validate the specific implementation against the requirement you are trying to meet rather than assuming the label alone qualifies. Confirm expectations against the current published PCI DSS text, since requirement wording and numbering differ between versions.

Is a passkey the same thing as a stored password or a shared secret?

No. A password is a shared secret that both the user and the relying party know or store, while a passkey uses a key pair in which the private key stays on the user's authenticator and only the public key is registered with the relying party. Because the private key is not transmitted or held by the server, passkeys are intended to reduce risks associated with reused, phished, or breached shared secrets. This changes what an attacker could obtain from a server compromise, but it does not by itself eliminate all authentication-related fraud.

How does using passkeys affect PCI DSS scope for the authentication system?

Passkeys change how credentials are handled but do not, by their label alone, remove a system from scope. Scope is determined by whether the system stores, processes, or transmits cardholder data or can affect the security of the cardholder data environment, and by how the authentication mechanism protects access to that environment. You should assess and validate the passkey implementation and its supporting infrastructure against the controls in the current published standard rather than assuming a scope outcome from the technology name.

What happens when a user loses the device holding their passkey?

Recovery depends on whether the passkey is device-bound or synced across a provider's ecosystem. Device-bound credentials do not exist elsewhere, so account recovery relies on a separate, pre-established process, while synced passkeys may be restored on another device through the syncing provider. Because recovery paths can become the weakest link, they should be designed and reviewed with the same rigor as the primary authentication, and account recovery is generally treated as a distinct control to evaluate.

Can passkeys be shared across the mobile app and web channels of the same service?

It depends on how the credential is scoped and whether the platform supports credential availability across those contexts. Passkeys are bound to a relying party identity, and whether the same credential works in both an app and a browser depends on platform association mechanisms and the syncing model in use. Implementers should test the intended channels and document the behavior rather than assuming a passkey registered in one context is automatically usable in another.

Should a passkey rollout include a fallback authentication method, and what is the trade-off?

Many deployments retain a fallback method to handle unsupported devices, lost authenticators, or enrollment gaps, but a fallback can undercut the intended benefits if it reuses weaker shared secrets. The trade-off is between availability and the risk that attackers target the weaker path, so any fallback should be assessed as part of the overall authentication design. The goal is to help reduce phishing and credential-reuse risk without introducing an easier route that offsets that reduction.

Common misconceptions

A passkey is just a more convenient password stored in the cloud.

A passkey is a cryptographic key pair, not a shared secret. The relying party only holds the public key, so there is no reusable secret to steal from the server in the way a stored or hashed password can be. The convenience is a side effect of the underlying asymmetric design, not the core distinction.

Passkeys count as multi-factor authentication because a biometric is used.

The local biometric or PIN verifies the user to the authenticator; it does not transmit a separate factor to the relying party. Whether a passkey satisfies a given multi-factor or strong customer authentication requirement depends on how the implementation is assessed against the applicable rules and standards, and should be validated rather than assumed.

Adopting passkeys eliminates account takeover and phishing fraud.

Origin binding is intended to help reduce phishing and credential-stuffing risk, but passkeys do not address all attack paths. Account recovery flows, synced-credential compromise, device theft with a weak local gesture, and social engineering can remain exposures. Passkeys may mitigate certain fraud vectors without preventing fraud outright.

Best practices

Decide deliberately between synced and device-bound passkeys based on your assurance needs, and document the recovery, portability, and trust trade-offs of the chosen model.

Design account recovery paths with the same rigor as primary authentication, since recovery is often the weakest link and can undermine the benefits of origin-bound credentials.

Do not assume a passkey satisfies multi-factor or strong customer authentication obligations by default; validate the implementation against the applicable rules and standards and confirm requirement wording in the current published versions.

Enforce user verification (biometric or device PIN) rather than relying on user-presence-only ceremonies where higher assurance is required, and record which authenticators support it.

Verify origin binding is configured correctly for each relying party so credentials cannot be replayed against a different origin.

Combine passkeys with layered fraud controls and monitoring, since passkeys may reduce certain phishing and credential-reuse vectors but do not cover device theft, recovery abuse, or social engineering.