Skip to main content
Commerce Security Authority
Category: Authentication Methods

WebAuthn

Also known as: WebAuthn, Web Authentication API
Simply put

WebAuthn is a web standard that lets people sign in to websites and applications using public key cryptography instead of, or in addition to, passwords. It is supported in common modern browsers such as Chrome, Safari, and Firefox and underpins technologies like passkeys. It is intended to enable stronger authentication, though it addresses login security specifically and is not a complete fraud-prevention solution on its own.

Formal definition

The Web Authentication API (WebAuthn) is a specification developed by the W3C and FIDO, with participation from organizations including Google, Mozilla, Microsoft, and Yubico, that extends the Credential Management API to enable strong authentication using public key cryptography. It allows a relying party (such as a web service) to register and authenticate users via public key credentials, where a WebAuthn Client—typically implemented in whole or in part within the user agent—acts as an intermediary between the relying party and the authenticator. WebAuthn defines the browser-facing API for credential creation and assertion; it governs authentication at the login layer and is distinct from payment-transaction authentication mechanisms such as EMV chip authentication or 3-D Secure.

Why it matters

WebAuthn addresses one of the most persistent weaknesses in account security: reliance on passwords, which are vulnerable to phishing, credential reuse, and theft. By using public key cryptography, WebAuthn allows a private key to remain bound to an authenticator and never be transmitted to or stored by the relying party, which helps reduce the risk of credentials being harvested through phishing or database compromise. It underpins passkey implementations and enjoys wide support across evergreen browsers including Chrome, Safari, and Firefox, making stronger authentication more practical to deploy at scale.

For security and fraud teams, WebAuthn is relevant primarily at the login layer, where it can strengthen protection against account takeover by making stolen or replayed passwords insufficient on their own. However, it is important to understand its scope: WebAuthn governs authentication to web services and applications, not payment-transaction authorization. It is distinct from and does not replace payment-transaction authentication mechanisms such as EMV chip authentication or 3-D Secure, which address different risks at different points in a transaction. WebAuthn is intended to enable stronger authentication, but it is not a complete fraud-prevention solution on its own and does not by itself address fraud that occurs after a legitimate authentication, such as first-party or friendly fraud.

Who it's relevant to

Security engineers
Engineers integrating authentication into web services can use the WebAuthn API to implement public key–based login, either replacing or supplementing passwords. Understanding that the private key stays bound to the authenticator and is not transmitted to the relying party helps in designing systems that reduce exposure to phished or stolen credentials.
Fraud analysts and merchant risk teams
WebAuthn can strengthen defenses against account takeover at the login layer, but analysts should recognize its scope: it authenticates users to applications and does not authorize payment transactions. It is distinct from EMV chip authentication and 3-D Secure, and it does not by itself address post-authentication fraud such as first-party or friendly fraud.
Compliance officers
Compliance teams evaluating authentication controls should note that WebAuthn is a W3C and FIDO web standard governing login-layer authentication, and is separate from payment-transaction authentication mechanisms. Any decision about whether it satisfies a given authentication requirement should be validated against the specific applicable standard rather than assumed from the label alone.

Inside WebAuthn

Public-Key Credential
A WebAuthn authentication relies on an asymmetric key pair generated by an authenticator. The private key remains protected on the authenticator (device or security key), while the public key is registered with the relying party. Authentication is performed by signing a challenge with the private key, so no shared secret equivalent to a password is transmitted or stored server-side.
Relying Party (RP)
The service or application that registers and later verifies credentials. In a payments context this could be a merchant, issuer, or wallet provider. The RP identity is bound into the credential, which is intended to help resist phishing by tying the credential to a specific origin.
Authenticator
The hardware or software component that creates and stores the private key and performs the signing operation. Authenticators may be platform-based (built into a device, such as a biometric sensor) or roaming (external security keys). WebAuthn does not by itself dictate which authenticator type is acceptable for a given use case.
Challenge-Response Ceremony
Registration and authentication are structured as ceremonies in which the RP issues a cryptographic challenge, the authenticator signs it after any required user verification, and the RP validates the signature and associated data. This exchange is the core of the WebAuthn protocol as standardized by the W3C and FIDO Alliance.
User Verification and User Presence
WebAuthn distinguishes user presence (a simple test that a human is present, such as a touch) from user verification (confirming the specific user, for example via biometric or local PIN). These are separate signals; whether a given ceremony requires user verification depends on RP configuration.

Common questions

Answers to the questions practitioners most commonly ask about WebAuthn.

