We’re excited to invite you to our next interactive Auth0 Community Ask Me Anything session on April 29.
This is your chance to learn how to strengthen your security posture, reduce the risk of phishing and credential theft, meet compliance requirements, and more. Whether you’re new to multi-factor authentication (MFA) or looking to optimize your current setup, this session will help you understand the value of MFA and how to tailor it to fit your needs.
How it Works
From April 10 to April 28, 2025, Auth0 developers, customers, and community members are invited to submit their MFA-related questions right here in the Auth0 Community. Just click “Reply” in this thread to join the discussion.
On April 29, from 9:00 AM to 11:00 AM PST, our product experts will be online and actively responding with detailed written answers to all questions submitted during the two-week period.
As a bonus, everyone who participates will earn points and a special community badge!
What You’ll Learn
What MFA is, how it works, and why it matters
Best practices for implementing MFA in your apps or platforms
How to balance strong security with a smooth user experience
Ways to customize MFA for different user types or risk levels
Tips for selecting the right authentication methods like biometrics, SMS, or authenticator apps
Real-world examples of how others have successfully rolled out MFA
Answers to your specific technical, strategic, or implementation questions
Submit your questions by clicking the “Reply” button below anytime between today, April 10, and April 28, 2025.
Featured Expert
Nithin Moorthy, Senior Product Manager
I’m trying to implement a more controlled MFA flow in a Post-Login Action, specifically avoiding email as a fallback and focusing on Phone, OTP, and WebAuthn Platform. I’m using enrollWith and challengeWith for this. My challenge lies in how to conditionally trigger a WebAuthn Platform (biometrics) challenge. I only want to prompt the user for biometric verification if their current device/browser has already been enrolled. If a user who enrolled biometrics on one device logs in on a new, unenrolled device, I don’t want to present the WebAuthn challenge. How can I detect existing WebAuthn Platform enrollment on the current device within a Post-Login Action to enable this conditional challenge?
Furthermore, I’m seeing an unexpected behavior with progressive enrollment. If a user enrolls in WebAuthn on macOS Safari and then logs into iOS Safari, they are prompted to enroll again, which then fails with an error. This issue reinforces the need for a mechanism within the Post-Login Action to accurately identify device-specific WebAuthn enrollments. Any insights on how to achieve both the conditional challenge and prevent this progressive enrollment error?
How can we monitor our Adaptive MFA implementation metrics to ensure success and gauge customer friction?
How many users were prompted for MFA?
Why was that user prompted?
Tracking attempts/failed logins?
We would want to know these things to determine if we want to build our own custom MFA trigger, rather than using Auth0’s logic. Thank you.
We appreciate your participation in the AMA thread by posting a question!
Your AMA Participant badge will be awarded once the event concludes—stay tuned!
We appreciate your participation in the AMA thread by posting a question!
Your AMA Participant badge will be awarded once the event concludes—stay tuned!
We appreciate your participation in the AMA thread by posting a question!
Your AMA Participant badge will be awarded once the event concludes—stay tuned!
@alex.caceres Hi Alex, welcome to the Auth0 Community!
Secondary authentication methods are great whenever we want to have a stronger assurance of the authentication from the user/client. Authentication methods follow three different assurance models:
inherence(who you are - ie biometrics)
possession(what you have - ie phone sms, phone voice, totp, etc)
knowledge ( security question, password, etc)
Most users are used to username/password flows, which is what a lot of SaaS companies implement today. However, passwords can be breached, security questions leaked, and now a malicious actor can access potentially sensitive resources and perform an account take over.
MFA is a secondary authentication method in addition to the primary authentication method to ensure that the user is who they say they are. Industry best practice is to use an authentication method that has a stronger security assurance model. Generally, inherence → possession → knowledge.
Additionally, MFA is great for step up authentication as well where you may want higher security due to sensitive authorizations. Think step up challenges for contextual access. An example of this would be to challenge when a logged in user tries to send a wire transfer.
Social Login on the other hand is different in the sense that it is a form of identification + authentication that is handled by a 3rd party provider. It is a way of authenticating an user with a 3rd party IDP using the OAuth protocol. This doesn’t necessarily mean that this is always a good idea or secure. For example, let’s imagine that I have a company(ACME) that I decided to act as a social login. ACME may only require authentication with username + password. If the user’s profile in ACME is breached, and your application allows users to use ACME to login. In effect, your application is breached as well. You do not have control of how the 3rd party IDP actually authenticates and validates an user. A common practice is to use social login + MFA with a strong security assurance.
One last point to call out is that most Social Login providers, such as Google, does have MFA built in it’s authentication flows as well. For example, if I am trying to login/sign up to application A in a different browser, location, and IP address than normal; Google would first request I sign in, and then likely challenge for a secondary authentication method such as Push notification to complete the authentication process. This is still using MFA as well, it’s just configured at Google.
Hope this answers your question! Please let me know if you have any thoughts or follow ups!
Hi Vinit,
I may need some additional context on the use case, and what you specifically would like to see happen. I’ll answer in some general terms with specific overtones that hopefully answers your question.
OOB - Email enrollment out of the box in Auth0 is special and intentionally designed as such to keep our customers safe. You would need to first enable email as an authenticator in the security page. This requires at least one other factor (TOTP, phone, etc) to also be enabled. You would also need email to be an identifier in the database connection as well. By default, Auth0 sends email verifications, and this is something you can configure to be required in Auth0. Once the user verifies the email, they are automatically enrolled in the email factor.
API approach - You can use the Management API or MFA API to enroll users in to email as well. This is also how we can configure email for the user who does not provide email through sign up.
Potentially upcoming feature enhancements:
The reason we treat email in this manner is due to how password resets used to work in Auth0. We used to only allow passwords to be reset by the email, and password reset is enabled by default for all tenants. The concern is that developers allow users to have email as a secondary factor with password as a primary factor. However, if the email was breached, a malicious actor could enter the email as an identifier, claim to forget the password, and reset the password through email. This effectively render the entire flow, which the developer thought had secondary authentication method, to be one with only one authentication method.
Now that password resets in Auth0 are not tied exclusively to Email. The product team is exploring features that allow email to be enrolled in flexible factors and through UL.
Today, this isn’t possible. The information of whether a challenge exists on the current device isn’t exposed today in Actions. This is a great product enhancement feature however, and it is something I’d like to explore implementing in some upcoming features!
The closest way to do this is to use Actions:
Check if the user is logging in with a new device
Check if the user is enrolled in WebAuthN
If so, prompt for challenge
This isn’t as perfect as checking if the information regarding the WebAuthN challenge was available in actions, but it can be close. That being said, this is something I will take under serious consideration as we improve our WebAuthN implementation.
`[quote=“sample, post:6, topic:185252, full:true”]
Furthermore, I’m seeing an unexpected behavior with progressive enrollment. If a user enrolls in WebAuthn on macOS Safari and then logs into iOS Safari, they are prompted to enroll again, which then fails with an error. This issue reinforces the need for a mechanism within the Post-Login Action to accurately identify device-specific WebAuthn enrollments. Any insights on how to achieve both the conditional challenge and prevent this progressive enrollment error?
[/quote]
`
Speaking of current WebAuthN implementation, the reason you are seeing some inconsistencies is due to the way have WebAuthN implemented today. Auth0 was one of the earliest supporters of WebAuthN as a platform due to its user experience and security benefits. As such, during the time of implementation; there were large open questions in the industry (W3C + CTAP) regarding how conditional mediation + excluded credentials works. We implemented the safest and most secure implementation with the information available at the time, which was to exclude credentials and handle conditional mediation from Auth0. Those open questions have now been answered by the W3C, with conditional mediation and backed up credentials. The inconsistency you are seeing is likely due to this mismatch.
This is an active feature that we are working with a delivery target for 2nd half of this year. You should these inconsistencies resolve themselves after that update.
Hi Vinit,
I may need some additional context on the use case, and what you specifically would like to see happen. I’ll answer in some general terms with specific overtones that hopefully answers your question.
OOB - Email enrollment out of the box in Auth0 is special and intentionally designed as such to keep our customers safe. You would need to first enable email as an authenticator in the security page. This requires at least one other factor (TOTP, phone, etc) to also be enabled. You would also need email to be an identifier in the database connection as well. By default, Auth0 sends email verifications, and this is something you can configure to be required in Auth0. Once the user verifies the email, they are automatically enrolled in the email factor.
API approach - You can use the Management API or MFA API to enroll users in to email as well. This is also how we can configure email for the user who does not provide email through sign up.
Potentially upcoming feature enhancements:
The reason we treat email in this manner is due to how password resets used to work in Auth0. We used to only allow passwords to be reset by the email, and password reset is enabled by default for all tenants. The concern is that developers allow users to have email as a secondary factor with password as a primary factor. However, if the email was breached, a malicious actor could enter the email as an identifier, claim to forget the password, and reset the password through email. This effectively render the entire flow, which the developer thought had secondary authentication method, to be one with only one authentication method.
Now that password resets in Auth0 are not tied exclusively to Email. The product team is exploring features that allow email to be enrolled in flexible factors and through UL.
You can monitor your MFA/AMFA implementation metrics in two different ways. From a high level perspective, you can use the Security Center to see visuals of authentications for your tenant and glean information regarding how many MFA authentications were issued, breached password detection, etc.
The second way is through the logs. Under Security → Multifactor-Auth, toggle the Enable Adaptive MFA Risk Assessment Toggle on. Now in all your login events, you will see the Adaptive MFA metrics such as the risk assessment, confidence score, new device, etc. You can use Log Streaming to stream this to a downstream SIEM provider if you’d like to store and analyze this data for longer than 30 days.
As a bonus, everyone who participates will earn points and a special community badge!
