# How do I stop bots and require two-step login?

Source: https://help.didit.me/authentication/bot-protection-mfa-and-sessions
Updated: 2026-11-12

Turn on bot protection, require MFA, and set session length and password rules in Authentication, and see which settings need the Growth plan.

Open **Authentication → Bot protection** and switch on **Only allow humans** to protect sign-up, sign-in and password reset. Open **Authentication → Security and sessions** to choose who must use MFA, how long a session lasts, your password rules and your redirect URLs. MFA, custom session length and user bans need the Growth plan or higher.

![The Bot protection page in the Didit console, with the Only allow humans switch, Attack mode and the mode of each protection](https://help.didit.me/screenshots/auth-bot-protection-light.webp)

*Bot protection: choose Off, Log, Challenge or Block for each protection.*

## Bot protection

Bot protection is off by default. When you turn on **Only allow humans**, six protections watch every sign-up, sign-in and password reset:

| Protection | What it catches |
|---|---|
| **Bot detection** | Scripts, headless browsers and browser drivers, using device and form signals |
| **Credential stuffing** | One device or network trying many accounts, or a known breached password |
| **Brute force lockout** | Repeated failed attempts on one account |
| **Disposable emails** | Sign-ups, and email code or magic link sign-ins, from disposable email domains |
| **VPN and data center IPs** | Attempts from VPN, Tor or data-center networks, using Didit's IP analysis |
| **Impossible travel** | A sign-in far from the last one, too fast to be the same person |

Give each protection one of four modes:

| Mode | What it does |
|---|---|
| **Off** | The protection is not checked. |
| **Log** | The attempt goes through and Didit records the match. |
| **Challenge** | The person must pass an extra proof first. This is an email code or a passkey. |
| **Block** | The attempt is refused. |

Real people never see a puzzle. A blocked attempt never tells the caller whether an account exists. Each decision shows in **Authentication → Sign-ins**.

### Other protections

- **Breached password check**: new and reset passwords are checked against known breached passwords, and a breached one is refused. The password itself is never sent anywhere.
- **Attack mode**: for emergencies. Press **Turn on Attack mode** and choose how long it lasts: 1, 6 or 24 hours. While it runs, every sign-up and sign-in is challenged with a passkey, new sign-ups from data center networks are refused, and people without a passkey cannot finish until it ends. It turns itself off, your saved settings take effect again, and your team is notified when it ends.
- **Rate limits**: always apply, whatever your settings.
- **Lockout**: until you save bot protection settings, 5 failed passwords lock the account for 15 minutes. With brute force lockout on **Block**, the person must reset their password. You can also unlock the person yourself (see [users, sessions and organizations](https://help.didit.me/authentication/users-sessions-and-organizations)).

### Test in Sandbox

Automated browser tests count as bots. Run them in a Sandbox application with **Bot detection** on **Off** or **Log**.

## Allowlist and blocklist

On the Growth plan and above, and in every Sandbox application, your application's **Blocklist** and **Allowlist** in **Lists** apply at every sign-up, sign-in and password reset, whether or not bot protection is on. They are the same lists your verifications use, so a value you block there is blocked at sign-in too.

On the Free plan, a Live application's lists apply to identity verification only.

| List | What it does at sign-in |
|---|---|
| **Blocklist** | A person whose email address, phone number, IP address (or a range that covers it), device or user (their `vendor_data`) is on it cannot sign up or sign in. The attempt is refused and shows as **Blocked** in **Authentication → Sign-ins**. |
| **Allowlist** | An IP address (or range) on it skips **Bot detection**, **Credential stuffing** and **VPN and data center IPs**. An email address on it skips **Disposable emails**. A device on it changes nothing at sign-in. **Brute force lockout**, **Impossible travel**, attack mode, rate limits and the Blocklist always apply. |

- A person who is already signed in and is then added to the Blocklist is signed out within five minutes.
- A value on both lists is blocked.
- A change to a list applies within 30 seconds.
- Custom lists, such as High Risk Countries, do not apply at sign-in.
- If the lists cannot be checked, sign-in continues. A sign-in never fails because of this check.

## Security and sessions

**Authentication → Security and sessions** holds these settings:

| Setting | Options | Default |
|---|---|---|
| **Who must use MFA** | Everyone, Organization admins, Optional | Organization admins |
| **MFA methods** | Passkey, Authenticator app and Backup codes are all accepted. Choosing which ones is not available yet. | Any of these |
| **Session lifetime** | 1 day, 7 days, 30 days, 90 days | 30 days |
| **Ends when idle for** | 30 minutes, 2 hours, 1 day, 7 days | 1 day |
| **Minimum password length** | 8, 10, 12 or 14 | 10 |
| **Who can sign up** | Anyone, Invited people, Allowed domains (up to 100 domains) | Anyone |

Other settings on the page:

- **Several devices at once**: on by default. Turn it off to sign a person out of their other sessions at each new sign-in.
- **Sign out other devices when the password changes**: on by default. It ends every session after a password reset.
- **Email subaddresses**: whether an address with a plus sign, such as `name+tag@example.com`, is accepted. Off by default.
- **Allowed email domains**: used when sign-up is limited to allowed domains.
- **Allowlist and blocklist**: opens **Lists**, where you manage the application's lists. Where your plan includes it, both lists apply at sign-in, as the section above describes.
- **Redirect URLs** and **Allowed origins**: where people return after signing in, and which sites may call Didit. Register your exact addresses. Live applications accept `https://` only.

A session also ends when your team revokes or blocks the person, or when a refresh token is reused.

## What needs Growth

| Part | Plan |
|---|---|
| Two-step login (MFA), custom session length, user bans, allow and block lists at sign-in | Growth and up |
| 30 days of sign-in logs | Scale and up |

On a plan without these, **Security and sessions** shows "Security settings require an upgrade" with **View plans**. Sessions then have a fixed length. See [pricing and active users](https://help.didit.me/authentication/pricing-and-active-users).

Changing settings needs a role that can edit applications: Developer, Admin or Owner by default.

## Related

- [See sign-ins and sign out or block a user](https://help.didit.me/authentication/users-sessions-and-organizations)
- [What Authentication costs](https://help.didit.me/authentication/pricing-and-active-users)
- [Bot protection in the docs](https://docs.didit.me/authentication/bot-protection)
- [Authentication overview in the docs](https://docs.didit.me/authentication/overview)