Limit login attempts in WordPress: the exact numbers
The lockout has two steps, both counted per IP address:
- 5 failed sign-ins in 15 minutes: that address is locked out for 15 minutes;
- 20 failed sign-ins: that address is locked out for 24 hours.
On by default.
WordPress brute force protection on every sign-in route
Failures are counted wherever they happen: the WordPress login page, the WooCommerce account login, and XML-RPC if you have turned it back on. A bot can't dodge the limit by switching from one door to another. A locked address is refused whatever password it sends next, even the right one.
On by default, as part of the lockout.
A WordPress login lockout for each account
Botnets get around per-address limits by sending each guess from a different machine. No single address ever reaches 5 failures. So WP SecureGate also counts failures against the account being attacked: 20 failed sign-ins on one account, from anywhere, lock that account.
Usernames attackers try first, such as admin and root, are locked on the very first attempt when no such account exists on your site. A name that belongs to a real account on your site is never locked this way.
On by default.
XML-RPC brute force
XML-RPC lets a script try passwords without loading the login page, which made it a favourite brute-force route. WP SecureGate switches it off by default. You can choose between on, authenticated-only and off if an app you use still needs it. If you turn it back on, failed sign-ins there count toward the same lockout.
Other one-click hardening, such as blocked user enumeration, is covered under WordPress security hardening.
XML-RPC is off by default.
Known attackers are stopped before they guess
Two address lists act on sign-in traffic. The signed attacker list, downloaded daily, carries addresses from public threat feeds, and in Block mode the firewall refuses them. Network learning adds addresses that 3 or more separate customer accounts have reported for attacks.
A network-only listing is refused on the places attackers aim at: sign-in, registration, password reset, XML-RPC, the user list and author enumeration. It is not refused on ordinary page views, so a listed address can still read your site. More on the lists in the WordPress firewall plugin guide.
On by default for both, with an active licence. Both lists refuse in Block mode, which new installs start in; in Monitor mode they only record.
CAPTCHA and two-factor codes on top
A CAPTCHA on the login form makes every guess slower for a script. It needs a provider, such as Cloudflare Turnstile, hCaptcha or Google reCAPTCHA, or the built-in math challenge; see the WordPress CAPTCHA plugin page.
Two-factor authentication is the backstop. If a password is guessed or leaked, the attacker still needs the code from the user's authenticator app. Our login security overview covers 2FA alongside the other sign-in layers.
Both off until you set them up. CAPTCHA needs a provider; 2FA is required for no role until you choose one.
The lockout allowlist, and getting back in
Addresses you add to the lockout allowlist are never locked out, and they don't trip the per-account lock either, so your office fumbling a password can't lock the account it belongs to. Use it sparingly. If one address keeps failing at one account while the lockout is off or the address is allowlisted, WP SecureGate raises an alert for unchecked password guessing, emailed if alerts are on.
Locked out anyway? Ask for the emergency link, which is emailed only to administrator addresses, or use a recovery code. With server access, wp securegate recover or the WPSG_SAFE_MODE constant lifts the lockout.
The allowlist is empty by default.
Part of WP SecureGate: Login security →