wp2shell: more than a month later. Confirm 6.8.6, 6.9.5, 7.0.2. Patched is not clean.

Read the advisory

WordPress Login Security Guide 2026

How to secure a WordPress login page: strong passwords, 2FA, failed-login limits, fewer admins, optional login URL rename, and monitoring that catches bots early.

Topics Hardening & checklists Login & access

Lars Koudal

Lars Koudal

Updated Published

How to secure a WordPress login: unique passwords, 2FA for admins, failed-login limits, fewer administrators, and monitoring that catches bots early. Most WordPress takeovers start with the login form. Lock that surface down and you remove a large share of everyday risk.

Product path when you are ready to configure tools: login protection and 2FA. This guide is the full playbook.

WordPress login security

What you are protecting

WordPress checks username/password, creates a session cookie, and grants capabilities based on role. Attackers try to break that chain with:

  • Brute force and credential stuffing against wp-login.php
  • Phishing that steals real admin passwords
  • Extra administrator accounts left behind after a compromise
  • Weak shared passwords across sites

You will not make login “unhackable.” You can make automated attacks expensive and noisy, and make a WordPress login page secure enough that bots bounce before they matter.

1. Passwords that are actually unique

  • Long random passwords from a password manager
  • Never reuse the same password on WordPress and email/hosting
  • No shared “company admin” password in a chat thread
  • Rotate when someone leaves or you suspect a leak

Monthly forced rotation for everyone is usually worse than unique long secrets plus 2FA. Related: password tips.

Serve the login over HTTPS so passwords and cookies are not sent in clear text. Force HTTPS at the host or with a careful redirect. Mixed-content admin pages undermine the rest of this guide.

2. Two-factor authentication

Require 2FA for administrators (and anyone who can install plugins). Authenticator apps are the practical default. Email codes work when you allow that method in Security Ninja. Keep recovery codes somewhere safe offline.

Set up 2FA with an authenticator app or email code

2FA stops a large number of “we got the password from somewhere else” incidents.

3. Limit failed logins (protect login from bots)

Bots will hammer the default login URL forever. Use login protection to:

  • Cap failed attempts per IP
  • Temporarily block noisy sources
  • Optionally rename the login URL so casual scanners miss the default path

Rename alone is obscurity. Pair it with rate limits and 2FA. Watch the walkthrough above for how this looks in Security Ninja.

4. Fewer administrators

Every admin is another phishing target.

  • Give editors, shop managers, and authors the lowest role that works
  • Audit the Users screen monthly
  • Remove access the day a contractor finishes

Avoid the default username admin on new sites when you can.

5. Watch the login trail

Hardening without visibility still fails quietly.

  • Review failed login / block events
  • Alert on new administrator creation when you can
  • Investigate sudden successful logins from odd locations
  • After big team changes, confirm who still has access

Security Ninja’s events logger helps here after protection is on.

6. XML-RPC and other noisy endpoints

XML-RPC is a common brute-force path when enabled. Disable it only if nothing you use needs it (some mobile apps, Jetpack-related flows, remote publishing). Prefer firewall rate limits when you must keep it.

Also watch for:

  • Open registration you forgot about
  • “Remember me” on shared computers
  • Application passwords you no longer need

7. After a suspected login compromise

  1. Reset passwords for all privileged users (from a clean device)
  2. Enable or re-check 2FA
  3. Remove unknown admins and odd plugins
  4. Invalidate sessions / rotate salts if the site was fully owned
  5. Scan for malware and close the entry point

Guides: signs of a hack, recovery steps, or hire cleanup.

Practical rollout

Today

  1. Unique admin passwords
  2. 2FA for admins
  3. Failed-login limits

This week

  1. Optional login URL rename
  2. Role cleanup
  3. Confirm alerts / event review habit

Ongoing

  1. Monthly user audit
  2. Keep Security Ninja (or your stack) updated

Security Ninja Pro includes login protection, 2FA, firewall, and scanning in one plugin. Start with the free security tests if you are not ready to buy yet.

Related video

Watch how login protection stops brute-force attacks.

Subscribe on YouTube Browse channel

Found this useful? Share it.

Frequently asked questions

How do I secure a WordPress login?+

Use unique long passwords, require two-factor authentication for admins, limit failed login attempts, keep the admin count low, and watch login events. Renaming the login URL helps against noisy bots only when you also use rate limits and 2FA.

How do I make my WordPress login page secure?+

Treat the login page as an attack surface: strong credentials, 2FA, failed-login caps, and optional rename of wp-login.php. Remove unused admin accounts and disable open registration if you do not need it. Product features for this live in Security Ninja Pro login protection.

How do I protect a WordPress login from bots?+

Cap failed attempts per IP, temporarily block noisy sources, and add 2FA so stolen or guessed passwords are not enough. Optional login URL rename reduces casual scanner noise. XML-RPC brute force needs the same rate limits if you keep that endpoint enabled.

Will renaming wp-login.php stop attacks?+

It reduces noisy default scans. Determined bots and targeted attacks still need rate limits and 2FA. Rename alone is obscurity.

Do I need 2FA for every subscriber?+

Usually no. Prioritize administrators and anyone who can install plugins or edit code.

Larger screenshot