A WordPress login hardening checklist

WordPress login security is not one setting, one plugin or one clever trick.

A hardened login system combines several independent controls so that the failure of one layer does not immediately give an attacker access to the website.

A practical model looks like this:

strong unique password
+
multi-factor authentication
+
limited login attempts
+
reduced username exposure
+
least privilege
+
secure HTTPS transport
+
controlled authentication endpoints
+
session management
+
monitoring
+
updates
=
stronger WordPress authentication

This matters because WordPress login attacks are not limited to an attacker manually typing passwords into wp-login.php.

Modern attacks can include:

• brute-force password guessing;
• password spraying;
• credential stuffing using leaked credentials;
• automated username discovery;
• XML-RPC authentication attempts;
• stolen session cookies;
• phishing;
• compromised administrator devices;
• weak or forgotten privileged accounts.

The official WordPress documentation on brute-force attacks recommends a layered defense that includes strong passwords, two-factor authentication, rate limiting, monitoring and protection at the server or edge where appropriate.

This checklist explains how to harden WordPress login security systematically without relying on security-through-obscurity or breaking legitimate authentication workflows.

1. Inventory every account that can log in

Before changing authentication settings, identify who can currently access the site.

Open:

Users
→ All Users

Review every account.

For each user, determine:

• who owns the account;
• whether the person still needs access;
• which role is assigned;
• whether the account is actively used;
• whether a privileged role is actually necessary.

Unused accounts are unnecessary authentication targets

An old Administrator account belonging to a former contractor remains useful to an attacker even if nobody on your team remembers it exists.

The safest account that no longer serves a purpose is usually an account that no longer has access.

Audit administrator accounts first

The potential impact of account compromise depends heavily on permissions.

A compromised Subscriber account and a compromised Administrator account do not have equivalent consequences.

WordPress implements authorization through roles and capabilities. The official WordPress User Roles and Capabilities documentation explains how permissions are assigned to users and checked throughout WordPress.

For a deeper site-level review, see How to Audit User Roles on a WordPress Site and WordPress User Roles and Capabilities Explained.

2. Apply the principle of least privilege

Users should have the capabilities required for their work, not the highest role available.

For example:

Writer
→ Author or Editor as appropriate

Content manager
→ Editor

Customer
→ Customer / Subscriber equivalent

Site administrator
→ Administrator

Do not assign Administrator simply because it avoids permission troubleshooting.

Why least privilege matters to login security

Login protection reduces the probability that an account is compromised.

Least privilege reduces the damage if compromise still occurs.

These are complementary controls:

authentication security
→ can the attacker become this user?

authorization
→ what can this user do?

3. Use strong, unique passwords

Every WordPress user, especially every privileged user, should have a unique password that is not reused on another service.

The official WordPress Password Best Practices documentation recommends long, strong passwords and explicitly recommends password managers.

Password reuse is one of the most important risks

Consider this situation:

same email
+
same password
used on unrelated service

unrelated service breached
↓
credentials leaked
↓
automated attacker tries them on WordPress

This is credential stuffing.

The attacker may never need to guess the WordPress password because someone else already leaked it.

Use a password manager

A password manager makes it practical to use a different random password for every service.

A good operational model is:

one unique password
for every account
on every site

rather than:

one memorable password
with small variations everywhere

Avoid predictable passwords

Do not use:

• company names;
• domain names;
• birth dates;
• names of family members;
• keyboard sequences;
• common dictionary words;
• season + year patterns;
• the username inside the password.

4. Enable two-factor authentication for privileged users

Two-factor authentication adds another authentication requirement beyond the password.

The concept becomes:

something you know
+
something you possess or control

For example:

password
+
TOTP code

Why 2FA changes the threat model

Suppose an attacker obtains:

username
+
correct password

Without 2FA:

credentials may be enough
→ login succeeds

With 2FA:

credentials valid
+
second factor missing
→ interactive login still blocked

The official WordPress brute-force guidance recommends 2FA for administrator accounts, while the OWASP Authentication Cheat Sheet identifies multi-factor authentication as one of the strongest defenses against password-related attacks.

