The Weakest Login Belongs to Someone Else
Most WordPress security advice is written as if a site has one admin, one password, one attack surface. Real sites rarely work that way. A typical small business WordPress install has an owner, a marketing contractor, a developer who touched it once eighteen months ago and still has an account, and maybe a plugin author's support technician who was granted temporary access during a support ticket and never got removed. Every one of those accounts can create posts, install plugins, and in most role configurations edit PHP files directly through the theme editor. Your site's actual security ceiling is not your own password discipline. It is the worst password habits of whichever of those accounts still has standing access, which is precisely why a single sitewide 2FA policy, not just a personal one, is the real fix.
Layer onto that the fact that WordPress powers a large share of the entire web, and you get the most consistently attacked login page on the internet: /wp-login.php. Check the access logs on almost any WordPress site within hours of launch and you will already see automated password guessing traffic. It is nothing personal. Bots sweep the whole internet trying admin and password123 against every WordPress install they can find, replay breached credentials at scale in what is called credential stuffing, and probe for outdated plugins with known holes. A compromised account, any compromised account on the site, tends to end the same way: injected spam pages, SEO poisoning, malware served to visitors, and a domain that shows up on blacklists.
Why This Is a Supply Chain Problem, Not a Personal One
WordPress core still ships without any built in two-factor authentication, which means the fix always arrives as a plugin, and plugin choice is itself part of the risk. Adding 2FA through a poorly maintained, rarely updated plugin trades one weak point for another: an unmaintained authentication plugin is a more attractive target than the login it protects, since a flaw there can potentially bypass every account's 2FA at once rather than just one. Choose accordingly:
- Two-Factor, maintained by the WordPress core contributors team itself: free, minimal, and includes TOTP, email codes, backup codes, and FIDO2 security keys. The clean, conservative default for most sites.
- WP 2FA: a free tier with setup wizards and, importantly for multi-admin sites, policy enforcement that can require every administrator to enroll by a set deadline rather than leaving it optional.
- Wordfence: a fuller security suite with firewall and malware scanning that bundles 2FA in, useful if you want one plugin covering more ground.
- Whatever you choose, run exactly one actively maintained 2FA plugin. Two overlapping ones tend to conflict during login and one of them usually ends up disabled without anyone noticing.
Setting It Up (Using the Two-Factor Plugin as the Example)
- From Plugins > Add New, search "Two-Factor," install, and activate.
- Each user, including every admin and editor, visits their own Users > Profile page to enroll individually. Enrollment is per account, not sitewide, which is exactly why enforcement matters more than a single setup guide.
- In the Two-Factor Options section, enable Authenticator app (TOTP).
- Scan the QR code with Google Authenticator, Authy, or any TOTP app.
- Enter the six digit code to confirm.
- Generate backup codes and store them somewhere outside the site itself, in a password manager or on paper, following our backup codes storage guide.
The QR code is a standard otpauth URI under the hood. Developers curious what is inside one can inspect it with our QR decoder, generate test secrets with our secret generator, and confirm any secret produces valid live codes with our TOTP generator.
Making Enforcement Actually Stick Across Every Admin
A single administrator without 2FA quietly undoes the protection everyone else on the site has. This is where WP 2FA's policy enforcement earns its place: set a rule requiring every Administrator and Editor role to enroll within a set number of days, applied automatically at their next login, rather than trusting an email reminder to get read. Even running a solo site, audit Users > All Users on a schedule: forgotten admin accounts from a past developer or a former employee are the classic overlooked backdoor, and they should be deleted or demoted the moment they are found, not left dormant "just in case."
The order automated tools try passwords is not random: "admin," the site's own domain name, "123456," then a scrolling list of millions of passwords leaked from other breaches. An account still named admin with a password a human once thought up is living on borrowed time. Two-factor authentication ends that entire category of attack in one step, regardless of how weak the underlying password turns out to be.
What Breaks When the Plugin Breaks
Every WordPress plugin update carries a small chance of breaking something, and a 2FA plugin breaking the login flow is uniquely bad because it can lock every enrolled user out simultaneously, not just one account. Have a documented recovery path in place before you ever need it, not while you are locked out and panicking: via FTP or your hosting file manager, navigate to wp-content/plugins and rename the 2FA plugin's folder. WordPress disables any plugin whose folder it cannot find, which restores plain password login instantly. Once back in, review what broke, update or replace the plugin, and re-enroll everyone. This single fact, that a folder rename in the file system can override a broken login flow, is worth writing down somewhere your whole team can find it, because it is the difference between a five minute fix and a frantic support ticket.
The Rest of the Fifteen Minute Hardening Checklist
- Retire the admin username: create a new administrator account with a random username, log in as it, and delete the old literal "admin" account, reassigning its content to the new user first.
- Unique, generated passwords per user: WordPress will suggest one at account creation, or use our password generator, and check existing passwords with the strength tester.
- Limit login attempts: most 2FA plugins include throttling, or add a dedicated one, turning a brute force campaign of thousands of guesses into a handful before it locks out.
- Disable XML-RPC if nothing on the site depends on it, since it is a documented path for bypassing rate limiting on password guessing attempts.
- Audit application passwords: WordPress's REST API application passwords bypass 2FA by design, so review them under each user's profile and revoke anything unused or unrecognized.
- Keep everything updated: most WordPress compromises exploit an outdated plugin rather than a weak login, so enable automatic minor updates and review the plugin list monthly regardless of 2FA status.
- HTTPS everywhere, so credentials and session cookies never travel in plaintext, explained further in our HTTPS guide.
Frequently Asked Questions
Our site has five admins across two agencies. How do we actually enforce 2FA rather than just recommend it?
Use a plugin with policy enforcement, such as WP 2FA, set to require enrollment within a fixed number of days for every Administrator and Editor role, and verify compliance directly in the plugin's dashboard rather than trusting confirmation emails. Treat any account that misses the deadline as suspended until it enrolls.
The 2FA plugin update broke our login for every user at once. What is the fastest fix?
Via FTP or your host's file manager, rename the plugin's folder inside wp-content/plugins. WordPress automatically disables any plugin it cannot locate, restoring standard password login immediately. Fix or replace the plugin, then have everyone re-enroll.
Does 2FA on wp-admin affect site visitors or page speed at all?
No. It only touches the login flow for accounts with dashboard access. Visitors, caching, and page performance are completely unaffected.
Should WooCommerce customer accounts get 2FA too, or just staff?
Prioritize admin and staff accounts first, since that is where the real risk concentrates. Extending 2FA to every customer account adds friction at checkout for comparatively little security gain; focus instead on strong password requirements and rate limiting on customer facing endpoints.
We manage dozens of client WordPress sites. What should our standard be?
Standardize on one plugin and one enforcement policy across every client site, keep unique passwords per site in a password manager, store backup codes per client separately, and require 2FA on your own accounts everywhere without exception. The layer above wp-admin matters just as much: see our cPanel and hosting 2FA guide for securing the hosting account each site actually runs on.
