WordPress Security Baseline: User Roles, Two-Factor Authentication, and Login Protection
1. Start by taking stock of accounts: most sites have too many administrators
The first step in any WordPress intrusion is always the login page. And the login page can only be breached if the attacker already has a working set of credentials. So security doesn’t start with installing a plugin. It starts with counting exactly how many people can get into your admin panel.
Many sites have been running for two years and piled up seven or eight administrator accounts: contractors, former colleagues, test accounts, some still using 123456 as a password. If any one of them leaks, the admin door is wide open.
Example: a site got injected with spam links. The logs showed the login came from a contractor account that was abandoned six months earlier. The person left, the account stayed, and the password was still the one sent in a chat message years ago. The attacker didn’t need a single exploit.
For how to plan accounts when choosing your tech stack, see WordPress Standalone Site Tech Stack. For the cleanup process after a breach, see After your site gets hacked.
| Role | Role | Who should get it |
|---|---|---|
| Administrator | Full site: install plugins, edit code, delete users | The person actually running things, ≤2 |
| Editor | Manage all content and comments | Content owner |
| Author | Write and manage only their own posts | Guest writers |
| Contributor | Write drafts but can’t publish | External contributors |
| Subscriber | Comment only | Regular visitors |
2. Least privilege: don’t let writers install plugins
The principle of permissions: what an account can do should be exactly the minimum it needs to do its job. A content operator writing blog posts doesn’t need to install plugins or change themes. Editor or Author is enough. Only the people actually maintaining the site deserve Administrator.
Offboarding takes two steps: first downgrade and disable the account, watch for one to two weeks to confirm nothing automated depends on it, then delete it. Deleting it right away can lose the author attribution on posts it published.
Also delete the default admin username. Many brute-force tools try the username admin on the first pass. If your admin panel happens to have it, you’ve handed over half your password.
Your passwords need to be long enough too. Eight digits of pure numbers is basically no protection against modern brute-force attacks. For admin passwords, aim for twelve characters or more, mix upper and lower case with symbols, and never reuse the same string across accounts. Password reuse is the main reason credential stuffing succeeds.
| Role | Recommended role | Should not be granted |
|---|---|---|
| Site owner / tech lead | Administrator | — |
| Content editor | Editor | Installing plugins, editing code |
| Contributor | Author | Editing others’ posts, editing themes |
| External contributors | Contributor | Publishing directly |
| Intern / temp | Contributor | Any publishing permission |
3. Two-factor authentication: add a second lock beyond your password
The point of two-factor authentication (2FA) is this: even if your password leaks, an attacker can’t get in without the dynamic code on your phone. This is the most effective layer against credential stuffing, because credential stuffing relies precisely on “passwords leaked somewhere else.”
Choose a TOTP authenticator (apps like Google Authenticator or Authy), not SMS. SMS codes can be intercepted through SIM hijacking, while TOTP is generated locally and doesn’t depend on your carrier.
Enforce it in two steps: require Administrator accounts to turn it on immediately, or they can’t log in; give other roles a two-week grace period, then lock them out automatically. See Security Hardening for setup instructions.Security Hardening for Your Own Site.
Scenario example 3: A team of five, and at first only the tech lead had two-factor enabled. One email leak exposed the operations person’s password, and the attacker got into the dashboard because that account had no 2FA, so the second lock was useless. Two weeks later, everyone was required to enable it, and that risk was truly closed off.
| 2FA method | Security | Recommendation |
|---|---|---|
| TOTP authenticator app | High, generated locally without a network connection | Recommended for everyone |
| SMS code | Medium, can be hijacked via SIM | Not recommended as your main method |
| Email code | Low, email is often leaked along with passwords | Backup only |
| Hardware key | Highest | Optional for admins |
4. Login protection: rate limiting and lockouts beat changing the path
Let’s correct a popular misconception here. Many tutorials tell you to change /wp-admin to some strange path, thinking attackers won’t find the dashboard that way. In reality, a targeted attacker will use tools to scan for where the login page is. Changing the path only adds a little hassle; it won’t stop brute force.
What actually works is two things: lock out an IP for a while after 5 failed logins (say 15 minutes), so automated brute force can’t keep running; and turn off the XML-RPC system publishing method, which is the entry point for many bulk brute-force scripts.
Scenario example 2: The logs showed one IP trying 800 passwords in an hour, all with common usernames. After enabling the 5-failure lockout, that IP was blocked on its sixth attempt, and every later attempt was rejected instantly.
One more detail: make the login endpoint respond with a slight delay on every failure, and the cost of scripts trying passwords in bulk goes up. Once your site grows, put a cloud WAF in front of the login layer, and distributed credential stuffing gets stopped before it ever reaches WordPress.
| Protection action | Role | Limitation |
|---|---|---|
| Lock out IP after 5 failures | Stops automated brute force | Distributed attacks need a cloud WAF |
| Disable XML-RPC | Shut the door on scripted attacks | Keep it if you publish via the app |
| Hide the WP version number | Don’t expose old-version flaws | Only reduces information exposure |
| Change the admin path | Adds a little scanning cost | Won’t stop a targeted attack |
| Disable file editing in the dashboard | Stops theme edits after a login | Code changes must go through SFTP |
5. The supporting cast: backups, monitoring, and a minimal attack surface
No matter how good your security is, assume you’ll be breached someday, so backups are your last line of defense. Back up the database and files separately, store them off-site, and run a restore drill every quarter. A backup you can’t restore is no backup at all. For how, see Backup strategy for standalone sites.
Keep shrinking your attack surface: delete plugins and themes you don’t use, since every idle plugin is a potential vulnerability. Set up alerts for suspicious logins, such as admin logins from unusual regions or outside working hours. For monitoring thresholds, see Monitoring system for standalone sites.
One more red line: if a password turns up in a breach somewhere else, rotate every account password across the site. Credential-stuffing attacks will try that password on your dashboard, and every protection above fails once the password is correct.
| Action | Frequency | Pass criteria |
|---|---|---|
| Audit admin accounts | Monthly | administrator ≤2个 |
| Review idle plugins and themes | Quarterly | Delete once disabled |
| Backup and Recovery Drill | Once a quarter | Restore within 2 hours |
| Suspicious login alerts | Real-time | Instant notice of logins from new locations |
| Password rotation | Immediately after a breach | Everyone changes passwords and enables 2FA |
FAQ
Is one security plugin enough for WordPress?
Can changing /wp-admin to another path keep hackers out?
Can I use SMS codes for two-factor authentication?
What should I do with a departing employee’s WordPress account?
How many Administrator accounts should you keep?
What does a brute-force attack look like in the logs?
Final thoughts
WordPress security is counterintuitive: you think it depends on complex plugins and advanced rules, but what actually decides your site’s fate is whether you’ve deleted extra administrators and added a second lock to every account. These two things cost nothing, yet they stop the vast majority of intrusions.
Three steps to put it into practice: audit your user list today and cut administrators down to 2 or fewer; force TOTP two-factor authentication on all administrators; enable lockout after 5 failed logins and turn off XML-RPC. After that, review accounts once a month and run a recovery drill once a quarter.
One line worth remembering: security isn’t about how fancy the lock on the door is, it’s about taking back the keys from the people who shouldn’t have them.