Prioritize high-value accounts

If immediate organization-wide deployment is difficult, start with:

1. Administrators;
2. Shop Managers or equivalent privileged roles;
3. Editors with significant publishing access;
4. developers and maintenance accounts;
5. other sensitive users.

TheOneWP Two-Factor Authentication

TheOneWP Two-Factor Authentication adds TOTP-based authentication and supports role-based enforcement.

That allows stronger authentication to be required for privileged groups rather than depending entirely on users enabling it voluntarily.

Store recovery methods securely

A 2FA deployment needs a recovery plan.

Do not keep recovery information:

• inside the same compromised mailbox;
• in an unsecured shared document;
• in plaintext public project notes.

Test account recovery before an emergency

An authentication control is operationally incomplete if nobody knows how legitimate administrators regain access when a device is lost.

5. Limit repeated login attempts

WordPress can be attacked by repeatedly testing credentials.

The official WordPress brute-force guidance recommends rate limiting at the application, server, WAF or CDN layer.

The goal is not necessarily:

one wrong password
→ permanent account lock

That would create an easy denial-of-service mechanism.

The goal is to make large-scale repeated attempts expensive.

Typical controls include

• temporary throttling;
• progressively longer delays;
• IP-based rate limiting;
• account-aware throttling;
• WAF rules;
• CAPTCHA or challenge mechanisms after suspicious behavior.

The OWASP Authentication Cheat Sheet also recommends login throttling while warning that lockout systems need to avoid creating an easy denial-of-service attack against legitimate users.

For the WordPress implementation side, see How to Limit Login Attempts in WordPress.

Application-level rate limiting is not always enough

If WordPress must boot completely before rejecting every malicious attempt, high-volume attacks still consume:

• PHP workers;
• CPU;
• database connections;
• memory;
• bandwidth.

Block obvious abuse earlier where possible

A CDN, WAF or server-level rate limiter can reject unwanted traffic before WordPress performs the full request.

This is especially useful for high-volume attacks.

6. Monitor failed and successful login activity

Security controls should produce enough visibility to answer basic questions such as:

• Are failed logins increasing suddenly?
• Which accounts are being targeted?
• Are attempts coming from unusual locations or networks?
• Did an Administrator log in at an unexpected time?
• Are the same credentials being tested repeatedly?

Monitoring makes login attacks visible

Without visibility:

50 failed attempts
→ unnoticed

5,000 failed attempts
→ unnoticed

successful suspicious login
→ potentially unnoticed

See How to Monitor WordPress Login Attempts.

Do not alert on every single failed password

A public website will often receive some automated authentication noise.

Useful monitoring focuses on patterns:

• high frequency;
• privileged accounts;
• new sources;
• unusual timing;
• successful login following repeated failures.

7. Use HTTPS for every login

Credentials should never travel over an unencrypted HTTP connection.

The official WordPress Logging In documentation strongly recommends HTTPS and explains WordPress authentication cookies.

A login over HTTPS protects data in transit between:

browser
↕ encrypted connection
website

Redirect HTTP traffic to HTTPS

Do not rely on administrators remembering to type:

https://

Configure the site and infrastructure so insecure HTTP requests are redirected appropriately.

Secure the entire authenticated session

Login security is not only about protecting the password submission request.

After successful authentication, WordPress relies on authentication cookies.

If an attacker steals a valid session cookie, they may not need the password for that session.

8. Protect administrator devices too

A perfectly configured WordPress login cannot protect an Administrator whose computer is compromised.

Endpoint hygiene includes:

• up-to-date operating systems;
• updated browsers;
• device encryption;
• screen locks;
• malware protection where appropriate;
• avoiding unknown browser extensions;
• not storing credentials in insecure documents.

Authentication security extends beyond WordPress

The actual login chain is:

human
↓
device
↓
browser
↓
network
↓
WordPress authentication
↓
session

A weakness anywhere in that chain can matter.

9. Do not rely on changing the login URL alone

The standard WordPress login endpoint is predictable:

/wp-login.php

Automated scanners know this.

Changing the public login URL can reduce opportunistic requests that blindly target default WordPress paths.

