WordPress Security · Part 6 of 10

WordPress Login & Administrator Security.

An administrator account can change plugins, users, content and configuration. Protecting that account deserves more than changing the login URL and hoping bots go away.

Before you begin: have administrator access, a recent backup, a password manager and a tested recovery method. If you enable MFA, make sure you know how recovery codes or emergency access work before logging out.

Why the login is such a valuable target

Every normal WordPress installation needs a way for authorized users to sign in. Bots know that. They continuously test login endpoints with common usernames, leaked password combinations and automated credential-stuffing tools.

A successful administrator login can be more valuable than finding a minor page vulnerability because the attacker may gain legitimate application permissions.

Login attempt
Edge / rate controls
Password
MFA

Start with the accounts themselves

Give administrator privileges only to people who need them. A content editor usually does not need permission to install plugins. A former employee or contractor should not retain an unused account indefinitely.

✓ Use a separate account for each real administrator—no shared “office admin” password.
✓ Remove accounts that are no longer required.
✓ Use the lowest role that fits the person's job.
✓ Review administrator accounts periodically.
✓ Keep the account email address current so recovery goes to the right person.

Strong unique passwords are still essential

A long unique password generated and stored in a reputable password manager is far stronger than a memorable password reused across services. Reuse is especially dangerous because a breach at an unrelated service can give attackers a credential pair to test against WordPress.

Do not email administrator passwords around or keep them in an unprotected spreadsheet. The strongest WordPress settings cannot protect credentials that have already been exposed elsewhere.

Add multi-factor authentication

MFA requires another factor in addition to the password. If an attacker obtains the password, that second factor can prevent the login. Authenticator apps or hardware-backed methods are generally preferable to relying solely on SMS where stronger options are available.

Recovery matters just as much as activation. Store recovery codes securely and understand how an authorized administrator can regain access if a phone is lost.

Reduce brute-force noise without locking out customers

Login-attempt limiting, Cloudflare rate controls and application security tools can slow or block repeated failures. The threshold should tolerate normal human mistakes while reacting to automated behaviour.

Be careful with permanent IP blocks. Offices, mobile users and internet providers may share or change addresses. A temporary limit or managed challenge can be more forgiving than a permanent block.

Steve's Tip: I use layers here too. Cloudflare can reduce obvious automated traffic before it reaches the site; WordPress security tooling can see application-level login behaviour; MFA protects the account even if a password gets exposed.

Should you hide or rename the WordPress login URL?

Changing the default login path can reduce noise from unsophisticated bots and can be a useful convenience layer. It is not authentication. If the custom path becomes known, your real protection still comes from credentials, MFA, rate controls and account management.

Any login-path change also needs documentation. Locking out your own maintenance team six months later is not a security win.

What about XML-RPC and other authentication paths?

Some WordPress features and third-party services can authenticate through endpoints other than the normal login form. If the site does not use XML-RPC functionality, restricting it may reduce unnecessary attack surface. If a service depends on it, blocking it blindly can break that service.

The same principle applies to REST/API access: understand what the site uses before restricting it.

Protect the administrator environment

Administrator security extends beyond WordPress. Keep the administrator's email account protected with MFA because password resets often depend on it. Keep the computer/browser updated. Avoid logging into production administration from untrusted devices. Protect hosting and Cloudflare accounts too—an attacker with those credentials may not need WordPress at all.

What should you monitor?

Look for repeated failed logins, unexpected administrator creation, password/email changes, plugin installation, unusual geographic patterns and logins at odd times. Do not assume every failed login is a crisis; failed attacks are common. The important event is a successful action you cannot explain.

Common questions

Is “admin” automatically unsafe as a username?

A predictable username removes one unknown from a login attempt, so a unique administrator username is preferable. But changing the username is not a substitute for a strong password and MFA.

Will MFA stop every account takeover?

No security control is absolute, but MFA significantly raises the bar when passwords are guessed, reused or stolen.

Should clients all share one administrator account?

No. Individual accounts improve accountability and allow access to be removed without changing everyone else's credentials.

Important: Login-security changes can lock out legitimate administrators. Back up first, keep recovery information and test the new login process before ending the existing session.

Next: spam and automated bots

Part 7 looks beyond login attacks to contact-form spam, scanners, resource-consuming bots and the layers that can reduce them.