Is WebAuthn the same thing as passwordless login, meaning it removes all authentication risk?
No. WebAuthn is a web API standard that enables authentication using public-key credentials bound to authenticators, and it can support passwordless flows, but it is not synonymous with passwordless login. It can also be used as one factor alongside others. It is intended to reduce certain phishing and credential-replay risks by binding credentials to origins and keeping private keys on the authenticator, but it does not eliminate all authentication risk. Threats such as endpoint compromise, authenticator theft or coercion, account-recovery weaknesses, and social-engineering attacks against fallback methods remain relevant and are out of scope for the API itself.
Does implementing WebAuthn by itself satisfy multi-factor authentication or strong customer authentication requirements?
Not automatically. WebAuthn is a mechanism for exercising public-key credentials; whether a given deployment constitutes multi-factor authentication depends on how it is configured, for example whether it combines a possession factor with a knowledge or inherence factor such as a local PIN or biometric. Multi-factor authentication, strong customer authentication, and 3-D Secure are distinct concepts addressing different requirements and, for strong customer authentication, region-specific regulatory rules. Whether a WebAuthn implementation meets a particular obligation should be assessed against the applicable rule or standard and its current published text rather than assumed from the use of WebAuthn alone.
How does WebAuthn relate to the FIDO2 components an implementation team works with?
WebAuthn is the browser-facing API standardized for web applications, and it is typically paired with a protocol used between the client platform and external authenticators. A relying party integrates the WebAuthn API on the web side, while authenticators such as platform authenticators or roaming security keys handle key generation and signing. Implementation teams should confirm the specific component roles and supported protocol versions against current specifications and their chosen platform and browser support, as capabilities vary.
What should be considered for account recovery when WebAuthn credentials are lost?
Because private keys generally remain on the authenticator, loss or damage of that authenticator can lock a user out. Implementations commonly plan for enrollment of more than one authenticator and for a defined recovery path. Recovery flows warrant careful design, since a weak fallback can undermine the anti-phishing properties of the primary method and may itself become a target for account-takeover attempts. The strength of any recovery mechanism should be evaluated as part of the overall authentication design.
How does WebAuthn interact with PCI DSS scope and cardholder data?
WebAuthn addresses authentication and does not itself store, process, or transmit cardholder data, so it is distinct from controls such as tokenization, encryption, truncation, masking, or hashing that transform account data. Where WebAuthn is used to authenticate access to systems or administrative interfaces within scope, it functions as an authentication control rather than a data-protection control. How authentication requirements apply should be confirmed against the current published PCI DSS text, noting that requirement wording and numbering differ between versions.
What deployment factors affect whether users can register and use WebAuthn credentials?
Practical factors include the browser and operating-system versions in the user base, availability of platform authenticators versus external security keys, and whether the relying party's domain configuration matches the origin binding the credential expects. Teams also weigh user-experience trade-offs, such as supporting multiple authenticators per account and communicating enrollment steps clearly. Supported features vary across platforms and change over time, so capabilities should be verified against current documentation for the targeted environments.

Common misconceptions

WebAuthn is a form of biometric authentication that sends the user's fingerprint or face data to the server.
Biometric checks, when used, are performed locally on the authenticator only to unlock or authorize use of the private key. WebAuthn transmits a cryptographic signature and related data to the relying party, not biometric templates. Biometrics are one possible method of local user verification, not a required part of the protocol.
Deploying WebAuthn satisfies strong customer authentication (SCA) or multi-factor authentication requirements automatically.
SCA and MFA are defined by their own frameworks and, for payments, by applicable regulatory and card brand or network rules that vary by region and change over time. WebAuthn is a mechanism that can contribute a possession factor and, with user verification, an inherence or knowledge factor, but whether a specific deployment meets a given SCA or MFA obligation depends on configuration and independent validation, not on the label alone.
WebAuthn is the same as 3-D Secure and handles payment authorization.
WebAuthn is an authentication protocol for proving control of a credential to a relying party. 3-D Secure is a separate card-network protocol addressing cardholder authentication for card-not-present transactions. They operate at different points and may be used together, but WebAuthn does not itself authorize a payment or perform EMV chip authentication.

Best practices

Configure the relying party identity and origin binding correctly so credentials are tied to the intended domain, which is intended to help resist phishing and credential replay across origins.
Decide explicitly whether each ceremony requires user verification versus only user presence, and document why, since these signals carry different assurance and affect any downstream authentication-factor claims.
Support both platform and roaming authenticators where feasible, and provide a recovery or re-enrollment path, because loss of an authenticator can otherwise lock users out; ensure recovery flows do not become a weaker parallel channel.
Do not treat a WebAuthn deployment as automatically meeting SCA, MFA, or card brand or network requirements; confirm the specific obligation against the current applicable rules and validate the configuration independently.
Keep WebAuthn scoped to authentication and integrate it alongside, not in place of, transaction-level controls such as 3-D Secure or EMV where those apply, since no single control eliminates fraud.
Log and monitor registration and authentication ceremonies for anomalies while being mindful that added friction from user verification can affect false-positive and false-negative trade-offs and user drop-off.