Limit Login Attempts on WordPress to Stop Brute-Force Attacks

To limit login attempts on WordPress, use a plugin that counts failed sign-ins per IP address and per account and blocks the source when the risk crosses a threshold. User Security Guard for WordPress does this out of the box: install it, add your own IP address to its allowlist and start with the defaults. Strong passwords and a second factor still matter alongside it.

What a brute-force login attack looks like

A brute-force attack is automated password guessing. A script submits many username and password pairs to wp-login.php, often starting with names such as admin, until one works. Some attacks rotate through many IP addresses, and others probe for exposed files such as /.env first.

In your logs this shows up as bursts of failed sign-ins from one address, many failures against one account from many addresses, requests for default usernames that do not exist on your site, and repeated 404 requests for paths no real visitor asks for.

What you can do without a plugin

• Use long, unique passwords for every account, ideally from a password manager.
• Do not keep an account called admin, since it is the first name attackers try.
• Add a second factor for administrators. Guessing a password is not enough if a second proof is required.
• Ask your host whether it offers rate limiting at the server or firewall level.

None of this counts failed attempts or blocks the source on your site. That is the gap a login-limiting plugin fills.

Setting up User Security Guard step by step

The plugin requires WordPress 6.2 or later and PHP 7.4 or later. It is a paid plugin, but the documentation states that no sign-in protection feature checks the licence; the key only unlocks updates.

1. Download the zip under My Account → Downloads on wpexpertshub.com.
2. In WordPress, go to Plugins → Add Plugin → Upload Plugin, choose the zip, click Install Now, then Activate Plugin. The plugin then works with its default settings.
3. Open User Security → Allowlist, add your own IP address with a label and click Add to allowlist. The screen shows the address you are browsing from. Only add addresses you control.
4. Make sure the site has a second administrator account. The Dashboard and Settings warn when there is only one.
5. If the site is behind Cloudflare or another proxy, open User Security → Settings → Reverse proxies, tick Trust proxy headers and choose the header your proxy sets. Then check User Security → Tools → Sign-in diagnostics, which says “Working” when the visitor’s address is read correctly.
6. If another login-limiting plugin is active, keep only one. The plugin names the ones it detects, because two plugins counting the same failures can lock the wrong person out.

The key protections and their defaults

• Login limits: failed sign-ins are counted per IP address, username and email within a rolling window of 60 minutes (Counting window (minutes)). An address counts as suspicious after 5 failures (Suspicious attempts per IP), and the per-IP limit is 10 (Block after failed attempts from one IP).
• Administrator protection: administrator accounts get a stricter limit of 5 (Failed attempts before an admin account is treated as targeted).
• Default usernames: names such as admin that are not real accounts on your site are watched, and the address is blocked after 3 attempts.
• Exploit probing: an address that makes 5 requests for known exploit paths that answer 404 within 10 minutes is blocked from signing in.
• XML-RPC: blocked by default with a generic 403 (Block XML-RPC).
• WooCommerce: the My Account and checkout sign-in forms are protected when WooCommerce is active.

How blocking works

Before WordPress checks a password, the plugin asks whether the address or account is already blocked. If it is, the request is refused even when the password is correct. After a wrong password, a risk engine adds up points from signals and answers allow, suspicious or block. A request is blocked when a rule asks for a block or when the total reaches the block score of 80 (Risk score for “block”).

One point deserves care: the per-IP limit alone adds 60 points, which is below 80. The documentation gives this default example for an ordinary account guessed from one address with a normal browser. The 6th failed attempt marks the address suspicious. On the 11th, 60 points for the per-IP limit plus 20 for failures against the account reach 80 and the address is blocked. The count is one higher than the limit because counters are read before the latest failure is saved. A script using unknown usernames and a browser-like profile is marked suspicious, not blocked, unless you lower the block score.

Other facts worth knowing:

• Blocked visitors see the same generic message as for any wrong password: “The username or password you entered is incorrect.”
• Every block stores a readable reason. By default a block lasts until an administrator removes it. Automatic release after a set number of hours is opt-in (Release automatic blocks after (hours)).
• Administrator accounts are not blocked automatically by default. The plugin blocks the attacking address instead and sends an “Administrator block refused” alert.
• Blocks stop new sign-ins only. Sessions that already exist keep working until their cookies expire.
• The plugin does not add a CAPTCHA, hide wp-login.php or support authenticator apps. Its only second factor is an optional emailed code, off by default.

How to avoid locking yourself out

Start with the allowlist. Allowlisted addresses are never scored and never receive an automatic block. It has limits, though. It does not lift a block that already exists, it does not protect you from an account block, and it does not skip the email sign-in code. Treat each entry as a deliberate gap and add only addresses you control.

If you are locked out, the documentation lists these ways back in:

• WordPress’s “Lost your password?” link. Password reset is never blocked.
• Another administrator’s session: unblock the address or account under User Security → Blocked IPs or User Security → Blocked Users.
• WP-CLI, which works without a browser session:

wp wpus blocks
wp wpus unblock --account=your-admin-login --reason="Locked out"

You can also use wp wpus unblock --ip=<address>. If you turn on the email sign-in code and mail does not work, a correct password is still refused; use Send me a test email first, and wp wpus two-factor --disable is the way back in.

Emergency mode

During an attack, User Security → Tools → Turn emergency mode on tightens the limits at once. For example, the per-IP block limit drops to 2, the block score to 50, and XML-RPC stays blocked. It is never switched on automatically, your saved values are untouched, and blocks never lapse while it is on. Turn it off on the same screen.

What the security log and weekly digest show

User Security → Security Logs records 20 event types, filterable by event, risk level, result, address and date. Passwords, cookies, tokens and request bodies are never stored. Log rows are kept for 90 days by default. User Security → Dashboard adds a 14-day chart.

The security digest is a plain-text email, weekly by default, set under User Security → Settings → Notifications (Security digest). It reports the threat level, failed sign-ins, requests refused by existing blocks, new blocks, the five busiest IP addresses and the five most-targeted accounts. When nobody failed to sign in, it says so, which also shows the protection was running. The first digest arrives one full period after the schedule is first seen as switched on, and it needs WP-Cron.

Further reading

Every setting, WP-CLI command and alert is covered in the full documentation. Browse all plugins for more.