Unfortunately, lambdas won't help here. FusionAuth never exposes the password anywhere lambda code can access it, so you can't write a lambda that validates complexity.

You do have several other options, each with tradeoffs:

1. Low complexity for everyone, with MFA for franchise managers. Configure the tenant with low complexity rules and require MFA for the franchise manager group using the MFA lambda. The MFA lambda can be combined with most of the other options below.

2. Low complexity for everyone, with an IdP for franchise managers. Add an identity provider pointing to a different FusionAuth instance/tenant or a corporate directory, and have franchise managers authenticate there.

   • The FusionAuth instance can have more complex password requirements.
   • Add a Login Validation lambda that denies login for users in the franchise manager group unless they authenticated through that IdP.
   • Modify the theme to hide the IdP button on the normal login page.
   • Pass an idp_hint on the authorization URL for everyone in the franchise manager group.

3. Passwordless for restaurant staff. Let restaurant staff log in without a password and set higher complexity rules at the tenant level for everyone else.

4. Two tenants with separate applications. Create tenant A (low complexity) and tenant B (high complexity). Have the restaurant staff application use tenant A's ID and the franchise manager application use tenant B's ID. You could also use a universal application to represent the application.

5. Two tenants with a connector. Again, tenant A is low complexity and tenant B is high complexity.

   • Set up a connector from tenant B to tenant A, with MFA lambda rules in tenant B for franchise managers.
   • Configure the connector to not migrate users.
   • Have all users log in to the application in tenant B, which checks tenant A for restaurant staff.

All of these will work, but they have tradeoffs. Some may increase your MAU count, and some may add latency.

Why not per-application password rules?

As an aside, I don't expect FusionAuth to ever support different password rules per application, because it would lead to confusing user experiences:

• If the staff app requires 10 characters and the manager app requires 15, and a user registers in the staff app, what happens if/when they log in to the manager app? Do we deny the login? Force a password change?
• If the staff app requires 10 to 20 characters and the manager app requires 25 to 35, no single password can satisfy both. Would a user have to change their password every time they switch between the two apps? Can you migrate users between applications?

Can I enforce different password complexity rules for different groups of users (e.g., restaurant staff vs. franchise managers) logging into the same application and in the same tenant? Can a lambda help with this?

We have two kinds of users. Restaurant staff need a low-friction login with simple password rules, since they’re often signing in on shared devices or between shifts. Franchise managers can access sensitive data like payroll and financial reports, so they need stricter complexity requirements. Can we do this in a single FusionAuth setup, perhaps with a lambda?

Using FusionAuth 1.70.

Hi @david-kircheis,

The cross-platform authenticator passkey functionality is not available for the licensed community edition, only the platform passkey functionality.

The options I see for your use case are:

• talk to sales about an enterprise license, if it fits your business model. We do offer non-profit discounts in certain circumstances.
• use platform authenticators with all their limits
• move to a different identity provider

While we'd love to have FusionAuth used by everyone, we can't offer all features to every plan level. We recognize this limit means FusionAuth isn't the right solution for every authentication problem.

I appreciate you using FusionAuth now and hope it remains helpful to you.

Not as a single feature, but doable with some glue code. FusionAuth has no built-in “inactivity warning” workflow or scheduler for this.

It does give you the pieces: a lastLoginInstant on every user, a user search API, an email send API, and user deactivation. You wire them together with a small scheduled job (cron, Lambda, GitHub Action, etc.) outside FusionAuth.

Set up a daily job that does three things:

• Finds users whose last activity was about 55 days ago and who haven’t been warned yet.
• Sends them the warning email and records that you did.
• Finds users who are 60+ days inactive and marks them dormant.

If a user logs in during the 5-day window, their lastLoginInstant updates and they drop out of the step 3 query automatically.

Use the User Search API with an Elasticsearch/OpenSearch query on lastLoginInstant (milliseconds since epoch). This needs the Elasticsearch/OpenSearch search engine. The database search engine doesn’t support range queries on this field.

