Topics tagged with suspicious

Why aren't user.login.suspicious webhook events firing despite emails being sent?

FASupportBot — Invalid Date

The user.login.suspicious webhook event requires the Client Risk Configuration to be enabled at the tenant level. Even though Risk Signals are evaluated by default, the webhook event itself won't fire unless this configuration is explicitly turned on.

To enable it:

Navigate to Tenants → Select your tenant → Edit → Security tab Find the Client Risk Configuration section Ensure it's enabled for your tenant

Additionally, verify that the user.login.suspicious event is enabled in the tenant's webhook settings:

Go to Tenants → Select your tenant → Edit → Webhooks tab Confirm user.login.suspicious is checked/enabled

Once both are configured, your webhook should start receiving user.login.suspicious events along with details about which Risk Signals triggered the suspicious login determination.

About Risk Signals and Email Volume

If you're seeing a significant increase in suspicious login emails after upgrading to 1.68.0 or later, this is because FusionAuth introduced comprehensive Risk Signals in version 1.68.0. Previously, only Impossible Travel was tracked. Now additional signals are evaluated including:

Untrusted Device Unrecognized Device Recent Password Change Recent Identity Change Dormant Password Suspicious Agent

All Risk Signals are enabled by default without any configuration changes.

Managing Email Volume

You can tune which Risk Signals trigger suspicious login alerts:

Go to Tenants → Select tenant → Edit → Security tab → Client Risk Configuration Disable specific Risk Signals that are generating too many false positives for your use case Monitoring Without Sending Emails

You can monitor webhook events while tuning your Risk Signals without sending emails to users:

Go to your tenant/application settings → Identities tab Change the Suspicious Login template to "No Template Selected" Monitor your webhook endpoint to see which Risk Signals are triggering Fine-tune your Risk Signal configuration Re-enable the email template once you're satisfied with the detection accuracy

The webhook fires whenever a Risk Signal threshold is met, independent of whether an email template is configured. This allows you to observe and tune the system before alerting end users.

Why are users receiving more suspicious login emails after upgrading FusionAuth?

FASupportBot — Invalid Date

This behavior changed due to the introduction of Intelligent MFA in FusionAuth 1.68, which significantly expanded the risk signals used to trigger suspicious login detection.

What Changed

Prior to version 1.68, suspicious login emails were primarily triggered by Impossible Travel detection (when a user appears to log in from geographically distant locations in an impossibly short time).

Starting in 1.68, FusionAuth added many more risk signals to the suspicious login detection system as part of the Intelligent MFA feature. This means more login scenarios now trigger the suspicious activity email.

How to Tune the Detection

If you want to restore the previous behavior or customize the risk detection to reduce false positives, you can configure this in your tenant settings:

Navigate to Tenant > Edit > Security > Client Risk Config Configure the risk signals that should trigger suspicious login alerts To match the pre-1.68 behavior, set it to only trigger on "Impossible Travel"

You can customize these settings to find the right balance between security and user experience for your application.

Why are suspicious login emails sent on every login after upgrading to 1.69.2?

FASupportBot — Invalid Date

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.