In this guide · 8 sections
- 01Why the WordPress login is a target
- 02Step 1: Turn on two-factor authentication for every admin
- 03Step 2: Clean up admin accounts and usernames
- 04Step 3: Limit login attempts and add bot protection
- 05Step 4: XML-RPC and application passwords
- 06Step 5: Hosting-level protection and monitoring
- 07Do it yourself or get help?
- 08Frequently asked questions
Short answer
Turn on two-factor authentication for every admin (core WordPress lacks it, so use a plugin), remove unused admin accounts, rate-limit logins at the firewall or server, disable or restrict XML-RPC if unused, and give integrations application passwords, not your main password.
Why the WordPress login is a target
Automated bots try common usernames and leaked passwords against WordPress sites all day. WordPress's brute force guide describes these attacks and lists the defences below. A successful login as an administrator lets an attacker install plugins, add hidden users and inject spam or malware, which can get a site blacklisted by browsers and search engines.
The good news is that a handful of settings shut out most automated attempts, because bots depend on weak or reused passwords and missing second factors. Singapore's Cyber Security Agency gives the same core advice for any account: use strong passwords and enable 2FA.
Step 1: Turn on two-factor authentication for every admin
WordPress's handbook says to enable 2FA for all administrator accounts and notes that core WordPress does not include it, so you need a plugin or your identity provider. It also suggests considering passkeys through a reputable plugin for phishing-resistant login.
Install a maintained 2FA plugin
For example, the Two Factor plugin on WordPress.org supports authenticator apps (TOTP), email codes and backup codes. Many security plugins include 2FA as well.
Enrol every administrator and editor
Use an authenticator app rather than email codes where possible; email codes are only as safe as the mailbox.
Save backup codes
Store them in your company password manager so a lost phone does not lock you out.
Enforce it
Configure the plugin, or your security plugin, so admin roles cannot skip 2FA.
For the wider picture across email, banking and admin consoles, see our MFA set-up guide for business accounts.
Step 2: Clean up admin accounts and usernames
Every administrator account is a key to the whole site. Most small business sites have more than they need: the original developer, a former staff member, an SEO agency from three years ago.
Admin account clean-up
WordPress does not let you change a username from the dashboard. You can create a new administrator with a proper name, log in as them, then delete the old 'admin' account and attribute its content to the new user. WordPress's hardening guide also shows a database query for renaming it, best left to someone comfortable with the database.
Step 3: Limit login attempts and add bot protection
WordPress's brute force guide recommends rate-limiting login attempts at the edge (a web application firewall or CDN) or the web server, and adding a CAPTCHA or Cloudflare Turnstile-style challenge to the login form. Blocking at the edge stops bad traffic before it reaches your server, which also keeps the site fast during an attack.
| Layer | Example | Strength |
|---|---|---|
| Edge / WAF | Cloudflare, host-provided firewall, Sucuri | Strongest; blocks before your server does any work |
| Web server | Nginx or Apache rate limits on wp-login.php | Strong; needs server access |
| WordPress plugin | Limit-login or security plugin lockouts | Useful extra layer; runs after the request reaches WordPress |
| Login challenge | CAPTCHA or Turnstile on the form | Slows bots; small friction for people |
| Hidden login URL | Custom login path | Reduces noise only; not a defence on its own |
Step 4: XML-RPC and application passwords
Two less visible entry points matter as much as the login form.
- XML-RPC. The handbook calls xmlrpc.php a frequent brute-force target, especially its system.multicall method, which lets one request try many passwords. If you do not use XML-RPC, disable it. If something needs it, such as Jetpack or a mobile app, restrict it with firewall rules and rate-limit it aggressively.
- Application passwords. WordPress's application passwords page explains that this feature, added in WordPress 5.6, creates separate, individually revocable credentials for API access (the REST API, and XML-RPC where enabled). They cannot be used for normal browser logins, and by default they are available only over HTTPS. Give each integration its own application password and revoke any you no longer need.
- Do not need them at all? The same page says application passwords can be disabled with the wp_is_application_passwords_available filter, or limited to certain users with wp_is_application_passwords_available_for_user.
Step 5: Hosting-level protection and monitoring
Login security is only one layer. The rest of the hardening guide covers keeping core, themes and plugins updated, removing unused plugins and themes, enforcing HTTPS, and keeping logs.
Beyond the login
If an update itself breaks the site, our WordPress update broke my site guide helps roll back safely. If you find unknown admin users or spam pages, treat it as a compromise and follow our website hacked guide before changing anything else.
Do it yourself or get help?
Most of this is an afternoon's work for a site owner with admin access: install 2FA, clean up users, add the file-editor line, and turn on the firewall your host or CDN already offers. Server-level rate limiting and XML-RPC rules need hosting access and some care.
IT Sorted's Website Security Hardening (S$290) covers core, theme and plugin updates, removal of unused plugins and users, login protection with 2FA for admins, a web application firewall, security headers and an off-site backup. To keep it that way, Care (S$129 a month) adds monitoring, monthly updates, daily off-site backups and up to an hour of changes a month.
Frequently asked questions
No. WordPress's own security handbook notes that core WordPress does not include 2FA. You add it with a plugin, such as the Two Factor plugin on WordPress.org or a security plugin with 2FA, or through an identity provider. Enable it for every administrator account.
It can reduce the number of bot attempts in your logs, but WordPress's brute force guide says obscuring the login URL should not be your only defence. Two-factor authentication, strong unique passwords and rate limiting at the firewall or server matter far more.
If nothing on your site uses it, yes. WordPress's handbook calls xmlrpc.php a frequent brute-force target. If you rely on it for Jetpack, a mobile app or another integration, keep it but restrict it with firewall rules and rate-limit it aggressively.
They are separate credentials, introduced in WordPress 5.6, that let apps and scripts access the REST API, and XML-RPC where enabled, without using your main password. Each one can be revoked individually, they do not work for normal browser logins, and by default they are only available over HTTPS.
WordPress does not allow username changes from the dashboard. Create a new administrator account with a different name, log in with it, then delete the old admin account and attribute its posts to the new user. Renaming it in the database is possible but best left to someone experienced.