But it is not equivalent to strong authentication.

A custom login URL is traffic reduction, not credential protection

Think of it as:

default endpoint
→ immediately obvious to generic bots

custom endpoint
→ less obvious to unsophisticated scanning

It does not make:

• weak passwords strong;
• stolen credentials invalid;
• 2FA unnecessary;
• rate limiting unnecessary.

TheOneWP Custom Login URL

TheOneWP Custom Login URL allows the native WordPress login location to be changed.

Use it as one defensive layer, not as the foundation of the site’s login security.

Test a custom login URL before logging out

When changing authentication routing:

1. keep the current administrator session open;
2. open a private browser window;
3. test the new login URL;
4. confirm login succeeds;
5. confirm the old route behaves as intended;
6. only then close the working administrator session.

10. Reduce predictable login identifiers

WordPress authentication can accept account identifiers according to site configuration and authentication logic.

An attacker who knows a valid identifier has one less unknown variable.

But hiding a username should not become the primary security mechanism.

A known username plus strong authentication can still be safe

The real problem is:

known username
+
weak or reused password
+
unlimited attempts

not simply:

known username

Avoid common administrative usernames

The WordPress Password Best Practices documentation recommends avoiding common usernames such as:

admin

because automated attacks commonly test predictable username/password combinations.

Review how identifiers become public

WordPress usernames or related identifiers can potentially be inferred through:

• author archives;
• REST API output depending on configuration and permissions;
• public author slugs;
• markup;
• plugin output;
• error messages;
• other application surfaces.

See How Attackers Collect WordPress Usernames and Email Addresses.

TheOneWP Restrict Login Identifier

Restrict Login Identifier can control the identifier accepted by supported WordPress login workflows.

This can reduce ambiguity or unwanted identifier types, but it should still be paired with strong passwords and 2FA.

11. Review author archive exposure

WordPress author pages can expose predictable public author information depending on theme and configuration.

If public author archives provide no useful visitor-facing functionality, review whether they are necessary.

TheOneWP provides:

• Hide Author Slug
• Disable Author Archive

Do not mistake identifier hiding for authentication strength

Reducing unnecessary exposure can make reconnaissance slightly harder.

It does not compensate for:

• password reuse;
• missing 2FA;
• unlimited login attempts;
• outdated plugins.

12. Understand username vs email login

Allowing email login can improve usability.

Restricting login to username or email can alter what information attackers need.

Neither choice is automatically secure by itself.

The more important controls remain:

unique password
+
2FA
+
rate limiting
+
monitoring

For the full comparison, see WordPress Login: Username vs. Email, Which Is More Secure?.

13. Review XML-RPC authentication exposure

Protecting only:

/wp-login.php

does not necessarily mean you have reviewed every WordPress authentication surface.

WordPress includes:

xmlrpc.php

for XML-RPC functionality.

XML-RPC can include authenticated methods

The official xmlrpc_enabled documentation explains that the filter controls XML-RPC methods requiring authentication rather than disabling every XML-RPC behavior.

Do not disable XML-RPC blindly

Some integrations may rely on it.

Audit whether the site uses:

• remote publishing;
• legacy applications;
• specific plugins or services;
• other XML-RPC integrations.

Then decide whether authenticated XML-RPC access should remain available.

See What Is XML-RPC in WordPress, and Why Disable It?.

14. Use Application Passwords for applications, not your main password

If an external application needs authenticated API access, do not automatically give it the user’s normal WordPress password.

WordPress supports:

Application Passwords

for supported API authentication.

The official WordPress Application Passwords documentation explains that these credentials are intended for applications and API clients rather than interactive wp-login.php logins.

Application Passwords are independently revocable

This gives an important operational benefit.

If Integration A should lose access:

revoke Integration A password

instead of:

change administrator password
+
reconfigure every other integration

Audit unused Application Passwords

Old integrations should not retain credentials indefinitely.

Review:

• who created each credential;
• which application uses it;
• whether that application still exists;
• whether the password can be revoked.

15. Protect password-reset workflows

A secure login form is not enough if password recovery is weak.

