Most hardening guides open a configuration file first. There is a step before that: counting how many people can currently do anything at all on this site. However many doors you close in configuration, eight people holding keys means eight things to protect.
WordPress has had roles and capabilities from the start. The tooling is not missing — the defaults are simply easy to leave alone. This part is about actually using them.
Counting administrators is your first measurement
You can read the list from the Users screen, but pulling it with a command leaves you something to compare against at the next audit.
wp user list --role=administrator --fields=ID,user_login,user_email,user_registered
wp user list --role=editor --field=user_loginThe first time you run it, the list is usually longer than you remember. Temporary accounts from the build, an agency account, someone who left, an account created for an integration, and the one you raised “just for a moment” and never lowered again.
An administrator account is a full copy of the site’s authority: install plugins, edit files, add users, change settings. More accounts means more passwords and more devices to protect, and the weakest one of them sets the level for the whole site.
Roles are not features — they set the blast radius
An editor writes, edits and publishes. They have no reason to install plugins. Yet sites where the person who only edits holds administrator are common, and the reason is almost always “they needed it once”. Rather than a standing grant for that one occasion, raise the role when it is needed and lower it afterwards.
If the capability someone needs does not line up with a built-in role, create one. An editor plus a single extra capability is always narrower than an administrator.
Do not create shared accounts. When several people use one login, nothing records who did what, and after an incident you have no idea where to start looking. Everyone having to change the password when one person leaves is a cost of the same shape.
Lower before you delete
Deleting an unused account outright cuts everything attached to it. An integration may be calling an external API as that user; a scheduled job may run under their name. Drop them to subscriber, watch for a week, then delete — and whatever depended on that account shows up as something visible rather than a quiet failure.
On deletion WordPress asks what to do with that user’s posts. If you do not choose attribute to another user, the posts go with them. Always reassign for any account with published work.
While you are there, review application passwords too. They are a route in that needs no human login, and they are easy to create once and forget. Revoke anything you cannot explain the purpose of — you can always issue a new one.
More on permission design and account hygiene lives in the Security archive, and a review of an existing site’s permissions and configuration is part of the diagnostic in our optimization program.
Next part
With fewer administrators, the next job is limiting what a single stolen administrator session can do. The next part covers the two constants that close the path from the admin screen to running code.