Macro photo of a brass deadbolt on a dark teal front door at night, a key in the lock with a glowing hardware security key on its ring, for securing the WordPress login page.

هذا المقال متوفر باللغة العربية — اقرأ بالعربية

Every WordPress site has the same front door: /wp-login.php. Bots know where it is, they know the default usernames people pick, and they will knock on it all day whether your site gets ten visitors or ten thousand. This guide explains how to secure WordPress login step by step, using the official WordPress hardening and brute force guidance as the base: strong passwords, two-factor authentication, passkeys, login limits, application passwords, XML-RPC, user roles, edge protection, and what to do if you think someone already got in.

Why the login page is the most attacked part of WordPress

The WordPress Advanced Administration Handbook describes a brute force attack as the simplest way to break in: an attacker repeatedly tries username and password combinations until one works. These attempts are automated and often come from many machines at once, so even attacks that fail can slow your server down with the sheer number of requests.

The handbook is also honest that this is not a WordPress problem as such. Any web application with a login form gets targeted. WordPress is simply popular, so it attracts more of this traffic.

The reason this matters for a business site is simple. The official hardening guide points out that someone who gets into an administrator account can install malicious scripts that may compromise your entire server. A stolen admin login is not just a defaced homepage. It can mean spam sent from your domain, injected links that hurt your search rankings, or a store checkout that quietly sends customer data somewhere else.

The quick version: defenses that matter most

If you only have ten minutes, the brute force page on developer.wordpress.org lists the key defenses. In plain terms:

  • Use strong, unique passwords and a password manager.
  • Turn on two-factor authentication (2FA) for every administrator.
  • Consider passkeys (WebAuthn) for phishing-resistant login.
  • Rate limit login attempts, ideally at the edge (CDN or firewall) or the web server.
  • Protect or disable XML-RPC if you do not need it.
  • Keep WordPress core, themes and plugins updated.
  • Watch for unusual login activity and block abusive IPs temporarily.

The rest of this post goes through each one, with what to actually click and where the limits are.

How to secure WordPress login, method by method

Before the details, here is how the main methods compare. No single row is enough on its own. The point is to stack a few of them.

Method What it stops Effort Limits
Strong unique passwords Guessing and reused leaked passwords Low, with a password manager Does nothing if the password is phished
Two-factor authentication Logins with a stolen password Low to medium Each user must set it up; codes can still be phished
Passkeys (WebAuthn) Phishing and password theft Medium Needs a plugin and a backup authenticator
Limit login attempts Repeated guessing from one source Low Plugins still run PHP under heavy attack
Edge or server rate limiting Bot floods before they reach WordPress Medium Needs CDN, firewall or server access
Changing the login URL Noise from basic bots Low Not real protection on its own

1. Strong, unique passwords and a password manager

The WordPress documentation on password best practices recommends passwords of at least 20 characters, mixing lowercase and uppercase letters, numbers and special characters. It warns against names, birthdays, your company name and generic words like admin or password, and against using the same password on more than one site.

WordPress already helps here. When you create an account or reset a password, it suggests a generated password, and the documentation says these contain 24 characters. It also shows a strength meter when you change a password. Use both.

Nobody can remember twenty random characters for every account, and that is fine. A password manager stores them for you behind one strong master password. The same documentation recommends exactly this approach instead of reusing passwords.

Steps to fix passwords on an existing site:

  1. Install a password manager and create a long master password you can remember.
  2. In WordPress, go to Users, then Profile, and generate a new password with the built-in button.
  3. Save it in your password manager before you click Update Profile.
  4. Repeat for every administrator and editor, or ask each person to do it.
  5. Change the hosting panel, SFTP and database passwords too. They are doors into the same site.

2. Two-factor authentication

Two-factor authentication asks for a second proof after the password, usually a six digit code from an app on your phone. If someone steals or guesses your password, they still cannot log in without that second factor.

One thing surprises many site owners: the WordPress brute force handbook states that WordPress core does not ship 2FA. You add it with a plugin or through a single sign-on provider. Here are options I checked on their wordpress.org pages in October 2026:

  • Two Factor (by WordPress.org): supports authenticator apps (TOTP), email codes and backup codes. The plugin page lists version 0.17.0, 100,000+ active installations, and requires WordPress 7.0 or higher. Each user configures it from their own profile, under Users, then Your Profile, in the Two-Factor Options section.
  • WebAuthn Provider for Two Factor: an add-on for the Two Factor plugin that adds passkeys and hardware security keys such as Windows Hello, Touch ID and YubiKeys. The Two Factor plugin’s own FAQ recommends it for passkeys.
  • Wordfence Security: the main Wordfence plugin lists 2FA and passkeys among its login security features, along with a firewall and malware scanner.

A note if you used the standalone Wordfence Login Security plugin: its wordpress.org page says it was closed on August 17, 2026, permanently, at the author’s request, and it is no longer available for download. If you still run it, plan a move to another 2FA option rather than keeping a plugin that will not receive updates from the directory.

