WordPress Login Security in 2026: 2FA, Passkeys and Practical Protection

A WordPress website can be well maintained, regularly updated and protected by a firewall, but one compromised administrator account can still cause serious damage.

That is why login security deserves more attention than it usually gets.

In my previous MEND FWD case study, I looked at WordPress security as part of the wider website architecture. This time, I want to focus specifically on one of the most important parts of that security model: administrative access.

For many small-business websites, the login page is simply treated as something that comes with WordPress. You enter a username, enter a password and get access to the dashboard.

Technically, that works.

From a security point of view, however, relying on a password alone is no longer a strong enough approach for an account that can install plugins, change themes, create users or modify the whole website.

The good news is that improving WordPress login security does not require turning a small website into a complicated security project.

A few well-chosen controls can make a significant difference.

Passwords are still important — but they are only the first layer

A strong password still matters.

Administrator passwords should be long, unique and never reused on another service.

The problem is that even a good password can be exposed.

A password might appear in a data breach from another service. It might be entered into a convincing phishing page. It might already be stored somewhere insecurely without the website owner realising it.

This is why attacks such as credential stuffing are so effective.

An attacker does not necessarily need to break WordPress itself. They can simply take email addresses and passwords leaked elsewhere and automatically test them against other websites.

That makes password reuse particularly dangerous.

For administrative accounts, I prefer generated passwords stored in a password manager rather than passwords based on a company name, year, family name or predictable pattern.

But even then, the password should be treated as the first barrier rather than the entire security system.

Add a second factor to administrator accounts

Two-factor authentication is one of the most useful improvements that can be made to a WordPress login.

The idea is simple.

First, you enter your normal password.

Then you confirm the login using something else.

A common example is a six-digit code generated by an authenticator application. The code changes regularly and is only available on the registered device.

That means someone who has stolen the password still cannot simply log in.

For a small-business website, I would prioritise 2FA for accounts with real administrative power.

That normally includes administrators, developers and anyone who can install software, change important settings or access sensitive information.

There is usually little benefit in making every low-privilege user go through additional security steps if they do not have access to anything important.

The focus should be on protecting the accounts that can actually cause damage if compromised.

Not every type of 2FA offers the same protection

The term 2FA covers several different technologies.

SMS codes are probably the best-known example. They are still better than using only a password, but stronger options are available.

Authenticator applications using TOTP are a common choice for WordPress.

They work well, are widely supported and do not depend on receiving a text message.

There are also hardware security keys and newer WebAuthn-based methods.

For an administrator account, I would generally prefer an authenticator app or a phishing-resistant method over SMS when possible.

This is not because SMS protection is useless.

It is simply because security should be proportional to the importance of the account.

An administrator account deserves stronger protection than an ordinary website user.

Passkeys are becoming a very interesting option

Passkeys take a different approach to authentication.

Instead of relying on a reusable secret that you type into a login form, authentication is based on cryptographic keys.

The private part of the credential remains on the user’s device or authenticator.

The website receives proof that the correct credential exists, without receiving the private key itself.

In practice, this means a person may be able to log in using something they already use every day:

a fingerprint,

Face ID,

Windows Hello,

a device PIN,

or a physical security key.

The important security advantage is that passkeys are designed to resist phishing.

A normal password can be entered into a fake website by mistake.

A properly implemented passkey is tied to the legitimate service and domain.

That makes it much harder for a fake login page to simply collect reusable credentials.

For WordPress administrators, this is an area worth watching closely.

WordPress itself does not currently provide a complete passkey system out of the box, so it normally requires a maintained WebAuthn-compatible plugin or another authentication solution.

Strong authentication also needs a recovery plan

There is another side to stronger login security that is easy to forget.

What happens when the administrator loses the phone?

What happens if the authenticator application is removed?

What happens if a hardware key disappears?

A security system that prevents the legitimate owner from accessing the website is not a good operational system.

That is why recovery needs to be planned at the same time as authentication.

Backup codes should be generated and stored somewhere secure.

Where practical, more than one authenticator should be registered.

For example, an administrator could have a phone plus a second trusted device or hardware key.

The recovery process should also be understood before it is actually needed.

Trying to figure it out for the first time during an emergency is exactly what should be avoided.

Stop automated login attempts before they reach WordPress

Strong authentication protects the account itself, but there is another problem.

Bots can still repeatedly send requests to the WordPress login page.

Even if they never manage to log in, thousands of automated requests can create unnecessary traffic and server work.

This is where rate limiting becomes useful.

Instead of allowing unlimited login attempts, a security layer can detect unusual behaviour and slow down, challenge or block repeated requests.

Where possible, it makes sense to do this before the request reaches WordPress.

The request path may look roughly like this:

Internet → Cloudflare → web server → PHP → WordPress

If suspicious traffic can be stopped at Cloudflare or another edge security layer, WordPress does not have to process every malicious request itself.

