RFC 8693 is now supported as of 1.70.0

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.

@andrzej-taramina Usually, when we see 403s on the hosted backend, the root cause ends up being an origin issue.

The endpoint calls need to originate from the same domain the FusionAuth instance lives at

There's some CORS information in this section of the hosted backend docs: https://fusionauth.io/docs/apis/hosted-backend#prerequisites

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?

Hey everyone,

We're making a change to how we handle community support, and we wanted to share the reasoning directly with you.

We're retiring support from the #general community Slack channel and making this forum the official home for community support. Starting 10/30/2026, all community questions and peer support will live here.

Why the change?

Slack conversations disappear and be difficult to search. A great answer given to one person in a Slack channel helps only that person — and then it's gone. Forums are different. Every question asked and answered here is searchable, permanent, and available to anyone who comes after you with the same problem. That means:

When you ask a question, you're not just helping yourself. You're building a resource for the whole community.

When you answer someone else's question, your expertise lives on and continues to help people long after the conversation ends.

The collective knowledge of this community compounds over time rather than getting lost.

We believe this is genuinely better for everyone here, and we're excited to build something more lasting together.

If you have questions about the transition, feel free to post them right here.

If you are coming over from the #general Slack channel, welcome to the forum.

If you are an existing forum member, please welcome our new members by helping them out with their questions!

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.

@damien For information on releases, please be sure to check out the release-notes. While it may not list which versions the issues were introduced in, it is recommended to stay on the latest version to avoid potential issues.