An attacker may target:

Forgot your password?

instead of directly guessing the existing password.

Protect the email account behind privileged WordPress users

If password resets go to:

admin@example.com

then compromise of that mailbox can become compromise of the WordPress account.

Use MFA on administrator email accounts too

Your effective authentication chain may be:

email account
↓
password reset
↓
WordPress administrator account

Securing WordPress while leaving the recovery mailbox weak defeats part of the login-hardening effort.

16. Keep WordPress Core updated

Login hardening cannot compensate for known vulnerabilities elsewhere in the application.

Keep WordPress Core on a supported, maintained version.

17. Keep authentication-related plugins updated

This is especially important for plugins controlling:

• 2FA;
• login URLs;
• rate limiting;
• SSO;
• CAPTCHA;
• firewalls;
• user management.

A security plugin itself becomes part of the authentication attack surface.

For the broader update risk, see The Risks of Not Updating WordPress Plugins.

Do not keep abandoned security plugins

A plugin handling authentication should receive particular scrutiny if it is:

• no longer maintained;
• incompatible with current WordPress versions;
• removed from its distribution source;
• showing unresolved security issues.

18. Remove unused plugins and themes

Deactivated software is not automatically irrelevant.

If code exists on the server and can still be reached or accidentally reactivated, it remains part of the maintenance burden.

Keep only software that is:

• needed;
• maintained;
• updated;
• understood.

19. Review registration settings

If public registration is enabled, ask whether it is intentional.

Under normal WordPress configuration, review:

Settings
→ General
→ Membership

Do not allow public registration by accident

If the website does not need visitors creating accounts, unnecessary registration increases:

• account volume;
• spam registrations;
• attack surface;
• administrative workload.

If registration is part of the business model, monitor it rather than disabling it blindly.

See Detecting Spam Registrations on WordPress.

20. Set the correct default registration role

If public registration is enabled, the default role should provide the minimum necessary permissions.

Do not accidentally configure new public users as:

Administrator
Editor
Author

when they only need basic account access.

21. Review login error messages

Login errors can reveal different information depending on authentication flow and customization.

Do not build custom errors that unnecessarily disclose:

this username definitely exists

versus:

this username does not exist

if that distinction has no user-experience benefit.

For how Core errors behave, see WordPress Login Error Messages, Explained.

Do not destroy usability merely to hide account existence

Login error design is a tradeoff.

Authentication security should still rely on:

• strong credentials;
• 2FA;
• throttling;
• monitoring.

not exclusively vague error messages.

22. Review active sessions after security incidents

Changing a password does not always answer every session-management question.

If an account is suspected of compromise, review whether active sessions should also be terminated.

WordPress authentication is cookie-based after login, as documented in the official WordPress login and authentication cookie documentation.

Incident-response sequence

For a suspected compromised Administrator account:

secure recovery email
↓
change WordPress password
↓
revoke suspicious sessions
↓
review Application Passwords
↓
review account changes
↓
review other administrators
↓
review logs
↓
scan site integrity

23. Do not use shared Administrator accounts

A team should not use:

username: admin
password: shared-password

for five different people.

Use individual accounts

Each administrator should have their own:

• username;
• password;
• 2FA configuration;
• audit trail.

Individual accounts improve accountability

If everyone shares one identity, it becomes difficult to determine:

• who logged in;
• who changed a setting;
• which person’s access should be revoked;
• which credential was compromised.

24. Remove access promptly when staff or contractors leave

Access revocation should be part of offboarding.

The process should include:

• WordPress user accounts;
• hosting access;
• CDN access;
• DNS access;
• Git repositories;
• password managers;
• analytics;
• email;
• third-party services.

Do not merely change the person’s role if access is no longer required

An unused account with fewer permissions is still an unused authentication surface.

25. Use a WAF or CDN where appropriate

High-volume login abuse is often more efficiently handled before traffic reaches PHP.

A WAF or edge platform can help:

• rate-limit login paths;
• challenge suspicious clients;
• block obvious bot patterns;
• reduce origin-server load.

The official WordPress brute-force guidance specifically recommends considering edge and WAF protections so malicious traffic can be rejected before it reaches WordPress.

