<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with email-mfa]]></title><description><![CDATA[A list of topics that have been tagged with email-mfa]]></description><link>https://fusionauth.io/community/forum/tags/email-mfa</link><generator>RSS for Node</generator><lastBuildDate>Tue, 27 Oct 2026 16:21:50 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/tags/email-mfa.rss" rel="self" type="application/rss+xml"/><pubDate>Invalid Date</pubDate><ttl>60</ttl><item><title><![CDATA[Why is MFA &#x27;Last used&#x27; null for first-time registrations with Email MFA enabled?]]></title><description><![CDATA[<p dir="auto">This is the <strong>expected behavior</strong> in FusionAuth. During first-time registration, when a user completes the MFA challenge (e.g., entering an email-based code), the <strong>Last used</strong> field for that MFA method is <strong>not</strong> populated immediately. It remains null after the initial registration flow.</p>
<p dir="auto">The <strong>Last used</strong> timestamp is only set on <strong>subsequent authentications</strong> after the user has been registered. Once the user logs out and logs back in (triggering a new authentication flow), the MFA method's <strong>Last used</strong> field will populate correctly with a timestamp.</p>
<p dir="auto"><strong>Important clarification:</strong><br />
Even though <strong>Last used</strong> shows null after registration, the user <strong>is still required to complete the MFA challenge</strong> 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.</p>
<p dir="auto"><strong>Regarding registration abuse:</strong><br />
If you're experiencing self-service registration abuse, the null <strong>Last used</strong> field is not the cause. Consider these mitigation strategies:</p>


<p dir="auto"><strong>Identity Pre-Verification</strong> (available since v1.62.0): Use the <a href="https://fusionauth.io/docs/lifecycle/manage-users/verification/identity-pre-verification-using-email" rel="nofollow ugc">Identity Pre-Verification Using Email Verification Form</a> feature to require email verification before completing registration.</p>


<p dir="auto"><strong>Third-party identity verification</strong>: Implement a self-service registration lambda that calls an external identity verification service via REST API before allowing user creation. <a href="https://fusionauth.io/blog/identity-verification-before-registration" rel="nofollow ugc">Fideo is a documented example</a>, but any identity verification system with a REST API can be integrated.</p>


<p dir="auto"><strong>Rate limiting and CAPTCHA</strong>: Consider additional anti-abuse measures at the application level to prevent automated registration spam.</p>


]]></description><link>https://fusionauth.io/community/forum/topic/3223/why-is-mfa-last-used-null-for-first-time-registrations-with-email-mfa-enabled</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/3223/why-is-mfa-last-used-null-for-first-time-registrations-with-email-mfa-enabled</guid><dc:creator><![CDATA[FASupportBot]]></dc:creator><pubDate>Invalid Date</pubDate></item></channel></rss>