Securing the WordPress Login: 2FA, Limits and Passkeys

Every WordPress site has the same front door at /wp-login.php, and automated scripts try it on every site they can find, whatever its size. Good WordPress login security does not depend on hiding that door. It depends on making a correct password insufficient by itself, slowing down guessing, and knowing which other doors exist.

Four things do the real work: a second factor, attempt limits, control over application passwords and a recovery plan. One popular measure does much less than people expect, and it gets its own section near the end.

What the login screen gives you by default

WordPress stores passwords as hashes, shows a strength meter when one is set and lets a user end their other sessions with the "Log Out Everywhere Else" button on the profile screen. That is roughly where the built-in protection stops.

Core does not limit failed login attempts, and it does not include two-factor authentication. Both have to be added. Usernames are no help either. The WordPress project does not treat them as private, and author archives and the REST API can reveal them. Plan on the assumption that an attacker already knows every administrator's username and needs only the password.

Two-factor options compared

Method	How it works	Weak point	Good fit for
Email code	A one-time code is sent to the account's email address	Only as strong as the mailbox, and it fails when site email is not delivered	Low-privilege users and a fallback method
Authenticator app (TOTP)	An app on the phone shows a six-digit code that changes every 30 seconds	A convincing fake login page can still collect the code, and phones get lost	The default for administrators and editors
Passkey or hardware security key	The device proves who you are with a key pair tied to your site's domain	Needs an extra plugin, and a recovery route when the device is gone	Administrators of stores and other high-value sites
Backup codes	A printed set of single-use codes	Useless if stored in the same place as the password	Recovery only, next to one of the methods above

The community-maintained Two Factor plugin on WordPress.org covers email codes, authenticator apps and backup codes, and most security suites include their own version. Companies that already use an identity provider can go another way and put WordPress behind single sign-on, so the second factor is enforced in one place for every tool. Whichever you choose, run only one two-factor plugin. Two of them on the same login form will fight.

Roll out 2FA without locking anyone out

1. Start with your own account. Set it up, log out, log back in, and store the backup codes in your password manager.
2. Keep a second administrator. A spare admin account with its own second factor, held in the company password vault, is the way back in when the first one is locked out.
3. Check that site email arrives before relying on email codes or password resets. Send yourself a reset link and see how long it takes.
4. Enforce by role. Administrators, editors and shop managers should not be able to skip it. Give people a few days of grace to enroll, then make it mandatory.
5. Leave customers and subscribers optional unless your business has a reason to require it. Forcing a second factor on every shopper costs sales and support time.
6. Write down the recovery route. Someone with server access can switch the plugin off with wp plugin deactivate and the plugin's folder name. That is your emergency exit, and it is also the reason hosting and SSH access need the same care as the WordPress login.

Passkeys on WordPress today

Passkeys replace or supplement the password with a key pair held on a phone, laptop or hardware key and confirmed with a fingerprint, a face or a PIN. Because the key is bound to your domain, a fake login page on another domain gets nothing usable. That resistance to phishing is their main advantage over codes.

WordPress core does not support passkeys natively. The feature request on the core tracker is still open with no release assigned, so on a WordPress site passkeys come from a plugin. The Two Factor plugin itself has dropped its old security-key method and points to a separate WebAuthn provider plugin for passkeys and hardware keys.

Before adopting one, check three things. First, whether the password login stays available as a fallback, because if it does, the password still has to be strong and unique. Second, what happens when a device is lost: there must be backup codes or a second registered device. Third, how the plugin behaves on a staging copy with a different domain, where passkeys registered on the live site will not work. A sensible start is passkeys for administrators, with an authenticator app kept as the second option.

Limit attempts where it costs the least

Attempt limits can sit in three places. A CDN or web application firewall can challenge or block repeated requests to the login page before they reach your server. The web server can rate limit the same address. A plugin can count failures inside WordPress and lock out the offender. The official brute-force guidance prefers the first two, because a plugin still starts PHP for every attempt it rejects.

On a small site with no server access, a plugin limit is fine. Two settings deserve attention. If the site sits behind a CDN or proxy, make sure the plugin reads the visitor's real IP address, or one bad visitor will lock out everybody who shares the proxy's address. And avoid lockouts keyed only on the username, since anyone who knows your username could then keep you out of your own site. Server-level examples are in our article on stopping brute-force and XML-RPC attacks.

Application passwords are logins too

Under Users > Profile > Application Passwords, any user can create a separate password for a script or an app. These work with the REST API and XML-RPC, cannot be used on wp-login.php, and are available when the site runs over HTTPS. They also skip the second factor, because nobody is present to type a code.

Treat each one as a key. Create one per integration, on an account with the lowest role that does the job, and give it a name that says what it is for. Review the "Last Used" column now and then and revoke anything idle. The application passwords documentation covers the details. If nothing on the site uses them, switch the feature off with one line in a small must-use plugin:

add_filter( 'wp_is_application_passwords_available', '__return_false' );

Moving the login address is tidiness, not protection

Plugins that change /wp-login.php to a private address do cut down the noise in your logs, and that has some value. They do not secure the account. XML-RPC and the REST API still accept credentials at their usual addresses. The new address leaks through emails, redirects and browser history. Password reset links and some plugins break in ways that only show up weeks later, and staff forget the address.

The same goes for a CAPTCHA on the login form. It turns away simple bots, adds friction for people and does nothing against a stolen password. Use either as an extra once two-factor and attempt limits are in place, never as a replacement.

How much WordPress login security you can set up yourself

On a site with a handful of staff accounts, everything here is an afternoon's work: install one two-factor plugin, enroll, enforce by role, add an attempt limit and review application passwords. It gets harder when logins are part of the product. Membership and learning sites with thousands of users, a store with a custom account area, a mobile app that signs in through the API or single sign-on with role mapping all need the login flow tested end to end, on staging, before anything is enforced.

That testing, along with a regular check that every privileged account still has a second factor, is routine work within a WordPress maintenance plan. If the site's login is tied into other systems, reviewing how those connections authenticate is part of our WordPress API and integration work.

Frequently asked questions

Does WordPress have two-factor authentication built in?

No. WordPress core does not ship a second login step, so it has to come from a plugin or from single sign-on through an identity provider. Check that whatever you install can enforce two-factor by role, since an optional setting is rarely switched on by everyone.

Which two-factor method is best for a small team?

An authenticator app with backup codes. It works without mobile signal or email delivery, costs nothing and takes a minute to set up. Add passkeys or hardware keys for the people whose accounts could do the most damage.

What happens if an administrator loses their phone?

They log in with a backup code and enroll the new phone. If the codes are lost too, most two-factor plugins let another administrator reset the second factor on that user's profile, and as a last resort someone with server access can deactivate the plugin with WP-CLI. Decide which of these applies to you before it happens.

Are passkeys safer than a password with a code?

Against phishing, yes, because a passkey will not respond to a fake copy of your login page. The gain disappears if a weak password remains as a fallback, so a site that adds passkeys should keep strong passwords and a second factor on that fallback route.