That reduces unnecessary load and keeps some of the attack traffic away from the application completely.

For sites already using Cloudflare, login rate limiting is therefore worth considering as part of the security setup.

CAPTCHA can help, but it is not the whole solution

CAPTCHA-style protection can also reduce automated login attempts.

Cloudflare Turnstile is one example.

It can help distinguish normal users from automated traffic without forcing every visitor through an old-style image puzzle.

But CAPTCHA should not be treated as a replacement for proper authentication.

It does not replace strong passwords, 2FA, passkeys, rate limiting or monitoring.

It is simply another layer.

That distinction matters.

WordPress security becomes much easier to understand when every control has a clear purpose rather than expecting one feature to solve every problem.

Changing the login URL is not a security strategy on its own

A popular WordPress recommendation is to change the standard login address.

Instead of using the familiar WordPress login endpoint, a plugin can move the login form to a custom URL.

This can reduce basic automated noise.

Many bots simply look for the default WordPress login paths and move on if they do not find them.

But this should not be confused with real authentication security.

If the new login address is discovered, the protection is gone.

So I see this more as a way to reduce unnecessary traffic than as a substitute for 2FA, passkeys or rate limiting.

Hiding the door is not the same as locking it properly.

Review whether XML-RPC is actually needed

Another WordPress endpoint worth checking is xmlrpc.php.

XML-RPC has legitimate uses and may still be required by some applications or integrations.

That means it should not simply be disabled because a security checklist says so.

The better question is:

Does this particular website actually need it?

If the answer is no, there may be little value in leaving unnecessary functionality exposed.

If the answer is yes, then it should be monitored and protected appropriately.

This reflects a broader security principle that I use throughout WordPress work:

do not disable or install things blindly.

First understand what the feature does, whether the site needs it and what would break if it changed.

Login monitoring matters too

Security is not only about blocking attacks.

It is also about noticing unusual behaviour.

Repeated failed logins can indicate automated attacks.

Attempts to log into usernames that do not exist can reveal bot activity.

Unexpected administrator logins or newly created privileged accounts deserve attention.

Monitoring these events can help identify a problem earlier, before it becomes a larger incident.

This is one reason application-level tools such as Wordfence can still be useful even when Cloudflare is already protecting the site.

The two layers see different parts of the traffic and perform different jobs.

Cloudflare can filter traffic before it reaches the server.

WordPress security monitoring can provide visibility into what is happening inside the application.

They should complement each other rather than duplicate everything.

Updates still matter

Strong login protection does not make normal WordPress maintenance unnecessary.

WordPress core, plugins and themes still need to be kept current.

An attacker does not have to use the login page if an outdated plugin provides another route into the website.

This is why I prefer to think of security as several connected layers rather than one configuration screen.

Authentication protects access.

Updates reduce known software vulnerabilities.

Monitoring helps detect unusual behaviour.

Backups make recovery possible.

The system becomes stronger when all of these are maintained together.

Avoid building a collection of security plugins

One mistake I often see in WordPress security discussions is the assumption that more plugins automatically mean more protection.

That is not necessarily true.

Several security plugins may apply overlapping firewall rules, login restrictions or CAPTCHA systems.

They can make troubleshooting harder and introduce more code that itself needs updates and maintenance.

A simpler setup is often easier to understand and safer to operate.

For example, one site might use:

Cloudflare for network-level filtering and rate limiting,

Wordfence for WordPress-level monitoring,

a dedicated 2FA or WebAuthn solution for privileged accounts,

and a separate backup system for recovery.

Each tool has a clear responsibility.

That is much easier to maintain than installing tools simply because they have the word “security” in their description.

A practical baseline for a small WordPress website

For many small-business websites, a reasonable security baseline can remain quite simple.

Use a unique generated password for every administrator.

Store credentials in a password manager.

Enable 2FA or a passkey for privileged accounts.

Rate-limit suspicious login traffic where possible.

Monitor failed and unusual authentication activity.

Keep WordPress, plugins and themes updated.

Maintain reliable backups.

And make sure there is a documented way to recover administrator access.

None of these controls is particularly exotic.

The value comes from using them together.

Security should remain understandable

One of the main lessons from building and maintaining MEND FWD is that security does not have to make a WordPress website unnecessarily complicated.

The opposite is often true.

A system becomes easier to protect when its components have clear responsibilities and the person maintaining it understands why each control exists.

A strong password is useful.

Two-factor authentication makes it stronger.

Passkeys can improve phishing resistance.

Rate limiting reduces automated abuse.

Monitoring provides visibility.

Backups provide a way back when something still goes wrong.

No single plugin provides all of that.

Good WordPress security is a process.

For a small business, the goal is not to build the most complicated security system possible.

The goal is to make administrative access difficult to abuse, suspicious behaviour easier to notice and recovery predictable if something does go wrong.