WordPress Login Security: Stop Brute Force, Enable 2FA (2026)

Open the access log of almost any WordPress site and you will see a steady stream of POST /wp-login.php and POST /xmlrpc.php requests from unfamiliar IP addresses, even on small sites. Those are automated bots guessing passwords. A single guessed administrator account is enough for an attacker to install a malicious plugin, inject spam links or lock you out of your own site. That is why WordPress login security is the first layer of defense worth setting up, before speed or SEO work.

In this guide, TeamDevDesign walks through how attackers get past the login page (brute force, credential stuffing, XML-RPC abuse, username enumeration) and the practical countermeasures for each, with sample configuration for Apache, Nginx and functions.php. Everything is checked against the official WordPress documentation as of 2025–2026.

Table of contents

• Why WordPress login security matters
• 4 common login attacks
• Layer 1: Accounts, passwords and roles
• Layer 2: WordPress two-factor authentication and passkeys
• Layer 3: WordPress brute force protection
• Disable or restrict XML-RPC
• Block username enumeration
• Securing wp-admin: IP rules, HTTP auth, WAF, custom login URL
• Application Passwords, sessions and login logs
• Login security checklist
• FAQ

1. Why WordPress login security matters

WordPress uses fixed login paths: /wp-login.php and /wp-admin/. Everyone knows them, so bots do not need to discover anything. They simply send login requests over and over using ready-made lists of usernames and passwords.

Many site owners assume their site is too small to be a target. In reality, most login attacks are not aimed at you personally. Bots sweep huge ranges of IP addresses and domains, and whichever site is weakest gets taken over. Compromised sites are then used to send spam, redirect visitors to scam pages or attack other systems.

The Brute Force Attacks guide on developer.wordpress.org recommends layering several controls: strong passwords, two-factor authentication, login rate limiting, XML-RPC protection, log monitoring and backups. No single plugin or config line is enough on its own, and this article follows the same approach.

Note: Login security is only one part of the picture. For the bigger view, read our overview of common WordPress security vulnerabilities.

2. 4 common attacks on the WordPress login

Knowing how attackers work helps you pick the right defenses instead of piling on plugins at random.

2.1. Brute force (password guessing)

A bot tries a long list of passwords against one username, usually starting with common ones such as 123456, admin@123 or the domain name plus a year. Short or predictable passwords fall quickly. Every attempt also makes PHP and the database do work, so a site under constant guessing can slow down noticeably.

2.2. Credential stuffing

Attackers take email and password pairs leaked from breaches of other services and try them on your site. If you reuse an old password, its length will not save you. According to the OWASP Credential Stuffing Prevention Cheat Sheet, multi-factor authentication is the most effective defense against this kind of attack.

2.3. XML-RPC attacks (xmlrpc.php and system.multicall)

xmlrpc.php is a legacy API that lets external apps publish posts and receive pingbacks. It also accepts a username and password, which makes it a familiar brute force target. The official WordPress docs point out that the system.multicall method has been abused to bundle many login attempts into a single HTTP request, slipping past tools that only count requests.

Current WordPress versions include an auth_failed flag in wp_xmlrpc_server::login(): after one failed login, further attempts in the same request are refused. Bots still send floods of individual requests to xmlrpc.php, though, so if you do not use it, block it.

2.4. Username enumeration

To guess a password, a bot first needs a username. WordPress can leak it in two ways:

• Author archives: visiting /?author=1 redirects to /author/author-name/. That slug is usually derived from the login name.
• REST API: /wp-json/wp/v2/users returns authors with published content, including id, name and slug (see the REST API Users reference).

A leaked username is not a serious hole if the password is strong and 2FA is on. It does, however, solve half the puzzle for the bot, so it is worth closing.

3. Layer 1: Accounts, passwords and roles

3.1. Strong passwords and a password manager

