WordPress has no built-in cap on failed login attempts. An attacker, almost always an automated bot, can try thousands of password guesses in a row against your login page and WordPress will process every single one without complaint. Limiting how many attempts an IP gets before it’s temporarily blocked turns that unlimited automated attack into a slow, impractical one. Here’s how to actually add that limit, at whichever level fits your setup.
Method 1: a security plugin (the simplest option)
Most WordPress security plugins include login attempt limiting as a core feature, including in their free tiers, SecondGate’s brute-force lockout being one example. This is genuinely the recommended approach for most site owners, no code to write or maintain, and it’s usually paired with other related protections (rate limiting, IP blocking) in the same settings area rather than needing a separate tool just for this one thing.
Method 2: a dedicated code snippet
If you’d rather implement this directly, WordPress fires a wp_login_failed action hook every time a login attempt fails, which is what any plugin implementing this feature hooks into under the hood. A minimal version, storing a failure count per IP in a transient and blocking further attempts once a threshold is crossed, looks roughly like this in a custom plugin or your theme’s functions.php:
add_action('wp_login_failed', function($username) {
$ip = $_SERVER['REMOTE_ADDR'];
$key = 'login_fails_' . md5($ip);
$fails = (int) get_transient($key);
$fails++;
set_transient($key, $fails, 15 * MINUTE_IN_SECONDS);
if ($fails >= 5) {
wp_die('Too many failed login attempts. Please try again later.');
}
});Worth being honest about the limits of this approach: transients fall back to the database on hosting without an external object cache, which means this check itself becomes a database query on every failed attempt, and a genuinely large, sustained attack can add real load. A dedicated plugin typically implements a faster storage tier (an in-memory cache like APCu) specifically to avoid that problem at scale.
Method 3: server-level blocking with fail2ban
If you manage your own server (a VPS rather than standard shared hosting), fail2ban can watch your server’s access logs directly and block an offending IP at the firewall level after repeated failed WordPress logins, entirely independent of WordPress or PHP. This is a more advanced setup requiring server access and a custom filter definition matching WordPress’s specific log format, but it blocks earlier in the request chain than anything running inside WordPress itself can.
Set a sensible threshold, not the strictest possible one
A lockout threshold set too aggressively can genuinely lock out a real team member who’s simply mistyped their password twice. OWASP’s own authentication guidance recommends a reasonable middle ground rather than the strictest possible setting, a handful of attempts (commonly 3 to 5) before a lockout measured in minutes rather than hours for a first offense, which tends to work better in practice than the strictest available setting, mostly generating support requests from your own team instead of meaningfully stopping a determined attacker who’ll simply wait out a longer lockout anyway.
Whitelist your own IP if you’re testing this
While configuring and testing login limiting, it’s easy to lock yourself out accidentally through repeated test attempts. Most plugins offer a way to whitelist a specific IP address from the rate limit, worth doing temporarily while you’re actively testing the setup, then removing once you’ve confirmed it works as expected.
Verify it actually works
Deliberately fail a login a few times in a row (using a genuinely wrong password, not your real one) and confirm you’re actually blocked after the threshold you configured. This is one of those settings that’s easy to assume works simply because it was configured without an error message, actually testing the real behavior once is the only way to know for certain.
Where this fits into a broader security setup
Login attempt limiting is one of the most common, foundational protections on any WordPress security checklist, and it pairs naturally with enabling two-factor authentication, since even a successful brute-force guess stops being enough once a second factor is required too. For the complete picture, how to secure a WordPress site covers this alongside the rest of what actually matters.