Do not block legitimate administrators accidentally

Test:

• office networks;
• mobile connections;
• VPN users;
• remote staff;
• IPv6;
• traveling administrators.

26. Consider CAPTCHA or challenge mechanisms carefully

CAPTCHA or challenge systems can reduce automated login attempts.

But they add:

• user friction;
• accessibility considerations;
• third-party dependencies;
• privacy considerations depending on provider.

Use challenges based on actual risk where possible

A system that challenges suspicious behavior can create a better experience than one that challenges every legitimate administrator on every login.

27. Do not expose wp-admin over plain HTTP

This is closely related to HTTPS, but worth checking explicitly.

Test:

http://example.com/wp-admin/

The request should not leave the administrator using an insecure session.

28. Review reverse proxy and HTTPS configuration

Sites behind:

• Cloudflare;
• load balancers;
• reverse proxies;
• managed hosting layers;

need correct HTTPS detection.

Incorrect proxy configuration can cause:

• redirect loops;
• incorrect secure-cookie behavior;
• mixed protocol detection.

29. Protect staging sites too

A staging copy can contain:

• production usernames;
• password hashes;
• customer data;
• API credentials;
• administrator accounts.

A forgotten staging site with weak access controls can become a second copy of your authentication surface.

See WordPress Staging Site Best Practices.

Do not expose staging publicly without controls

Use appropriate:

• authentication;
• network restrictions;
• search-engine blocking;
• separate credentials where practical.

30. Secure backups containing user credentials

A WordPress database backup includes sensitive authentication-related information such as password hashes and account data.

A publicly downloadable backup can bypass many frontend login defenses.

Login security includes protecting copies of the database

An attacker who steals:

production database backup

can perform offline analysis without interacting with your protected login page.

31. Do not expose debug information on production

Authentication errors should not expose:

• filesystem paths;
• database errors;
• stack traces;
• plugin internals;
• sensitive configuration.

Debugging output belongs in controlled logs, not public authentication pages.

32. Review REST API exposure separately

The REST API is not the same thing as the WordPress login form.

Do not disable the entire REST API merely because you are hardening authentication.

Modern WordPress and plugins rely heavily on REST functionality.

Instead, understand:

• which routes are public;
• which require authentication;
• which expose account-related information;
• which integrations authenticate through the API.

See WordPress REST API Security Basics.

33. Review Application Passwords separately from browser login

Application Passwords cannot be used for normal interactive login through wp-login.php, according to the official WordPress Application Passwords documentation.

This means:

interactive login security
and
API credential security

need related but distinct controls.

34. Review SSO if your organization already has an identity provider

Larger organizations may prefer authentication through an established identity provider.

Benefits can include:

• central MFA enforcement;
• central account disabling;
• central password policy;
• central access auditing.

Do not add SSO merely to make the architecture more complicated

For a three-user website, a well-maintained WordPress login with strong passwords and 2FA may be entirely appropriate.

Choose complexity according to operational needs.

35. Test account lockout recovery

If login throttling or security plugins can block administrators, document how legitimate access can be recovered.

Possible recovery paths may involve:

• another Administrator;
• hosting control panel;
• WP-CLI;
• filesystem access;
• database access;
• security-plugin allowlists.

Never deploy authentication controls without a recovery path

A security system that permanently locks the legitimate owner out is not operating successfully.

36. Keep one authenticated session open during major login changes

When changing:

• login URLs;
• 2FA;
• SSO;
• authentication hooks;
• role restrictions;

keep an existing Administrator session open while testing the new workflow in another browser.

This reduces recovery risk

If the new authentication configuration fails:

existing session
→ still available
→ configuration can be corrected

37. Test every supported authentication path

Your login audit should include more than:

/wp-login.php

Depending on the site, also test:

• /wp-admin/ redirects;
• custom login pages;
• WooCommerce My Account;
• membership login forms;
• XML-RPC if enabled;
• REST API authentication;
• Application Passwords;
• SSO;
• password-reset flow.

38. Test each relevant user role

Authentication may work correctly for Administrator while failing for:

• Editor;
• Author;
• Subscriber;
• Customer;
• custom roles.

Role-aware 2FA or redirects require representative testing.

39. Test Remember Me behavior

WordPress’s normal login system supports a longer session when:

Remember Me

is selected.

The official WordPress login documentation currently describes the normal authentication-cookie lifetime as approximately:

2 days

and the Remember Me lifetime as approximately:

14 days

under standard Core behavior.

Long-lived sessions increase convenience and exposure

A session that remains valid longer provides a longer opportunity if the device or cookie is compromised.

Decide whether the normal behavior is appropriate for the site’s risk level.

40. Review authentication after major staff changes

Login security is not a one-time setup.

Re-audit after:

• employees leave;
• agencies change;
• developers change;
• ownership changes;
• new administrators are added;
• new authentication plugins are installed.

41. Re-audit after security incidents

If any account is compromised, assume the attacker may have done more than log in.

Review:

• new users;
• role changes;
• plugin installations;
• theme modifications;
• Application Passwords;
• scheduled tasks;
• API keys;
• database changes;
• file modifications.

42. Understand what a custom login page does not protect

A redesigned login screen can improve:

• branding;
• usability;
• client experience.

It does not automatically improve the authentication protocol.

TheOneWP Custom Login Page and security controls such as 2FA solve different problems.

Appearance and authentication are different layers

custom login page
→ presentation

custom login URL
→ endpoint exposure

2FA
→ authentication strength

rate limiting
→ attack frequency

roles
→ authorization

43. Use multiple independent defenses

A strong login configuration does not depend on any single assumption remaining true forever.

For example:

username discovered
→ password still strong

password compromised
→ 2FA still blocks login

bot attacks login
→ rate limiting slows attempts

administrator compromised
→ least privilege limits damage where possible

suspicious activity occurs
→ monitoring detects it

Defense in depth is the goal

No individual control should be treated as magical.

Not:

changed login URL
→ secure forever

Not:

installed security plugin
→ secure forever

Not:

long password
→ every attack solved

44. Do not over-harden until the site becomes unusable

Security controls have operational costs.

Bad implementations can:

• lock out staff;
• break integrations;
• block legitimate API clients;
• break WooCommerce accounts;
• make password recovery impossible;
• generate unusable alert volumes.

Security should reduce risk without destroying the workflow

The right question is not:

How many security controls can we add?

It is:

Which threats matter,
and which controls reduce them reliably?

TheOneWP login hardening stack

TheOneWP includes several modules that can participate in a layered login-security configuration.

Two-Factor Authentication

Two-Factor Authentication adds a second authentication factor and supports role-based enforcement.

Custom Login URL

Custom Login URL can reduce automated traffic targeting the predictable default login endpoint.

Restrict Login Identifier

Restrict Login Identifier controls the identifier types accepted by supported login flows.

Hide Author Slug

Hide Author Slug can reduce unnecessary exposure of public author identifiers.

Disable Author Archive

Disable Author Archive can remove author archive functionality where it provides no visitor-facing value.

Last Login

Last Login can make account activity easier to review from the user-management workflow.

Block User Login

Block User Login can prevent selected accounts from authenticating without necessarily deleting the user record.

Use modules according to the site’s actual threat model

You do not need every possible control on every WordPress installation.

A small brochure site with two administrators may need:

strong unique passwords
+
2FA
+
rate limiting
+
updates
+
monitoring

A large membership or e-commerce platform may require substantially more.

WordPress login hardening checklist