Steps to set up Two Factor:

  1. Take a backup, then install and activate Two Factor from Plugins, then Add New.
  2. Open Users, then Your Profile, and scroll to Two-Factor Options.
  3. Enable Authenticator App, scan the QR code with your app, and enter the code to confirm.
  4. Generate backup codes and store them in your password manager.
  5. Set the authenticator app as your primary method and click Update Profile.
  6. Log out and back in to test it before you ask other users to do the same.

Prefer an authenticator app over email codes for admins. If your email account is ever compromised, email codes go with it.

3. Passkeys (WebAuthn)

Passkeys let you log in with your phone, laptop fingerprint reader, face recognition or a hardware key instead of typing a code. The handbook describes them as phishing-resistant, because the browser will only use a passkey on the real site it was created for. A fake login page on a lookalike domain cannot collect it.

The handbook gives one practical rule worth repeating: enroll at least two authenticators per admin. If your only passkey lives on a phone that gets lost, you want a second device or a security key ready.

4. Limit login attempts

By default WordPress does not limit how many times someone can try to log in. A login limiting plugin counts failed attempts and blocks the source for a while after too many. Limit Login Attempts Reloaded is a popular option; its plugin page lists 1+ million active installations and version 3.3.10 at the time of writing.

The handbook adds an important limit here. A plugin runs inside PHP, so under a heavy attack every blocked request still costs your server some work. If your host or CDN can rate limit at the edge, prefer that, and keep the plugin as a second layer.

Application passwords: useful, but review them

Application passwords arrived in WordPress 5.6. They let an outside app or service (a mobile app, an automation tool, a reporting script) talk to your site through the REST API or XML-RPC without using your real password.

According to the Make WordPress Core integration guide, each application password is 24 characters long, made of letters and numbers, and shown in chunks like abcd EFGH 1234 ijkl MNOP 6789. WordPress records when and from which IP address each one was last used, and the guide notes the Last Used column is accurate to within 24 hours. That column is your best friend when cleaning up.

The REST API handbook explains that these credentials are sent with Basic Auth over HTTPS, and that you generate them from the Edit User screen. The integration guide also notes they are not available when the request is not over https://.

When to revoke an application password:

  • You stopped using the app or service it was made for.
  • Last Used shows it has not been touched in months.
  • A developer, agency or freelancer who created it no longer works with you.
  • You do not recognize the name or the IP address.
  • You suspect any kind of breach. Revoke all of them and create fresh ones only for the tools you still need.

To revoke, go to Users, open the user, scroll to Application Passwords and click Revoke next to the one you want to remove. If nobody on your site needs them, a developer can turn the feature off with the wp_is_application_passwords_available filter:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

This matters more now that many AI and automation plugins connect through the API. I covered the wider risks in my guide on checking AI plugins before you trust them with your site, and the same rule applies: give access only to what you use, and remove it when you stop.

XML-RPC: disable it or restrict it

xmlrpc.php is an older remote API that lets apps create posts, upload media and manage comments. The brute force handbook calls it a frequent brute force target, especially the system.multicall method, which lets an attacker try many passwords in a single request.

The handbook’s advice is clear: if you do not use XML-RPC, disable it. If you do (for example Jetpack or some mobile apps), restrict it with firewall rules and rate limit it aggressively.

Ways to handle it:

  • Block /xmlrpc.php at the CDN, firewall or web server if nothing on the site needs it. This is the cleanest option because the request never reaches PHP.
  • Use the xmlrpc_enabled filter. Be aware that the code reference describes this filter as controlling XML-RPC methods that require authentication. It does not switch off every XML-RPC method.
  • Many security and login plugins include an XML-RPC setting. Check what it actually blocks before you rely on it.
add_filter( 'xmlrpc_enabled', '__return_false' );

Test after any change. If a connected app or plugin stops working, that is your sign it was using XML-RPC.

Changing the login URL: honest pros and limits

Plugins that move wp-login.php to a custom address are popular, and they do something real: basic bots that only hit the default URL stop filling your logs. Fewer junk requests can also mean less load.

The limits are just as real. The brute force handbook says obscuring the login URL can reduce noise but should not be your only defense, and the hardening guide calls security through obscurity an unsound primary strategy. A custom URL does not protect XML-RPC, it does not help if a password is already leaked, and it can lock you out or break some plugins if it is set up badly. Write the new URL in your password manager, and treat it as a nice extra, not a lock.

User roles and unused admin accounts

WordPress has six predefined roles: Super Admin, Administrator, Editor, Author, Contributor and Subscriber. An Administrator has access to all administration features on a single site. Most people who touch a business site do not need that much.

The handbook’s operational tips line up with what I see on client sites: do not use the username admin, keep the number of administrators small, and use least privilege roles for daily work. The hardening guide adds that usernames like admin or webmaster are typically attacked first.

