What Are WebAuthn, FIDO2 and Passkeys?

WebAuthn is the W3C API that allows web applications to create and use public-key credentials. FIDO2 is the broader ecosystem combining WebAuthn on the web side with authenticator protocols such as CTAP. Passkeys are WebAuthn credentials designed for user-friendly passwordless or multi-factor sign-in, often synced across a user’s trusted devices or stored on a device/security key.

As of August 25, 2026, WebAuthn Level 3 is a W3C Recommendation. Level 4 has entered early draft work, but production guidance should anchor to the Recommendation and the capabilities supported by target browsers/platforms.

Why WebAuthn Is Phishing Resistant

Traditional passwords and OTP codes can be typed into a fake site and relayed. WebAuthn credentials are scoped to the relying party, and browser/authenticator checks bind the ceremony to the legitimate origin/RP ID. A phishing site on a different domain cannot simply ask the authenticator to produce a valid assertion for the real relying party.

This verifier binding is why modern security guidance treats FIDO/WebAuthn as a strong phishing-resistant option.

WebAuthn Registration Flow

A typical registration ceremony has four trust-critical steps:

• The server creates a cryptographically random challenge and registration options.
• The browser calls the WebAuthn API and the authenticator creates a new scoped credential/key pair.
• The browser returns the credential data and signed/authenticator information to the server.
• The server verifies challenge, origin, RP ID binding and required authenticator properties before storing the public credential.

The private key remains under authenticator control; the server stores public information needed to verify future assertions.

WebAuthn Authentication Flow

Authentication is a challenge-response ceremony rather than password comparison.

1. Server creates fresh challenge + allowed policy
2. Browser requests a credential assertion
3. Authenticator requires user presence / verification as configured
4. Authenticator signs the challenge-bound data
5. Server verifies challenge, origin, RP ID and signature
6. Server issues the application session/token

Challenges must be unpredictable, short-lived and single-use. Server-side verification is the security boundary; the client cannot be trusted to self-assert that WebAuthn succeeded.

Key WebAuthn Terms

Synced Passkeys vs Device-Bound Credentials

Passkeys may be synced through a platform credential provider or remain device-bound depending on the authenticator and deployment. The security and recovery model therefore depends on account/platform protections as well as the WebAuthn ceremony itself.

Organizations should define whether synced passkeys, hardware security keys, enterprise attestation or particular authenticator properties are acceptable for each risk tier rather than assuming all WebAuthn credentials are operationally identical.

What the Server Must Verify in a WebAuthn Assertion

The browser ceremony is only one side of WebAuthn. The relying-party server must verify the returned assertion against the challenge and credential record it issued or stored. Key checks include the challenge, expected origin, RP ID relationship/hash, credential identifier, cryptographic signature, and the user-presence/user-verification flags required by policy.

WebAuthn Level 3 also exposes credential backup eligibility and backup state. If those properties matter to enterprise policy, store and evaluate them deliberately rather than assuming every passkey has the same device-binding model. Signature counters can provide a cloning signal for authenticators that implement them, but a non-increasing counter is not proof of compromise and some authenticators legitimately use a constant zero counter.

WebAuthn Assertion Verification at a Glance

Use a maintained WebAuthn library to perform these checks and configure the expected origin, RP ID and user-verification policy explicitly. The server should never accept a client-supplied RP identity or origin as authoritative configuration.

WebAuthn Implementation Security Checklist

• Generate strong random challenges on the server and invalidate them after use.
• Verify the expected origin and RP ID for every ceremony.
• Require user verification where the assurance policy calls for it.
• Store credential identifiers/public keys securely and support multiple authenticators per account.
• Protect credential enrollment and replacement with recent strong authentication.
• Design recovery so it does not undermine phishing-resistant sign-in.
• Use mature WebAuthn server libraries instead of implementing signature parsing from scratch.
• Test browsers, platform authenticators and roaming keys across the supported environment.

WebAuthn and API Authentication

WebAuthn authenticates a user to the relying party; APIs generally receive the result through a session or access token issued after successful server-side verification. APIs should enforce authorization and, for sensitive actions, may require a token/session that proves recent strong authentication.

WebAuthn does not replace API authorization, token lifecycle controls or protection against stolen post-login sessions.

Related Ammune reading: API authorization vs authentication and JWT API security best practices.

WebAuthn Does Not Always Mean Passwordless

WebAuthn can be deployed as a passwordless primary sign-in, as a phishing-resistant second factor, or as a step-up authenticator for sensitive actions. The presence of a WebAuthn ceremony therefore does not by itself describe the whole account-authentication model.

For passwordless sign-in, discoverable credentials/passkeys can let the user choose an account without first typing a username. Other deployments use a username or existing session to identify which registered credentials are eligible. Choose the model based on account discovery, privacy, recovery and support requirements rather than treating “passwordless” as a mandatory property of FIDO/WebAuthn.

Synced passkeys improve usability and recovery across devices, while device-bound credentials can be appropriate where organizations need tighter hardware or enterprise control. The security decision should be documented as a policy choice, not inferred from the marketing label “passkey.”

Attestation vs Authentication: Do You Need Authenticator Provenance?

Authentication proves possession and use of the credential’s private key for the relying party. Attestation is different: during registration it can provide information about the authenticator and, depending on the attestation mode and deployment, evidence about its provenance or characteristics.

Many consumer/passkey deployments do not need to identify an authenticator model, and unnecessary attestation requirements can reduce privacy or device compatibility. Enterprise environments may have a stronger reason to restrict registration to managed hardware or approved authenticator classes. Define that requirement before turning attestation into an allowlist.

Attestation also does not make recovery secure by itself. Protect credential enrollment, device replacement and recovery with assurance comparable to the primary sign-in flow. A phishing-resistant login can still be undermined if an attacker can register a new authenticator through a weak help-desk or password-reset path.

Migrating From Passwords to WebAuthn

A practical migration often starts by allowing users to register a passkey/security key after an authenticated session, then making phishing-resistant authentication the preferred path. High-risk users can be moved first, followed by broader passwordless adoption once recovery, support and device-coverage questions are proven.

Avoid keeping a weak password-only recovery route that silently defeats the strongest authenticator. Recovery is part of the authentication architecture.

Runtime Visibility After Strong Authentication

WebAuthn strengthens the sign-in event, but the resulting application session still needs monitoring and authorization. Ammune can add runtime visibility into API behavior after authentication, complementing phishing-resistant identity with detection of suspicious post-login actions.

WebAuthn / FIDO Deployment Checklist

• Anchor implementation to WebAuthn Level 3 behavior supported by target platforms.
• Use mature server libraries.
• Verify challenge, origin, RP ID and signatures server-side.
• Define user-verification requirements by risk.
• Secure enrollment, replacement and recovery.
• Support multiple credentials per user.
• Plan passkey portability/device-loss support.
• Protect the post-login session and API authorization separately.

Frequently Asked Questions

Primary References