• Audit every WordPress user account.
• Delete or disable accounts that are no longer required.
• Audit all Administrator accounts.
• Apply least privilege.
• Use individual accounts instead of shared Administrator credentials.
• Use strong, unique passwords.
• Use a password manager.
• Remove reused passwords.
• Avoid predictable usernames where practical.
• Enable 2FA for Administrators.
• Enable 2FA for other privileged users.
• Store recovery methods securely.
• Test 2FA recovery.
• Limit repeated login attempts.
• Consider server, WAF or CDN rate limiting.
• Monitor failed logins.
• Monitor successful privileged logins.
• Use HTTPS everywhere.
• Verify wp-admin never remains on plain HTTP.
• Review authentication-cookie behavior.
• Secure administrator devices.
• Review whether the default login endpoint should remain public.
• Do not treat a custom login URL as primary authentication security.
• Review username and email exposure.
• Review author archives.
• Review public author slugs.
• Review login identifier policy.
• Audit XML-RPC requirements.
• Protect or restrict unnecessary XML-RPC authentication.
• Review REST API exposure separately.
• Use Application Passwords for supported API integrations.
• Do not give applications the user’s main password unnecessarily.
• Revoke unused Application Passwords.
• Protect password-reset email accounts with strong authentication.
• Keep WordPress Core updated.
• Keep authentication and security plugins updated.
• Remove abandoned plugins.
• Remove unused plugins and themes.
• Review public registration.
• Review the default registration role.
• Monitor spam registrations.
• Review login error messages.
• Terminate suspicious sessions after incidents.
• Remove access during staff offboarding.
• Secure hosting, CDN and DNS accounts too.
• Protect staging environments.
• Protect database backups.
• Disable public production debug output.
• Test custom login URLs before logging out.
• Keep an active admin session during authentication changes.
• Test wp-login.php.
• Test wp-admin redirects.
• Test custom login forms.
• Test WooCommerce or membership login forms.
• Test password reset.
• Test every important user role.
• Test Application Password integrations.
• Test XML-RPC if retained.
• Review Remember Me behavior.
• Document administrator recovery procedures.
• Re-audit authentication after staffing changes.
• Re-audit authentication after security incidents.
• Review login hardening after major WordPress or plugin updates.

Priority checklist for a small WordPress site

If you cannot implement everything immediately, start here:

1. Give every Administrator a unique strong password.
2. Enable 2FA for every Administrator.
3. Remove unused privileged accounts.
4. Limit repeated login attempts.
5. Use HTTPS everywhere.
6. Keep Core, plugins and themes updated.
7. Monitor suspicious login activity.
8. Review XML-RPC and other authentication surfaces.
9. Protect the administrator email accounts used for password recovery.
10. Create and test an account-recovery procedure.

Priority checklist for a business-critical WordPress site

For e-commerce, membership, publishing or business-critical installations, add:

• role-based 2FA enforcement;
• WAF or edge rate limiting;
• centralized login monitoring;
• individual Administrator accounts;
• formal staff offboarding;
• Application Password audits;
• staging authentication controls;
• incident-response procedures;
• session-revocation procedures;
• regular role and capability audits.

Related guides

• WordPress Brute-Force Attacks, Explained
• How to Limit Login Attempts in WordPress
• How to Monitor WordPress Login Attempts
• How Attackers Collect WordPress Usernames and Email Addresses
• WordPress Login: Username vs. Email, Which Is More Secure?
• How to Audit User Roles on a WordPress Site

Final recommendation

A hardened WordPress login should not depend on the attacker failing to discover one secret URL or one username.

Assume that:

the login endpoint can eventually be found

usernames may eventually be discovered

automated login attempts will happen

passwords can sometimes be leaked

Then build defenses that remain useful even when those assumptions become true.

The strongest practical foundation is:

unique passwords
+
2FA
+
rate limiting
+
least privilege
+
HTTPS
+
monitoring
+
updates
+
secure recovery

Additional controls such as custom login URLs, identifier restrictions, author-archive reduction and XML-RPC restrictions can further reduce exposure when they fit the site’s architecture.

But classify each control correctly.

strong password
→ protects the credential

2FA
→ reduces the value of a stolen password

rate limiting
→ reduces automated guessing

custom login URL
→ reduces predictable scanning

least privilege
→ limits account power

monitoring
→ improves detection

updates
→ reduce known software vulnerabilities

HTTPS
→ protects credentials and sessions in transit

No single item replaces the others.

The objective is not to make WordPress impossible to attack. No internet-facing authentication system can make that promise.

The objective is to make account compromise significantly harder, automated attacks less efficient, suspicious activity more visible and recovery more controlled if something still goes wrong.