Passwordless sign-in now runs the same risk checks

Email-password sign-in already ran reCAPTCHA, bot detection, pre-authentication action hooks, and device risk before checking the secret. Email OTP, SMS OTP, TOTP, and magic-link verify did not. A passwordless flow could complete without those policies, which made "passwordless" a bypass of the risk stack rather than a different credential.

Those verify handlers now share one pre-auth helper.

This is the longer note behind the August 24 changelog entry.

What runs

enforcePasswordlessPreAuth runs, in order:

1. Captcha (reCAPTCHA v3 or Turnstile, when configured for that action)
2. Bot detection
3. pre_authentication action hooks

Device risk runs with the same policy set as password sign-in after the credential checks the handler already performed.

Handlers pass the identity they have ({ email } or { phone }) into the action-hook payload so hooks see the same shape as the password path.

Where captcha is skipped

Magic-link click-through and the SMS code page do not always carry a captcha token. For those verifies, skipRecaptcha turns off only the captcha gate so a globally enabled v3 policy cannot lock out a tokenless URL. Bot detection and action hooks still run.

Email OTP and TOTP verify still send a token when the hosted page collected one (otp_verify, mfa_verify, and related actions).

Trust boundaries

Risk checks are deny/allow on the request. They do not prove possession of the email or phone; the OTP, magic link, or TOTP secret still does that. Fail-open vs fail-closed follows the existing captcha and bot-detection add-on settings.

If you enable Turnstile or reCAPTCHA only on signin, passwordless verify actions are not covered until you add otp_verify, magic_link, or leave the action list empty.

Try it

Enable bot detection (and captcha if you use it), then complete an email OTP sign-in. Setup is in Bot protection. The original release note is in the changelog.