Client Trust

Client Trust is Clerk's defense against credential stuffing⁠ attacks - a type of attack where bad actors use lists of stolen passwords to attempt to gain unauthorized access to user accounts.

When Client Trust is enabled, Clerk treats every new device as untrusted until the user has verified their identity with a second factor.

How Client Trust works

Client Trust automatically requires a second factor when all of the following conditions are met:

1. The user enters a valid password.
2. The user hasn't enabled multi-factor authentication (MFA).
3. The user is signing in from a new device.

When these conditions are met, Clerk sends a one-time verification code to the user's email address or phone number. The user must enter this code to complete the sign-in process.

Enable Client Trust

Client Trust is automatically enabled for Clerk applications created after November 14, 2025. For applications created before this date, you can enable Client Trust in the Clerk Dashboard:

1. In the Clerk Dashboard, navigate to the Updates⁠ page.
2. Enable the Client Trust update.

How Client Trust differs from traditional MFA

Impact on custom sign-in flows

If you've built a custom sign-in flow that allows password-based sign-ins using the Clerk API or SDKs, you'll need to handle the needs_second_factor status that Client Trust can trigger.

When Client Trust requires verification, the sign-in attempt will return a status of needs_second_factor with email_code in the supportedSecondFactors array. Your flow should:

1. Check if the sign-in status is needs_second_factor.
2. Check if email_code is in the supportedSecondFactors array.
3. Call prepareSecondFactor() to send the verification code to the user's email address or phone number.
4. Collect the code from the user.
5. Call attemptSecondFactor() to verify the code.
6. If successful, set the session as active.

For a complete implementation example, see the email/password custom flow guide.

Limitations

• Password-only: Client Trust only applies to password-based sign-ins. Passwordless authentication methods (such as email links, OTPs, passkeys, and OAuth) are not affected.
• Email/Phone number required: Client Trust requires the user to have a verified email address or phone number to receive the verification code.