A good password is long (16 characters or more), random and never reused. The easiest way to get there is a password manager (Bitwarden, 1Password, KeePassXC or your browser's built-in one) that generates and stores passwords for you. You only need to remember one strong master password.

Avoid patterns like site name plus year, phone numbers or birthdays; bots already have dictionaries for those. The strength meter on the WordPress profile screen is a useful reference when you change a password.

3.2. Do not use the "admin" username

admin, administrator, webmaster and your domain name are the first usernames bots try. If your administrator account uses one of these, the safest fix is:

1. Create a new Administrator account with a hard-to-guess username.
2. Log in with the new account and confirm everything works.
3. Delete the old admin account and choose "attribute all content to" the new account so no posts are lost.

Also set a Display name publicly as value (in your Profile) that differs from the login name, so the login name does not appear under every post.

3.3. Least-privilege roles

Every Administrator account is a front door to your site. More doors means more risk. Give each person only the access their work requires:

Review the user list regularly. Remove accounts of former staff, previous web agencies and anything you do not recognize. An unknown administrator account is often a sign the site has already been compromised; in that case, see our guide to cleaning up a hacked WordPress site.

Add the following line to wp-config.php to disable the theme and plugin file editor in the dashboard. If an account is ever taken over, injecting PHP directly becomes harder (per the Hardening WordPress guide):

define( 'DISALLOW_FILE_EDIT', true );

4. Layer 2: WordPress two-factor authentication and passkeys

Two-factor authentication (2FA) asks for something besides your password, such as a 6-digit code on your phone. Even if the password leaks, an attacker cannot log in without the second factor. It is the single most effective control against both brute force and credential stuffing.

WordPress core does not ship 2FA, so you need a plugin. The Two Factor plugin on WordPress.org supports authenticator apps (TOTP), email codes and backup codes. For passkeys or hardware security keys, add WebAuthn Provider for Two Factor. Many all-in-one security plugins include 2FA as well.

In practice: require 2FA for every Administrator and Editor, and prefer an authenticator app or passkey. Print your backup codes or store them in your password manager so you do not lock yourself out.

5. Layer 3: WordPress brute force protection with login limits

Out of the box, WordPress allows unlimited password attempts. This layer slows down or blocks IPs that fail too often. There are three levels; pick based on your hosting.

5.1. A plugin that limits failed logins

This suits shared hosting where you cannot edit server config. Plugins such as Limit Login Attempts Reloaded, Wordfence, Solid Security and All-In-One Security can lock out an IP after a few failed logins. A sensible setup: 4–5 attempts, a 20–30 minute lockout, and a longer lockout for repeat offenders.

The trade-off is that every attempt still runs PHP and WordPress. Under heavy guessing the server still burns resources, so on a VPS it is better to block earlier, at the server level.

5.2. Rate limiting in Nginx

If your site runs on a VPS with Nginx (for example after you install WordPress on a VPS with aaPanel), you can cap requests to wp-login.php in the web server:

# Inside the http {} block
limit_req_zone $binary_remote_addr zone=wplogin:10m rate=10r/m;

# Inside the site's server {} block
location = /wp-login.php {
    limit_req zone=wplogin burst=5 nodelay;
    limit_req_status 429;
    # Keep your existing PHP-FPM pass-through lines here
}

This allows each IP roughly 10 requests per minute to the login page; anything above gets a 429 response. Real users are almost never affected.

Behind Cloudflare: if traffic goes through the Cloudflare proxy, Nginx sees Cloudflare's IPs rather than the visitor's. Configure the real_ip module first (set_real_ip_from plus real_ip_header CF-Connecting-IP), or you may end up throttling Cloudflare itself.

5.3. Server-level IP bans with Fail2Ban

Fail2Ban reads log files, spots IPs that send too many login requests and bans them in the firewall. The benefit is that banned IPs never reach PHP. A simple access-log based filter:

# /etc/fail2ban/filter.d/wordpress-login.conf
[Definition]
failregex = ^<HOST> .*"POST /(wp-login|xmlrpc)\.php
ignoreregex =

# /etc/fail2ban/jail.local
[wordpress-login]
enabled  = true
port     = http,https
filter   = wordpress-login
logpath  = /var/log/nginx/access.log
maxretry = 6
findtime = 600
bantime  = 3600

Point logpath at your site's real log file (on aaPanel it usually lives under /www/wwwlogs/). Installing Fail2Ban, SSH jails and the UFW firewall are covered step by step in our Linux VPS security guide. Add your own IP to ignoreip so you do not ban yourself.

6. Disable or restrict XML-RPC

Before switching it off, check whether you rely on XML-RPC. A few things may need it: older mobile app connections, remote publishing tools and some Jetpack features. If you do not use it, blocking it at the web server is the cleanest option.

Apache (.htaccess):

<Files "xmlrpc.php">
    Require all denied
</Files>

Nginx:

location = /xmlrpc.php {
    deny all;
    access_log off;
    log_not_found off;
}

If you cannot change the server config, you can use a filter in functions.php. Be aware that, per the xmlrpc_enabled filter reference, it only disables XML-RPC methods that require authentication; it does not disable the whole endpoint (pingbacks keep working):

add_filter( 'xmlrpc_enabled', '__return_false' );

If you must keep XML-RPC, rate limit it or allow only the IP ranges of the service that needs it, and make sure administrator accounts use 2FA.

7. Block username enumeration

The snippet below stops username discovery via ?author= and hides the REST API users endpoint from logged-out visitors. Put it in a child theme's functions.php or a small must-use plugin so it survives theme updates:

// Block username discovery via ?author=
add_action( 'template_redirect', function () {
    if ( isset( $_GET['author'] ) && ! is_user_logged_in() ) {
        wp_safe_redirect( home_url( '/' ), 301 );
        exit;
    }
}, 1 );

// Hide /wp/v2/users from logged-out visitors
add_filter( 'rest_endpoints', function ( $endpoints ) {
    if ( ! is_user_logged_in() ) {
        unset( $endpoints['/wp/v2/users'] );
        unset( $endpoints['/wp/v2/users/(?P<id>[\d]+)'] );
    }
    return $endpoints;
} );

Priority 1 makes the code run before WordPress's canonical redirect, which would otherwise send ?author=1 to the author archive and reveal the slug. The block editor keeps working because editors are logged in. Afterwards, open /wp-json/wp/v2/users in a private window to confirm.

This only reduces what is exposed. It does not replace strong passwords and 2FA. If your site has public author archives, the author slug still appears in URLs, so a hard-to-guess login name still matters.

8. Securing wp-admin: IP rules, HTTP auth, WAF and custom login URL

8.1. Allow only your IP on the login page

If you have a static IP (office or VPN), this is the strongest option: every other IP never sees the login page. Example based on the official WordPress docs (replace with your IP):

# Apache (.htaccess)
<Files "wp-login.php">
    Require ip 203.0.113.15
</Files>

# Nginx
location = /wp-login.php {
    allow 203.0.113.15;
    deny all;
    # Keep your existing PHP-FPM pass-through lines
}

With a dynamic IP (common on home connections), this can easily lock you out. HTTP auth or a WAF is a better fit in that case.

8.2. An extra password with HTTP Basic Auth

The browser asks for an extra username and password before showing wp-login.php. Bots cannot get past it, so they never reach WordPress:

<Files "wp-login.php">
    AuthType Basic
    AuthName "Restricted area"
    AuthUserFile /path-outside-web-root/.htpasswd
    Require valid-user
</Files>

Create the password file with htpasswd -c /path-outside-web-root/.htpasswd yourname and keep it outside the public folder. Apply it to wp-login.php only. The WordPress docs note that the older approach of locking the whole /wp-admin directory with Basic Auth tends to break front-end features that use admin-ajax.php.

8.3. Cloudflare and a web application firewall (WAF)

A WAF filters traffic before it reaches your server. With Cloudflare you can create rules for /wp-login.php and /xmlrpc.php: show a challenge (Managed Challenge or Turnstile), apply rate limiting, or restrict by country if your site only serves a local audience. Security plugins with an application-level firewall are another option on shared hosting.

8.4. Changing the login URL: reduces bot noise, not a primary defense

Plugins such as WPS Hide Login let you move /wp-login.php to a custom address. This cuts down blind bot traffic and keeps logs cleaner. Be clear about what it is, though: obscurity, not protection. The new address can leak through other plugins, emails or anyone who has seen it, and xmlrpc.php still accepts logins unless you block it.

Only change the URL after strong passwords, 2FA and login limits are in place, and save the new address in your password manager.

9. Application Passwords, sessions and login logs

9.1. Manage Application Passwords

Since WordPress 5.6, each user can create Application Passwords so external apps can call the REST API or XML-RPC. They cannot be used to log in through wp-login.php and by default only work over HTTPS, but they carry the same permissions as the account that owns them.

• Go to Users → Profile → Application Passwords and revoke any you no longer use or do not recognize.
• Give each one a clear name (for example "Publishing app - 2026") so reviews are easy.
• If your site does not need the feature, turn it off entirely:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

9.2. Log out unfamiliar sessions

On the Profile screen, the Sessions section has a Log Out Everywhere Else button. Use it if you have logged in on a shared computer, lost a phone, or suspect a leaked password. Administrators can also end other users' sessions from the Edit User screen. If you suspect a leak, change the password first, then end the sessions.

9.3. Turn on login logging

You cannot respond to what you cannot see. Activity log plugins (for example WP Activity Log or Simple History) record who logged in, when, from which IP, and who created users or installed plugins. At the server level, access logs show which IPs are hammering the login page with POST requests.

Red flags to check right away: successful logins at odd hours or from unexpected countries, new administrator accounts nobody created, unknown plugins. If you run many plugins, also read about WordPress plugin vulnerabilities, since one flawed plugin can let attackers bypass the login page entirely.

10. WordPress login security checklist

11. Frequently asked questions

Is changing the wp-admin URL enough to secure WordPress?

No. A custom login URL only reduces automated bot scans. If the password is weak or leaked, anyone who learns the new address can still log in. Treat it as an extra layer behind strong passwords, 2FA and login limits.

Will disabling XML-RPC break my site?

Most sites are unaffected because the block editor uses the REST API. Features that need XML-RPC include pingbacks, some remote publishing apps and a few Jetpack features. Check first, block second, then test your key features.

Which plugin should I use for WordPress two-factor authentication?

The Two Factor plugin on WordPress.org is a lightweight choice that supports authenticator apps, email and backup codes; add WebAuthn Provider for Two Factor if you want passkeys. If you already run an all-in-one security plugin with 2FA, you do not need another one. What matters most is making 2FA mandatory for admin accounts.

What if I lose my password or my 2FA device?

Use a saved backup code. If you have none, someone with hosting access can temporarily disable the 2FA plugin by renaming its folder via File Manager or SFTP, log in and set it up again. That is also why hosting and SFTP credentials need the same care as your WordPress password.

How can I tell if my site is under a brute force attack?

Typical signs: the site slows down unexpectedly, CPU usage spikes, the access log shows many POST /wp-login.php or /xmlrpc.php requests from many IPs, and your security plugin reports lots of failed logins. Turn on login limits, block XML-RPC and review your administrator accounts.

12. Conclusion

WordPress login security does not require expensive tools. Most of the risk drops sharply with a handful of steps: strong, unique passwords, no "admin" username, two-factor authentication, failed-login limits and blocking XML-RPC when you do not use it. IP rules, HTTP auth, Cloudflare and a custom login URL cut bot traffic further. No measure is absolute, but layered defenses make your site a much harder target than most.

If you would like someone to review and configure this for you, TeamDevDesign offers a website maintenance and management service that covers login hardening, plugin updates and regular backups. Feel free to contact TeamDevDesign to talk about your site.