POST /api/user/search
{
  "search": {
    "numberOfResults": 500,
    "query": "{\"bool\":{\"must\":[{\"range\":{\"lastLoginInstant\":{\"lt\":1760000000000}}}],\"must_not\":[{\"term\":{\"data.dormantWarningSent\":true}}]}}"
  }
}

Compute the lt value in your job as now - 55 days (so replace 1760000000000). Users who have never logged in won’t have a lastLoginInstant, so decide whether to fall back to insertInstant for them.

You can use FusionAuth to send the email or your own system. If you choose the former, create an email template in Customizations → Email Templates, then call the Send Email API with the matching user IDs:

POST /api/email/send/{emailTemplateId}
{
  "userIds": ["<id1>", "<id2>"],
  "requestData": {
    "daysInactive": 55,
    "daysUntilDormant": 5
  }
}

Your template body can then use FreeMarker:

Hi ${user.firstName!"there"},

As part of our routine account security measures, we monitor accounts for
inactivity. We haven't detected activity on your account in the last
${daysInactive} days, and it is scheduled to be marked dormant in
${daysUntilDormant} days unless activity is detected.

Log in to keep your account active: https://login.example.com

requestData values are available at the top level of the template, so you can reuse the template if you change the thresholds later.

After a successful send, patch the user to record that they've been notified so you don't send them multiple emails:

PATCH /api/user/{userId}
{
  "user": { "data": { "dormantWarningSent": true, "dormantWarningSentAt": 1760000000000 } }
}

The must_not clause in the search query above then skips them. If the user logs in, clear the flag so they can be warned again in the future. A user.login.success webhook receiver that uses the API is a clean place to do that.

As far as what you actually do when the user is marked dormant, you have two options:

• Deactivate the user. DELETE /api/user/{id} (soft delete) sets active=false, which blocks login. To reactivate, call PUT /api/user/{id}?reactivate=true. Deactivation also fires a user.deactivate event that you can consume via webhook to notify downstream systems.
• Flag only. Set user.data.dormant = true and handle it in your app where you might do a step-up or force an account recovery. This is gentler and keeps the account usable after a step-up.

For a true “close the account” outcome, deactivate first. Hard-delete (?hardDelete=true) only after a retention period that satisfies your compliance requirements.

Caveats:

lastLoginInstant updates when a user authenticates. Silent token refreshes using an existing refresh token don’t necessarily count as logins, so a user with a long-lived session in your app could look inactive. If that matters, track your own activity timestamp in user.data (updated by your app or a webhook) and query that instead. Test this against your own setup before relying on it.

user.lastLoginInstant is global to the user within a tenant. Each registration also has its own lastLoginInstant (user.registrations[].lastLoginInstant). If “inactive” should mean inactive in a specific application, query on that field and filter by applicationId.

Run the job daily and use a window, not an exact day match, so a missed run doesn’t skip anyone.

Page through search results (startRow) rather than assuming one page covers everyone.

Test with a user whose lastLoginInstant you’ve backdated in a non-production tenant.

Make sure your Send Email API key has only the endpoints it needs (search, send email, patch user, deactivate).

I want to email users after 55 days of inactivity, warn them they’ll be marked dormant in 5 days, and then mark them dormant.

Does FusionAuth do this out of the box?

You want to use FusionAuth webhooks to push data into your pipelines. I imagine the JSON will differ, so you might need to modify your mapping layer, but we should be able to provide the data you expect.

Here's our general webhook documentation.

Some events you might be interested in:

• User login success which includes the authentication method
• User login failure
• Two factor method added
• User create

Where possible, avoid transactional webhooks because you're using this for analytics and transactional webhooks impact workflow duration negatively.

You can also use the Search API to get adhoc counts/true things up, but it won't necessarily have the richness of data of the webhooks.

