This behavior is likely due to changes introduced in FusionAuth 1.68.0 related to Intelligent MFA and Risk Signals.

Starting in 1.68.0, FusionAuth uses a variety of "Risk Signals" to determine when to trigger the Suspicious Login email. The email is sent whenever any enabled risk signal returns a HIGH value. One common signal that can cause this is:

DormantPassword: This signal triggers when a user's password hasn't been changed "in the last few months." If your users do not regularly rotate their passwords, this risk signal could be flagging every login as suspicious. Solution

You can fine-tune which Risk Signals are considered for your tenant:

Navigate to Tenants > Edit Tenant > Security > Customize Risk Signals Review the enabled risk signals Consider toggling off the Dormant Password signal if password rotation is not part of your security model, or adjust other signals as appropriate for your use case Testing

To verify this is the cause:

Try changing a user's password, then logging in again to see if the suspicious login email still triggers Alternatively, disable the Dormant Password risk signal temporarily and test login behavior

This should allow you to re-enable suspicious login notifications while avoiding false positives for normal login activity.

You do not need to reindex users after upgrading FusionAuth.

The reindexing process will not impact:

Users' ability to log in User registration for applications

However, there may be a small increase in load times if the reindex occurs during a high-traffic period for your application. The reindexing primarily affects search and user count operations in the administrative console, not end-user authentication flows.

If you do choose to reindex (for other reasons such as search optimization), it can be done safely without blocking user authentication.

Additional Context

When Would Reindexing Be Needed?

While upgrading FusionAuth typically does not require reindexing, there are specific scenarios where it may be necessary:

Specific version upgrades: Certain version upgrades may require a reindex—this is always noted in the release notes. For example, version 1.17.2 noted: "A reindex may be necessary depending on how you have upgraded your Elasticsearch cluster." Database restoration: If you restore FusionAuth from a database dump without migrating the search index, you will need to reindex. User imports: If you import users via the User Import API, a reindex may be needed. Search engine switching: When switching from the database search engine to Elasticsearch, a reindex is required.

In general, even after a temporary Elasticsearch outage, the index will sync up automatically without manual reindexing.

Why Authentication Is Unaffected

Elasticsearch is only used for search operations in the admin UI and search APIs—it is not queried during authentication. FusionAuth does attempt to update the Elasticsearch index during authentication, but this is done asynchronously (since version 1.30.2) and is not required to complete the login. This means that even if Elasticsearch is temporarily unavailable or reindexing, authentication should not be blocked.

Performance Considerations

Reindexing is an expensive operation and should be avoided unless necessary. It causes additional CPU and I/O overhead until complete. However, performance has been significantly improved in recent versions, and beginning in version 1.48.0, index aliases are used to minimize disruption to API requests during a reindex.

Related Documentation Upgrade FusionAuth Guide - Best practices for upgrading FusionAuth Release Notes - Always check for version-specific reindexing requirements Re-indexing Documentation - When and why reindexing might be needed Rebuild the Elasticsearch Index API - How to trigger a reindex programmatically Switching Search Engines - Guide for switching between database and Elasticsearch search

Rollback Process for FusionAuth Cloud

For FusionAuth Cloud deployments, the rollback process must be handled by FusionAuth support—it is not something you can perform yourself.

Plan Eligibility and Backup Retention Business and High Availability (HA) Deployments: Upgrade backups are retained and available for 30 days Basic Deployments: Backups are not included, so rollbacks cannot be performed How to Request a Rollback

If you identify an issue after performing the upgrade:

Open a support ticket with FusionAuth The support team will perform the complete database rollback for you Expected Downtime

The rollback operation typically takes 20 minutes to 2 hours, depending on:

Database size How quickly the operations team can complete the rollback

Note that this involves a complete database rollback, so plan for 1-2 hours of downtime.

Support During Upgrades

For production upgrades, FusionAuth can provide:

An engineer on standby during your scheduled upgrade window An on-call support number for emergency assistance Pre-Upgrade Best Practices

Before upgrading to 1.69.1:

Review Release Notes for breaking changes, database migrations, and API modifications Choose an Upgrade Strategy: Incremental (version-by-version) for lower risk Direct upgrade for speed (but requires thorough testing) Test in Staging to verify: Authentication flows, webhooks, and APIs function correctly Templates render properly Database migrations complete successfully Coordinate with Support to schedule the upgrade and have assistance available if needed

This appears to be a bug in how FusionAuth handles the OAuth flow during password reset when an active session exists.

Root cause:

When a user clicks the password reset link from their email, the link doesn't include response_type=code in the URL. Normally, FusionAuth adds this parameter automatically during the OAuth flow.

However, when the user already has an active login session in their browser (even though their MFA trust has expired), FusionAuth detects that session and takes a shortcut. Instead of starting a fresh OAuth flow where it would add response_type=code automatically, it attempts to reuse the existing session's OAuth state.

This saved OAuth state is incomplete and missing the response_type parameter. When FusionAuth tries to redirect back to the application after MFA verification, it encounters an OAuth error because response_type was never included in the saved state.

Temporary workaround:

Manually add response_type=code to the password reset URL until a proper fix is available. While this works, it's a band-aid solution.

Status:

This issue appears to have been introduced in a version before 1.69.2 and may require a bug fix from the FusionAuth product team to properly handle OAuth state in password reset flows when active sessions are present. There's currently no tracking GitHub issue that I'm aware of.

Usually no, upgrades don't log users out or invalidate tokens.

The one exception is if your upgrade path includes v1.60.0, where some tokens may be invalidated. Even then, users with a refresh token should self-heal without needing to log in again.

For most upgrade scenarios, you can expect minimal impact on active user sessions.

During an upgrade, FusionAuth monitors your deployment, and if it becomes unresponsive for more than five minutes, the on-call engineer is alerted. A snapshot of the database is taken before the upgrade, so a rollback is possible, though it is manual and would result in data loss from the time of the upgrade to the rollback. Rollbacks are very rare and have only happened once in the past four years.

You can safely upgrade directly to 1.59, and many customers do skip versions. The upgrade process is straightforward: once started, the deployment status changes to Upgrading and returns to Active when complete. For production instances, downtime is minimal (typically seconds, if at all) because multi-node deployments use rolling upgrades. Most upgrades take under 20 minutes, though in rare cases they can take up to an hour.

FusionAuth never forces you to upgrade, but if you are running a very old version (1–2 years behind) and encounter issues, support may request that you upgrade before troubleshooting.

Upgrading a Deployment

The best way to see this is to visit the theme history github repo.

It is mentioned in the theme upgrade documentation.

That looks like you haven't applied the migrations needed. Per the release notes, that upgrade will require database migrations: https://fusionauth.io/docs/v1/tech/release-notes/

As a reminder, you can have fusionauth do the database migrations, but only if you are in development mode (check fusionauth.properties). If you are in production mode, you'll have to apply the migrations yourself, as outlined here: https://fusionauth.io/docs/v1/tech/installation-guide/upgrade/#database

FYI a lot more FusionAuth Cloud details are available in the cloud installation guide.

Added missing db migration notices for 1.21.0 and 1.22.0.

Once you make the purchase, you will be given a license id. You’ll enter that license id into your self-hosted FusionAuth under the Reactor menu item. This will activate your license and enable all of the premium features.

If you also purchase an Edition that comes with support, you’ll see a new menu item on your account in the FusionAuth website. This will let you open support tickets or provide you with our support phone number if you have an emergency.