Brute force attacks against WordPress login pages run continuously in 2026, with attackers cycling through compromised credential lists faster than ever. WordPress login security is no longer a single setting — it is eight separate defenses that work together, and missing any one of them leaves an obvious gap. This tutorial walks through each defense in order of priority.
Every defense below has been tested against the actual attack patterns showing up in WordPress access logs this quarter. They run on standard hosting without custom server access, and most take under five minutes to enable.
1. Move the login URL away from /wp-admin
The default /wp-login.php path is the first target every brute force tool checks. Changing it to a custom URL removes the site from automated scans entirely. The WPS Hide Login plugin handles this without editing core files: install it, set a new login slug like /access-2026, and save.
The change is invisible to legitimate users because you bookmark the new URL or distribute it through internal channels. Anyone hitting the old /wp-login.php gets a 404, which means automated scanners move on to the next target. This single change typically drops bot login attempts by more than 90 percent in the first 48 hours.
2. Enforce strong passwords on every account
Brute force attacks succeed when a single user has a weak password. Force the policy at the WordPress level using a plugin like Password Policy Manager: minimum 14 characters, mixed case, at least one number, at least one special character, and rotation every 90 days for administrator accounts.
Audit existing accounts before enforcement. Run wp user list --field=user_login through WP-CLI, then check each one against the Have I Been Pwned API. Any account that appears in a known breach gets a forced password reset before the new policy takes effect.
3. Require two-factor authentication for administrators
2FA stops every credential-based attack regardless of password strength. WP 2FA, Wordfence Login Security, and Two Factor Authentication by Stranger Studios all add TOTP support that works with Google Authenticator, Authy, or 1Password. Enable it for administrators first, then editors, then everyone with backend access.
For accounts that handle billing or store credentials, add hardware key support through WebAuthn. YubiKey and similar hardware tokens cannot be phished or intercepted, which is the strongest defense available. Our complete 2FA setup guide covers the configuration in detail.
4. Limit login attempts and lock out after failures
Native WordPress allows unlimited login attempts. Limit Login Attempts Reloaded caps it at 4 tries per IP per 20 minutes by default, which stops most brute force tools that depend on rapid retries. After the limit, the IP is blocked for 24 hours; repeat offenders get blocked for longer or permanently.
Configure these specific values in the plugin settings:
- Allowed retries: 3 attempts
- Minutes lockout: 30 for first lockout
- If 4 lockouts increase lockout time to: 24 hours
- Hours until retries are reset: 12
- Enable “Notify on lockout” for your admin email
Watch the lockout log for the first week to identify legitimate users who get caught. Whitelist their IP ranges if needed, but resist the urge to relax the limits — attackers will find any opening you leave.
5. Enable CAPTCHA on the login form
CAPTCHA blocks the automated tools that bypass IP-based rate limits by rotating through proxy networks. hCaptcha and Cloudflare Turnstile both work without exposing user data the way reCAPTCHA does, and both integrate with WordPress through free plugins.
Place CAPTCHA on three forms specifically: the login page, the registration page if open registration is enabled, and the password reset form. The reset form is the often-forgotten one, and attackers use it to enumerate valid usernames when login is locked down.
6. Disable XML-RPC if you do not use it
XML-RPC handles the same login flow as wp-login.php but without rate limiting in many configurations. Brute force tools target /xmlrpc.php precisely because the defenses on the main login form often miss it. If you do not use the WordPress mobile app or Jetpack remote features, disable XML-RPC entirely.
Add this rule to the .htaccess file in your WordPress root: <Files xmlrpc.php> deny from all </Files>. For Nginx, add location = /xmlrpc.php { deny all; } to the server block. Verify the block worked by visiting yoursite.com/xmlrpc.php — it should return 403 Forbidden.
7. Block suspicious IPs at the WAF or firewall level
Defenses inside WordPress run after a request has already reached your server, which costs CPU and bandwidth even when the attack fails. A web application firewall blocks malicious traffic before it touches WordPress. Cloudflare, Wordfence, and Sucuri all offer this layer; the Wordfence vs Sucuri comparison covers which one fits which site.
Configure these specific firewall rules: block traffic from countries where you have no legitimate users, rate-limit requests to /wp-login.php at 10 per minute per IP, and block known malicious user agents like sqlmap, Hydra, and WPScan when those tools are not authorized for your site.
8. Monitor login activity and alert on anomalies
The eight-defense stack is only effective if you actually check whether it is working. Install a logging plugin like Simple History or WP Activity Log, then review weekly. Look specifically for these patterns: failed admin logins from unusual countries, successful logins outside of business hours, and account creation events you did not authorize.
Set up email alerts for high-priority events. Most logging plugins include this — you specify the event types and the threshold, and the plugin sends an alert when the threshold is hit. The right alerts for WordPress login security are: any administrator login from a new IP, more than 20 failed logins in an hour across any account, and any change to user role permissions.
What to enable first if you have 30 minutes
Run them in this order on a production site: change the login URL, enable 2FA on every administrator account, install Limit Login Attempts Reloaded with the values above, and disable XML-RPC if your stack does not need it. Those four defenses block more than 95 percent of the attack patterns in current WordPress access logs, and they are reversible if something breaks.
The remaining four defenses — CAPTCHA, password policy, WAF rules, and activity monitoring — go in over the next few days. Together they make WordPress login security strong enough that brute force becomes a waste of time for the attacker, which is exactly the goal.