Skip to content
itsorted.online
Maintenance guide

Securing the WordPress Login: 2FA, Limits and Admin Accounts

The WordPress login page at /wp-admin is one of the most attacked pages on the internet, because a single guessed or leaked admin password gives full control of the site. Securing it does not need deep technical skills. This guide covers the measures that matter, in order of impact: two-factor authentication for every admin, fewer and better-named admin accounts, rate limiting and bot protection on the login and XML-RPC, application passwords for integrations, and protection at the hosting or firewall level. Each recommendation follows WordPress's own advanced administration handbook.

By IT Sorted teamReviewed 7 min readHow we write guides
in

Key takeaways

  • WordPress core does not include 2FA; add it with a plugin or your identity provider for all admins.
  • Fewer administrators means fewer passwords that can hand over the whole site.
  • Rate-limit wp-login.php and xmlrpc.php at the firewall or web server, not only with a plugin.
  • Application passwords, added in WordPress 5.6, give integrations revocable API access without your main password.
  • Hiding the login URL reduces noise, but WordPress's handbook says it should not be your only defence.
In this guide · 8 sections
  1. 01Why the WordPress login is a target
  2. 02Step 1: Turn on two-factor authentication for every admin
  3. 03Step 2: Clean up admin accounts and usernames
  4. 04Step 3: Limit login attempts and add bot protection
  5. 05Step 4: XML-RPC and application passwords
  6. 06Step 5: Hosting-level protection and monitoring
  7. 07Do it yourself or get help?
  8. 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.

  1. 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.

  2. Enrol every administrator and editor

    Use an authenticator app rather than email codes where possible; email codes are only as safe as the mailbox.

  3. Save backup codes

    Store them in your company password manager so a lost phone does not lock you out.

  4. 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.

LayerExampleStrength
Edge / WAFCloudflare, host-provided firewall, SucuriStrongest; blocks before your server does any work
Web serverNginx or Apache rate limits on wp-login.phpStrong; needs server access
WordPress pluginLimit-login or security plugin lockoutsUseful extra layer; runs after the request reaches WordPress
Login challengeCAPTCHA or Turnstile on the formSlows bots; small friction for people
Hidden login URLCustom login pathReduces 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.

Rather have it done for you?

Fixed price, set up in your own accounts.

Order online, get a written scope, and keep full ownership of everything we set up. Questions first? Ask us in writing.