Every person holding an administrator account on your site is a way in. Not because you cannot trust them, but because their laptop, their password habits and their email account are now part of your security, and you have no visibility into any of the three.
So the question to ask when someone needs access is not whether you trust them. It is what the smallest thing is that lets them do the job. Most sites I look at have three or four administrators where one would do, and a couple of them belong to people who finished their work two years ago.
The keys you hand over yourself
Before the roles, there is a habit that undoes all of them.
Something breaks on a premium theme, you open a support ticket, and the developer asks for access so they can look. What happens next is almost always the same: the site URL, an admin login and a password get typed into a reply box. Sometimes into a public forum thread. Sometimes into a comment on a marketplace item page, where the whole world can read it. Sometimes into a chat window belonging to a company neither of you has thought about.
The credentials work. The problem starts afterwards. That text now lives in a ticket system you do not control, in the notification emails it sent, in the inbox of whoever was on support duty, and in whatever backups that company keeps. It is still there in two years, when the developer has moved on and the ticket is closed and you have long since forgotten which of your sites it was for.
A password typed into a support thread is not a password any more. It is a document.
This is fixable on the support tool side, which is why we built ours that way. On our Hub, credentials do not go in the reply box at all. There is a separate form for them, the login and password are encrypted before they are stored, the submission is recorded as its own security event rather than as an ordinary message, and the reply never renders in the public thread or in the customer view. Only the person working on the ticket sees it.
That is what to look for wherever you are sending access. If the only place to put a password is the same box you type sentences into, it is going to end up in a mailbox.
Whatever the channel, three rules travel with the credentials:
- Make a new account for them rather than sharing yours. You cannot revoke your own login, and you cannot tell their actions from yours in any log.
- Send the password through something that expires, not through the ticket, a chat or an email that will sit in an archive forever.
- Delete the account when the work is done, the same day. Not deactivate, delete, and reassign the content it owns.
Everybody is an Administrator
WordPress ships with five roles and most sites use one of them. The writer who publishes twice a month is an administrator. The designer who touched the homepage last spring is an administrator. The agency that built the site three years ago is an administrator, and so is the freelancer the agency subcontracted to.
Administrator is not a seniority level. It is the ability to install code, edit any file the server lets PHP write to, change every user password on the site, and read anything in the database that a plugin puts on a screen. A person who writes blog posts needs none of that, and giving it to them means their password is now worth as much to an attacker as yours.
| Enough | Usually given | |
|---|---|---|
| Writes posts | Author | Administrator |
| Edits all content | Editor | Administrator |
| Runs the shop | Shop Manager | Administrator |
| A fix this week | Admin, then deleted | Admin, forever |
| Reads analytics | No account | Administrator |
The row that costs people the most is the fourth one. A developer needs administrator access while they are working, and that is fine. The hole is that the account survives the invoice. Temporary access with no end date is just access, and it is usually protected by a password that person also uses on nine other client sites.
Nothing is guarding the door
WordPress will let anyone on the internet try to log in as many times as they like, forever, with no delay and no notice to you. That is the default, and every site running without something in front of it is being tried right now by bots working through leaked password lists.
Four things close most of that off, in order of how much they buy you:
- Two-factor authentication on every account that can install code. This is the one that matters. With it, a leaked password is an inconvenience. Without it, a leaked password is the whole site.
- A limit on failed login attempts, so a bot gets ten tries instead of ten million.
- Rate limiting at the edge, before the request reaches PHP. If your site is behind Cloudflare, a rule on
/wp-login.phpand/wp-admincosts nothing and stops the traffic before it costs you CPU. - No account named
admin. It saves an attacker the trouble of guessing the half of the pair they can usually see anyway.
Two-factor is the one people skip because it is mildly annoying, and it is worth more than the other three put together.
The door nobody remembers building
There is a second way into a WordPress site that has nothing to do with the login screen, and almost nobody audits it.
Application passwords let an external tool authenticate as one of your users over the REST API. A mobile app, a deploy script, a publishing integration, an AI assistant somebody wired up in an afternoon. Each one is a credential that works from anywhere, that two-factor does not cover, and that keeps working after the person who created it leaves. They are created in one click and revoked by absolutely nobody.
Where to find and revoke them
They live per user, at the bottom of the profile screen: Users, then the account, then Application Passwords. Each row shows the name whoever created it typed in, and when it was last used. A password with a last-used date from last year belongs to something that has been switched off for a year, so revoke it.
Check every administrator, not just your own account. This screen is per user and there is no site-wide list, which is most of the reason nobody looks.
The audit, in one afternoon
The whole audit fits in an afternoon and does not need a plugin.
- Open Users, All Users, and sort by role. Read the administrator list out loud. For each one, say what they do on the site this month.
- Delete the accounts belonging to people who are gone. WordPress asks what to do with their posts, so choose to reassign rather than delete the content.
- Drop the rest to the role that fits the work. Nothing breaks, and anyone who hits a wall can be moved back up in four seconds.
- Check application passwords on every account that survived step two.
- Turn on two-factor for everyone who can still install a plugin, and put a login limit in place.
- Write down where you send credentials from now on, and stop typing them into ticket replies.
Then put a note in the calendar for six months out to read the administrator list again. That is the entire maintenance burden, and it is the cheapest security work available to anyone running a WordPress site.
Access is one section of a larger list. The rest of it is here:
Last updated
