There are a couple different scenarios where a login record could have a blank application Id. Usually it is #1 or #2. It occurs in scenarios where the user can have a JWT/access token that does not have the application Id in it.

1. If a user is not registered for the Application they are logging into
2. FusionAuth makes a login record when a user is created since FA makes a JWT upon user creation
3. If you use the Login API, you can log in without an App ID because you don't have to provide an application on the API call.

We have a user who has logged in repeatedly, but the application is blank.

https://fusionauth.io/docs/apis/login#search-login-records doesn't mention anything about this.

What gives?

It's one thing to read about new features in the release notes and another to see them demo'd. If you're interested in what FusionAuth has been up to, come check it out tomorrow in our Q1 2026 edition of Shipped!

@batmysta Going to link to this issue.

@batmysta I know this is a bit of a "trick" answer, but the reality is the right answer depends on what exactly you want the user to have access for. I understand that the roles in FusionAuth may give more access than you may like (I.E. MFA is a tenant level settings, but there is no role just for MFA edit.), but there are some other options.

Again, depending on what you want to do and what version you are running, there is the idea of the Tenant Manager applicaiton. This will still not help you with MFA settings thought.

The other option is using the APIs. Since everything in The FusionAuth admin UI is API first, you could create your own application that would allow users you choose to edit them.

Hope this is useful.

@hvfa Apologies for being a bit AWOL. I hope for things to slow down and be able to take a look at this a little more closely next week.

I think the way I'd approach this is:

• import all users into FusionAuth

At cutover time:

• look at local database to see which password hashes had changed
• pull the user data from FusionAuth for each of these users
• delete the user
• re-import the user with the new password hash and the FusionAuth data, maintaining the same userId (if you provide the UUID, we'll use that)

I get that is an additional complexity, but hopefully that helps.

I have a large number of users. I want to import them into FusionAuth with their password hashes and the accompanying data like the factor.

But my cutover is going to be slow, so I expect some percentage of people to change their password hashes after the import.

So I'd like synchronize any password hashes that changed in the meantime, and then roll out FusionAuth.

I can't re-import password hashes for an existing user, and the User API doesn't let me update passwords hashes, per this closed issue: https://github.com/FusionAuth/fusionauth-issues/issues/348

What would you recommend?

@hvfa At first glance this looks like a domain issue. Can you share an example of how your Authorized redirect URLs and Authorized request origin URLs are set up in relation to the applications. Please feel free to use example domains like https://domain1/ or https://domain2 and so on. It may also be useful to give the other OAuth settings for the applications as well (be sure to redact or obscure and sensitive information).

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.