Every security audit I run includes a look at the user list. And on almost every site, I find accounts that shouldn’t be there. A marketing manager who left two years ago. The agency that built the site in 2019. A freelancer who fixed one bug and still has administrator access. Sometimes a “test” account with a weak password that someone created and forgot. That’s why WordPress offboarding deserves a checklist of its own.
None of these people are necessarily malicious. The problem is that their accounts are attack surface. A former employee’s email address gets breached, their reused password ends up in a credential dump, and suddenly an attacker has a valid admin login to your site. Nobody notices, because nobody remembers the account exists.
Offboarding is the process of removing access cleanly when someone stops working on a site. It’s boring, it’s easy to skip, and it closes one of the most common gaps in WordPress security.
Why offboarding gets missed
The main reason is that access to a WordPress site is spread across many places, and nobody keeps a list. A developer might have:
- A WordPress administrator account
- An application password for a deployment tool
- SFTP or SSH access to the server
- A login to the hosting control panel
- Access to the domain registrar or DNS provider
- A Cloudflare account membership
- An API key for an email service or payment gateway
- A Git repository with deploy keys
- Access to Google Analytics, Search Console and Tag Manager
Removing their WordPress user deals with one of those. The rest stay open.
The second reason is timing. When someone leaves on good terms, removing their access feels unfriendly, so it gets postponed. When an agency relationship ends, there’s often a handover period, and the cleanup gets lost after it.
Start with an access inventory
Good offboarding begins before anyone leaves. Keep a simple record, a spreadsheet is fine, of who has access to what. For each person or company, list every system and the level of access.
When someone joins, add them. When they leave, the list tells you exactly what to remove. Without it, you’re relying on memory, and memory is exactly what fails.
If you’re starting from nothing, build the inventory by checking each system in turn: WordPress users, hosting accounts, server SSH keys, DNS, registrar, CDN, analytics, third-party services and code repositories.
The WordPress side
Delete or downgrade the user account
Go to Users and find the person’s account. You have two options:
- Delete the user. WordPress asks what to do with their content. Always choose to attribute it to another user, unless you genuinely want their posts deleted. Deleting content by accident is a common and painful mistake.
- Downgrade and lock. If you need to keep the account for record-keeping, change the role to Subscriber or “No role for this site”, change the email to an internal address and reset the password to a long random value.
I usually prefer deleting and reassigning content. A locked account is still an account, and locked accounts tend to get unlocked “temporarily” later.
Revoke application passwords
Application passwords let external tools authenticate with the REST API without the user’s main password. They survive a password change. If the user is deleted, their application passwords go with them. If you downgrade instead, check the profile and revoke every application password listed.
End active sessions
If someone is logged in when you change their role, their session may continue until it expires. On the user profile, use “Log Out Everywhere Else” or, if you’re dealing with a hostile departure, rotate the authentication keys and salts in wp-config.php. That logs everyone out, including you, but it guarantees no old session survives.
Check for hidden admin accounts
While you’re in the user list, filter by Administrator and question every entry. Then check with WP-CLI, which shows accounts that some plugins hide from the admin screen:
Any account you can’t explain should be investigated before it’s removed. Unexplained administrators are a classic sign of compromise.
Review plugin-specific access
Some plugins have their own user lists or permissions. Form plugins might email submissions to a departed staff member. WooCommerce might have them listed as a shop manager or have their email on order notifications. Security plugins might send alerts to their inbox. Search your settings for their email address.
That finds every place in the database where their email appears, which is often more places than you’d expect.
The server and hosting side
Hosting control panel
Remove their user from the hosting account or change the password if it’s a shared login. Many hosts support multiple users with separate logins. If yours does, use that feature going forward instead of sharing one account.
SFTP and SSH
Remove their SFTP user, or change the password on a shared one. For SSH, open the authorized_keys file for each relevant system user and remove their public key.
Each line is one key, usually with a comment at the end identifying its owner. If keys don’t have comments, that’s a problem worth fixing for the future.
Database access
If they had direct database access, through phpMyAdmin, a remote MySQL user or a database client, remove or rotate those credentials. If the database password in wp-config.php was shared with them, change it and update wp-config.php at the same time.
Deployment tools and repositories
Remove them from the Git repository and any deployment service. Check for deploy keys or access tokens they created, which may be attached to the repository rather than their personal account.
Domain, DNS and CDN
These are the systems that hurt most when they’re lost, and the ones agencies most often control.
- Domain registrar. Make sure the domain is registered in the business’s own account, not the agency’s. If it isn’t, transfer it before the relationship ends.
- DNS provider. Remove their access or change the shared password. Check that recovery email addresses on the account belong to the business.
- Cloudflare or CDN. Remove them as a member. Check for API tokens they created.
If an agency controls your domain and the relationship ends badly, getting it back can take weeks. This is why domain ownership deserves attention long before anyone leaves.
Third-party services
Make a pass through every service connected to the site:
- Google Analytics, Search Console and Tag Manager: remove their user.
- Email delivery services like SMTP providers: rotate API keys they knew about.
- Payment gateways: remove their login and rotate API keys if they had access.
- Backup storage: change credentials for S3 buckets, Dropbox or wherever backups live.
- Licensed premium plugins: check whose account holds the licence. If it’s the agency’s, you may lose updates when the relationship ends.
Rotating an API key means generating a new one, updating it in WordPress and deleting the old one. It takes a few minutes per service and closes access completely.
Passwords they knew
Finally, think about every shared password the person had access to. A password manager with shared vaults makes this much easier, because you can see exactly which credentials they could view. Change those passwords.
If passwords were shared through email, chat or a document, assume they’re known and change all of them. That’s also a good moment to move the team to a proper password manager.
When the departure isn’t friendly
If someone leaves on bad terms, or you suspect they might cause damage, do the offboarding before or at the moment they’re told, not afterwards.
The order matters:
- Take a full backup of the site and database so you have a clean reference point.
- Remove hosting, SSH, SFTP and database access first, because those give the deepest control.
- Rotate WordPress salts to end all sessions, then remove their WordPress account.
- Change shared passwords and rotate API keys.
- Review the activity log for recent changes and check for new admin accounts, unfamiliar plugins or modified files.
For the following few weeks, keep a closer eye on login alerts and file change monitoring.
Make it a routine, not an event
The easiest way to keep offboarding under control is to review access on a schedule, not only when someone leaves. Every quarter, go through the user list and the access inventory. Ask, for each entry, “does this person still need this?” Remove anything that doesn’t have a clear yes.
Also reduce what you have to offboard in the first place. Give people the lowest role that lets them do their job. Editors don’t need to be administrators. A freelancer fixing a CSS issue can work on staging without production admin access. Time-limited access, where an account is created for a project and removed when it ends, saves a lot of cleanup later.
Access that was never granted never needs revoking. Good WordPress offboarding is quiet, routine and boring, which is exactly how security should feel.
Frequently asked questions
Should I delete a former employee’s account or just change their password?
Delete it and reassign their content, in most cases. A changed password still leaves an account that can be reset through email, and if their mailbox is ever compromised, that’s a way back in.
What if I delete a user and their posts disappear?
WordPress asks what to do with content when you delete a user. If you chose to delete it, restore from a backup. Next time, always choose “Attribute all content to” another user.
How do I handle an agency that set everything up under their accounts?
Ask for a structured handover: domain transfer, hosting account transfer or new account setup, plugin licences moved to your account and all credentials changed. Do it while the relationship is still cooperative, ideally before the final invoice is paid.
Is it rude to remove access the day someone leaves?
No. It’s standard practice, and most professionals expect it. Removing access promptly protects them too, because if something goes wrong later, nobody can suspect their account.
