This is a confirmed bug in FusionAuth 1.69.2. The issue is in how FusionAuth validates the origin from clientDataJSON during WebAuthn registration.

This has been fixed and will be released in the next release. Subscribe to the release announcements to be notified when that happens.

Unfortunately, Passkeys cannot currently be used as an MFA method in FusionAuth's native hosted MFA flow. There is an open feature request for this functionality.

Workaround

You can implement a step-up authentication pattern using FusionAuth's WebAuthn API:

After the user completes email + password login, your application calls /api/webauthn/start The authenticator produces a signature Your application calls /api/webauthn/assert to verify possession of the passkey Only grant access if the assertion succeeds

You can check whether a user has a registered passkey by calling /api/webauthn?userId={userId}.

Important limitation: This workaround runs in your application code, not inside FusionAuth's hosted MFA screen. Passkeys will not appear alongside email and authenticator app in the same native picker — you would need to build that UI and enforcement logic yourself in your application.

A feature request has been logged for native passkey MFA support in FusionAuth's hosted flow.

Related Documentation Authentication With WebAuthn & Passkeys - Complete guide to implementing WebAuthn/passkeys in FusionAuth WebAuthn API Reference - API endpoints for starting and completing WebAuthn authentication ceremonies Start a WebAuthn Passkey Assertion - Documentation for the /api/webauthn/start endpoint Retrieve a Passkey - How to check if a user has registered passkeys using /api/webauthn?userId={userId} Multi-Factor Authentication (MFA) - Overview of FusionAuth's native MFA methods (TOTP, email, SMS) Step-Up Authentication - General guidance on implementing step-up auth patterns in FusionAuth Can I do a step up authentication with WebAuthn/passkeys? - Community discussion on this exact use case

Yes, successfully logging in with a passkey will update the user's last login instant.

However, there are edge cases where a passkey can be used without updating the last login timestamp:

Scenarios where passkey use doesn't update last login:

Login flow interrupted — The user authenticates with the passkey, but the login is stopped before completion due to:

Failed MFA challenge User action requirement (e.g., forced password reset) Account lock or suspension Login validation Lambda or transactional webhook rejecting the login

WebAuthn assertion without login — If the user performed a WebAuthn assertion directly via the API, this counts as using the passkey but does not constitute a full login flow and therefore doesn't update the last login instant. The Complete a WebAuthn Passkey Assertion API validates the WebAuthn ceremony but "does not authenticate the user into an application." This is different from the Complete a WebAuthn Passkey Authentication API, which validates the passkey and authenticates the user, thus updating the last login instant.

Summary

A passkey being "used" is not the same as a completed login. The last login timestamp only updates when the authentication flow completes successfully and issues a token.

Related Documentation Complete a WebAuthn Passkey Authentication - The API that validates passkeys and authenticates users (updates last login) Complete a WebAuthn Passkey Assertion - The API that only validates passkeys without authenticating (does not update last login) Authentication With WebAuthn & Passkeys - Complete guide to WebAuthn/passkey authentication in FusionAuth Update Login Instant API - Manual API for updating login instants when implementing custom SSO Setting Up User Account Lockout - How account lockouts can interrupt login flows

This is totally possible.

You want to start by understanding FusionAuth passkey setup and the normal flow.

Then, in your application, probably using one of the client libraries, you want to do the following for a user:

see if a user has a passkey set up, using the "retrieve a passkey" API. If this returns 0 passkeys, show the prompt. for the prompt, you have two options: use the API/client library to start the passkey registration process from within your application directly send them to the user management page to add a passkey (requires a paid license)

The right way to do the latter depends on your application needs (are you okay with a redirect) and whether or not you have at least a starter license.

For reporting on the number of users that have set up passkeys, unfortunately you have to query all your users and then pull the passkey data individually. There's no way to use the elasticsearch syntax to do the query as of yet. There's an open github issue to add that functionality.

We have an open issue to make passkeys one of the supported MFA methods.

But you can perform a step up passkey challenge using the APIs or the SDKs by doing the following:

User tries to access a restricted resource Customer app sees if the user has already been granted access (via the presence of a cookie, or some other mechanism). If they have, let them through. If the user hasn’t been granted access, perform a webauthn assertion workflow Call the /api/webauthn/start to get the workflow started Interact with the authenticator to produce the signature and whatever other information is needed. This is authenticator-specific. Call the /api/webauthn/assert to complete the workflow and prove possession of the authenticator If the workflow is successful Write a cookie or whatever if you want to remember this permission Let the user through If the workflow isn’t successful Deny access

If someone doesn't have a passkey enabled, which you can check by calling the /api/webauthn?userId={userId} API, direct them to the self-service account management passkey management pages.

Here are the API docs for the webauthn API.