Device Trust

Device 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 Device Trust is enabled, Clerk treats every new device as untrusted until the user has verified their identity with a second factor⁠.

How Device Trust works

Device 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 uses an email code, SMS code, or email link based on your settings. The user must complete this verification to finish the sign-in process.

How long a device remains trusted

Device Trust doesn't have a separate, configurable trust duration. On web applications, Clerk recognizes a browser through the client authentication cookie, so the browser remains trusted for as long as that cookie remains present and valid.

If the cookie expires, is deleted, or is unavailable - for example, after the user clears their browser data, switches browser profiles, or starts a private browsing session without the existing cookie - Clerk treats the browser as a new device and may require second-factor verification again.

You can't configure the Device Trust duration in the Clerk Dashboard or for an individual sign-in attempt. To access the expiration time of the current client's authentication cookie, use the Client.cookieExpiresAt property:

For development instances, this property is always null. For production instances, it reports the cookie's current expiration time, but can also be null. Clerk can refresh the client cookie, so this value can change. A user can also delete the cookie before it expires. If you display the value, describe it as the current cookie expiration time rather than a guaranteed Device Trust expiration date.

Enable Device Trust

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

1. In the Clerk Dashboard, navigate to the Rules⁠ page under Protect.
2. In the Device Trust row, check the Status.
   • If Disabled, select Enable. In the dialog, toggle on Enable, then select Save.
   • If Enabled, Device Trust is already active and no action is required. To disable it, select Manage, toggle off Enable, then select Save.

How Device 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_client_trust status that Device Trust can trigger.

When Device Trust requires verification, the sign-in attempt will return a status of needs_client_trust with email_code, phone_code, or email_link in the supportedSecondFactors array. Your flow should:

1. Check if the sign-in status is needs_client_trust.
2. Check if email_code, phone_code, or email_link is in the supportedSecondFactors array.
3. Call prepareSecondFactor() for the selected strategy.
4. Complete the selected strategy's verification.
5. If successful, set the session as active.

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

Limitations

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