Our data team has enjoyed lots of data points and insights from our existing auth solution. Specifically around users, data like:

• sign in type (Apple login, Google login, phone number, emails)
• MFA enabled/disabled
• what kind of MFA
• registration info

We have data pipelines set up to ingest and turn this data into meaningful insights for the business.

We want to make sure we maintain these important insights. How can we do this?

Hiya @florent-bossuyt ,

Thanks for using FusionAuth.

The upgrade to 1.59.0 added support for phone number as a first class identity. While I don't know for sure, it is possible that impacted lastLoginInstant. I'm not aware of any bug filed.

It's also possible you can find the data previously in the lastLoginInstant in the user.identities[x].lastLoginInstant value, available when you retrieve a user.

Since this is not a known issue, there's no documented procedure for reconciling the data, unfortunately.

Here's one approach, though.

If you have a database backup of the 1.57.0 release, you could stand up a FusionAuth instance pointing to that, and find all the users with a lastLoginInstant that is not null (set A). You'd then run the same query against your prod instance (set B). Then find the folks in set A who are not in set B (call them set C). Set C are the people you need to update.

Unfortunately, you can't update their lastLoginInstant directly. But you can fake a login using the passwordless APIs, which should set it. That is outlined here.

So you'd want to perform that for all the users in set C.

Hope that helps.

As of version 1.59.0, you can create users without passwords.

You can use the linked APIs, and that’s the option most people find first. The step-up flow in the API docs works, but means your app owns the challenge. It has to start it, collect the code, and handle the result. That’s a lot for what is basically “make the user log in again because they are about to do a sensitive thing.”

There’s another way that’s a little different, and it leverages login. Since version 1.60 the authorize endpoint supports the standard OIDC prompt and max_age parameters.

When your app hits a sensitive action, don't call any specific APIs. Instead, it can redirect the user to /oauth2/authorize with prompt=login and/or with a max_age small enough that their existing SSO session doesn’t satisfy it. FusionAuth shows the hosted login page, the user authenticates, and you get a fresh token back. Same code you already wrote for login, with one query parameter added.

Make sure you put the current page/location in the state so you can deliver the customer back to where they were. Here's a video on deep linking.

Using either max_age=0 and prompt=login end up in roughly the same place. I’d use max_age if you want a window like “re-auth if it’s been more than five minutes,” and prompt=login if you want it every time.

A successful redirect doesn’t prove everything. Your app still has to decide whether the token it’s looking at came from a recent authentication.

That’s what the auth_time claim is for. It’s a reserved claim in the JWT body (it moved there in 1.60, and lambdas can’t override it), so your resource server compares it against the clock and rejects beyond your threshold. If it’s too old, send the user back through authorize.

That’s basically the max_age half of RFC 9470, just without FusionAuth issuing the WWW-Authenticate challenge for you. You’d write that 401 yourself.

Caveats:.

• This forces a re-login, not necessarily a stronger one. If the user re-authenticates with a password and nothing else, you’ve proven recency and nothing about strength. If you need the second factor on that re-auth, you need MFA to actually fire. A static policy of Required will do it. On Enterprise, the MFA Requirement Lambda can make the decision per request.
• There’s no acr-style “this was step-up” claim. You get “authenticated at time T,” not “authenticated with a second factor at time T.” If your auditors need the latter, this approach won’t give it to you cleanly, and falling back to the step-up auth API is a better option.
• It’s a full redirect. For a banking-style “confirm this transfer” flow where bouncing the user to another page is a non-starter, the step-up API approach is still right.
• This only works when you are using the hosted login pages, not the Login API.

The short version: if sensitive actions are coarse-grained (“view the billing page,” “change the email address”), the redirect approach might work for you. It’s less code, the hosted pages handle the UI, and you’re not maintaining a custom MFA challenge.

But if you need per-operation binding or proof of which factor was used, look at the step-up API.