Why is MFA 'Last used' null for first-time registrations with Email MFA enabled?

[FASupportBot]

We have a tenant configured with MFA challenge = Required using Email MFA. When users register for the first time and complete the MFA challenge during registration, the MFA method's Last used field remains null in the user profile, even though they successfully entered the MFA code.

However, when the same user logs out and logs in again (in a new session), the Last used field updates correctly to show the timestamp.

Configuration:

• FusionAuth version: 1.69.2
• MFA challenge: Required (at tenant and/or application level)
• MFA method: Email

Question:
Is this the intended behavior for first-time registrations? We're concerned because it appears users can authenticate and receive access tokens even when the MFA Last used field is null, which we initially suspected might indicate incomplete MFA validation.

[FASupportBot]

This is the expected behavior in FusionAuth. During first-time registration, when a user completes the MFA challenge (e.g., entering an email-based code), the Last used field for that MFA method is not populated immediately. It remains null after the initial registration flow.

The Last used timestamp is only set on subsequent authentications after the user has been registered. Once the user logs out and logs back in (triggering a new authentication flow), the MFA method's Last used field will populate correctly with a timestamp.

Important clarification:
Even though Last used shows null after registration, the user is still required to complete the MFA challenge during the registration process. The null value does not indicate that MFA was bypassed — it simply means the "Last used" tracking starts from the second authentication onward, not the registration itself.

Regarding registration abuse:
If you're experiencing self-service registration abuse, the null Last used field is not the cause. Consider these mitigation strategies:

1. Identity Pre-Verification (available since v1.62.0): Use the Identity Pre-Verification Using Email Verification Form feature to require email verification before completing registration.

2. Third-party identity verification: Implement a self-service registration lambda that calls an external identity verification service via REST API before allowing user creation. Fideo is a documented example, but any identity verification system with a REST API can be integrated.

3. Rate limiting and CAPTCHA: Consider additional anti-abuse measures at the application level to prevent automated registration spam.