Steps for a user cleanup:

  1. Go to Users and filter by Administrator.
  2. For each account, ask: does this person still work with us, and do they need full admin rights?
  3. Change roles down where possible. A content writer needs Author or Editor, not Administrator.
  4. Delete accounts for people who left. WordPress will ask you to attribute their content to another user, so nothing is lost.
  5. If your main account is called admin, create a new administrator with a different username, log in with it, then delete the old one and attribute its content to the new account.
  6. Repeat this review on a schedule. It is one of the items on my monthly and quarterly WordPress upkeep list.

Cloudflare and server level protection

The handbook recommends edge and firewall protections (it names Cloudflare, Sucuri and host-provided firewalls) because bad traffic is blocked before it reaches your server. That keeps your site responsive even during a big attack, which a PHP plugin cannot fully do.

What you can do at this layer:

  • Rate limiting rules: Cloudflare’s rate limiting rules let you limit request rates for matching paths such as /wp-login.php and /xmlrpc.php. Check which rule options your plan includes.
  • Challenges: the handbook suggests a CAPTCHA or Turnstile on login to slow bots. Cloudflare Turnstile is one option, and several WordPress plugins add it to the login form.
  • Restrict by IP: if your team logs in from fixed IP addresses, the server can allow only those addresses to reach the login page.
  • Server rate limiting: on Nginx, the handbook shows an example like the one below.
  • Extra password layer: the hardening guide describes adding server-side Basic Auth in front of /wp-admin/, with a warning that this can break admin-ajax.php if done carelessly.
limit_req_zone $binary_remote_addr zone=logins:10m rate=10r/m;

location = /wp-login.php {
    limit_req zone=logins burst=20 nodelay;
    include fastcgi_params;
}

Test server rules on staging first. The handbook also advises against permanent country blocklists, since they block real visitors and are hard to maintain. For Arabic sites with customers across Egypt and the Gulf, plus travelers and expats, that warning matters.

What to do if you suspect a breach

Signs include new admin users you did not create, a host suspending your site, warnings in Google, visitors’ antivirus flagging pages, or changes nobody on your team made. The official FAQ on hacked sites suggests a calm, ordered approach. Here is a practical version of it:

  1. Write things down. Note what you saw, when (with time zone), and anything that changed recently, such as a new plugin.
  2. Take a snapshot. Back up the site as it is, even if infected, so you have a reference.
  3. Reset all access. Change passwords for every admin, plus hosting, SFTP and database. Revoke all application passwords.
  4. Log everyone out. Replace the secret keys in wp-config.php with new ones from the WordPress key generator. The FAQ explains this forces anyone still logged in off.
  5. Remove unknown users and check every remaining administrator.
  6. Scan the site and your own computer. The FAQ points out that some infections start on the site owner’s machine, through stolen saved logins.
  7. Talk to your host. On shared hosting the problem may be wider than your site.
  8. Clean or restore. Replace core files with a fresh copy of the same version, check .htaccess and theme files, or restore a known clean backup.
  9. Close the hole. Update everything, then add the protections from this guide so it does not happen again.

If the site shows errors after cleanup, my guide to troubleshooting the usual WordPress error screens can help you sort out what is broken and what is just cached.

WordPress login security checklist

Copy this list and tick it off. Most small business sites can finish it in an afternoon.

  • Every admin and editor uses a unique password of 20+ characters stored in a password manager.
  • No account uses the username admin.
  • 2FA is active for every administrator, with backup codes saved.
  • Each admin with passkeys has at least two authenticators enrolled.
  • Login attempts are limited, at the edge or server if possible, with a plugin as a backup.
  • XML-RPC is blocked, or restricted and rate limited if you need it.
  • Unused application passwords are revoked.
  • The number of administrators is as small as possible, and old accounts are deleted.
  • Hosting, SFTP and database passwords are strong and not shared by email.
  • The whole site runs on HTTPS.
  • WordPress core, themes and plugins are updated, and abandoned plugins are replaced.
  • A tested backup exists outside the server.
  • Someone checks failed login activity at least monthly.

Frequently asked questions

Is a strong password enough if I am the only user?

It helps a lot, but it does not protect you if the password is phished or leaked from another service. Adding 2FA to your one admin account takes a few minutes and closes that gap.

Does WordPress have built-in two-factor authentication?

The official brute force guide says WordPress core does not ship 2FA. You add it with a plugin such as Two Factor, a security plugin that includes it, or a single sign-on provider.

Should I disable XML-RPC on every site?

Disable it if nothing uses it. If you use Jetpack or an app that needs it, keep it on but restrict and rate limit it. Test connected services after any change.

Will changing the login URL stop hackers?

It reduces bot noise, but it is not real protection on its own. Use it only alongside strong passwords, 2FA and rate limiting.

Closing thoughts

Login security is not one plugin. It is a few simple layers: a strong password, a second factor, limits on guessing, fewer admin accounts, and a firewall in front. Each layer covers a gap in the others. If you would rather have someone set this up and keep an eye on it, that is part of what my SiteCare maintenance plans cover, or you can book a free consultation to review your current setup.

References