Employees leave. Agencies change. Freelancers finish projects. But their WordPress accounts and other credentials can remain active for years. A WordPress user access audit helps you identify who can still access your website, what permissions they have and whether that access is still necessary.
Last updated
22/09/2026
Your WordPress website was built five years ago.
Since then, a developer has worked on it. A designer made a few changes. An SEO agency had access. Your marketing team published content. A freelancer fixed a problem. Several employees came and went.
How many of those people can still log in today?
If you don’t know the answer, open Users → All Users in your WordPress dashboard.
You might be surprised by what you find.
Old user accounts are easy to forget because they rarely cause an obvious problem. The website continues to work, nobody complains, and an account created three years ago can remain there indefinitely.
But access to a business website should not be permanent simply because nobody remembered to remove it.
A regular WordPress user access audit helps you understand who can access your website, what they can do and whether they still need those permissions.
A WordPress user access audit is a review of the accounts that can access your website and the permissions assigned to them.
The goal is relatively simple. For every account, you should be able to answer three questions:
Who is this person?
Why do they need access?
Does their current role give them more access than they need?
WordPress includes a role and capability system that controls what different users are allowed to do.
The default roles are:
On a standard single-site WordPress installation, an Administrator has access to the site’s administration features, while the other roles have progressively more limited capabilities.
Plugins and custom development can also introduce additional roles and capabilities, so your own Users screen may contain more than these five defaults.
That makes reviewing the actual configuration of your website more useful than simply knowing the names of the default WordPress roles.
Start with the simplest step.
Log in to WordPress and go to:
Users → All Users
You will see the accounts registered on the website and their assigned roles.
Don’t immediately start deleting accounts. First, look at the list as a record of everyone who has been given access to the website over time.
Some accounts will be obvious. Others may belong to former employees, previous agencies, freelancers who completed a project years ago or people whose names nobody on the current team recognizes.
For each user, ask:
Does this person still work with us?
Do they still need access to this website?
Does their role match what they actually need to do?
The last question is particularly important. Someone may genuinely need access to WordPress without needing access to everything in WordPress.
An Administrator account nobody recognizes deserves additional attention. It may simply be an old account everyone has forgotten about, but an unexpected privileged account can also indicate that unauthorized access has occurred.
Instead of deleting it immediately and considering the problem solved, investigate when the account appeared and check whether there are other unexpected changes or credentials that should be reviewed.
Administrator access is convenient.
Someone asks for access to the website, you create an account, select Administrator and move on.
That is also how websites can gradually end up with far more administrators than necessary.
An Administrator can perform high-impact actions within the WordPress site. Depending on the configuration, that can include managing users, installing or managing plugins and themes, changing settings and modifying significant parts of the website.
A person who only publishes articles does not necessarily need that level of access.
Neither does every SEO consultant, content editor or external collaborator.
A better approach is to give each person the level of access required for their work.
For example, someone responsible for managing and publishing content may be better served by an Editor role than Administrator access.
The exact choice depends on what that person needs to do and on any custom roles or capabilities configured on the website.
Administrator access should be a deliberate choice, not the default answer to every access request.
This is where many access problems begin.
An employee leaves the company.
A development project ends.
You switch marketing agencies.
A freelancer finishes a one-time task.
Their WordPress account remains.
Months later, nobody remembers why it was created.
When someone’s work on the website ends, their access should be reviewed as part of the offboarding process rather than discovered during a cleanup two years later.
Before deleting a WordPress user, however, check whether the account owns any content.
WordPress allows you to reassign content associated with a user when deleting that account. Decide what should happen to that content before confirming the deletion.
Removing an account is not the only thing to consider when someone’s access changes.
If the account is staying active but its permissions are being reduced, consider whether existing WordPress sessions should also be terminated. The user’s profile includes a Log Out Everywhere Else option that can be used to end sessions on other devices.
This is also a good moment to think beyond the user’s regular WordPress password. The same person may have been given other credentials during their work on the website, from Application Passwords and SFTP credentials to hosting or deployment access.
Changing one password does not necessarily remove every other way that person may have been able to interact with the website.
A proper offboarding check should therefore answer a broader question:
What access did this person receive while working with us, and has all of it been reviewed?
And remember that removing a WordPress account only solves the WordPress part of the problem.
It can seem easier.
Instead of creating separate accounts for three people, everyone uses something like:
or a shared:
admin
The problem appears later.
Someone changes an important setting.
Who did it?
One person leaves the company.
Do you change the shared password for everyone?
You want to remove one person’s access.
How do you do that without affecting the others?
Individual accounts make access easier to manage because access belongs to a specific person rather than an entire team.
They also make it easier to revoke access when someone’s responsibilities change or they leave the organization.
If several people currently use one Administrator account, separating them into individual accounts is worth considering.
A strong password is important, but a password is still a single authentication factor.
Two-factor authentication adds another verification step to the login process.
WordPress core does not currently provide built-in two-factor authentication for standard installations.
One option is Two Factor, a free, open-source plugin available through the official WordPress plugin directory. It supports several authentication methods, including TOTP authenticator apps, email codes and backup verification codes.
There is an important limitation to consider on websites with multiple users.
With the basic Two Factor plugin, users configure two-factor authentication through their individual profiles. If you need to enforce 2FA enrollment for particular users or roles across an organization, you will need additional implementation or a solution that provides that enforcement.
For accounts with significant privileges, particularly Administrator accounts, adding another authentication factor can reduce the risk associated with a compromised password.
But 2FA does not solve poor access management.
An old Administrator account protected with 2FA is still an unnecessary Administrator account if that person no longer needs access.
For a broader look at where WordPress security risks actually come from, read our guide on WordPress security and the data behind the most common risks.
There is another type of access that is much easier to overlook during an audit.
Since WordPress 5.6, WordPress has included Application Passwords for programmatic access to a website.
These are separate credentials associated with a WordPress user account. They are designed for applications, integrations and scripts using interfaces such as the WordPress REST API and XML-RPC rather than for normal wp-admin logins.
You can review them in the Application Passwords section of the relevant user’s profile.
Depending on usage, WordPress can show information such as the name assigned to an Application Password, when it was last used and the IP address associated with its most recent use.
Individual Application Passwords can also be revoked.
This is important because changing a user’s regular WordPress password does not automatically revoke their Application Passwords.
They are separate credentials.
Imagine that an integration was configured two years ago using an Application Password. The integration is no longer used, the people who configured it no longer work on the website and the regular WordPress password has since been changed.
That Application Password still deserves its own review.
During an access audit, check which Application Passwords exist, what they are used for and whether each one is still required.
If an integration, application or script no longer needs access, revoke the corresponding credential.
Removing an old WordPress account does not necessarily mean that person no longer has access to your website infrastructure.
WordPress is only one layer of a modern website.
Developers, agencies and internal teams may have received access to hosting, servers, domains, repositories, databases or third-party services while working on the site. Some of those credentials can provide far more control over the website than a WordPress account itself.
That is why an access audit should include the systems surrounding WordPress, not just the accounts visible under Users → All Users.
For each service, the principle is the same: identify who has access, determine whether they still need it and revoke credentials that no longer have a valid purpose.
| Access to check | What to review |
|---|---|
| Hosting | Who can log in to the hosting account or control panel? |
| SFTP / FTP | Which users or credentials can still access website files? |
| SSH | Who has server-level access, and are old SSH keys still authorized? |
| Domain / DNS | Who can change DNS records, nameservers or domain settings? |
| Database | Which users or tools have direct database access? |
| CDN / Security services | Who can change firewall, caching or security settings? |
| Analytics / Tracking | Which users and agencies still have access to analytics and tracking accounts? |
| Email services | Who can access services responsible for transactional or website email? |
| Backup systems | Who can access, download, restore or delete website backups? |
| Git / Deployment tools | Which developers or teams can still access repositories or deploy changes? |
| Third-party integrations | Which external services, API credentials or connected applications still have access? |
ccess management is only one part of keeping a business website under control. The same principle applies to updates and technical changes, which should be tested before they reach production. See why a WordPress staging site matters.
Imagine removing a former developer from WordPress while their hosting or SFTP credentials still work.
From an access-management perspective, the job is not finished.
You don’t need to turn the process into a major project.
Start with the WordPress Users screen and work outward.
Open Users → All Users.
Identify every Administrator account.
Investigate accounts you don’t recognize.
Confirm whether each person still needs access.
Check whether each user’s role matches their actual responsibilities.
Review accounts belonging to former employees, agencies, developers and contractors.
Replace unnecessary shared accounts with individual accounts.
Review two-factor authentication for privileged accounts.
Check Application Passwords on relevant user profiles.
Revoke credentials belonging to integrations, applications or scripts that are no longer used.
End existing sessions when access needs to be terminated.
Then move beyond WordPress and check relevant hosting, SFTP or SSH, domain, database and other infrastructure access.
By the end of the audit, you should be able to answer a simple question:
Who can make changes to our website right now?
If the answer is still unclear, the audit isn’t finished.
There is no single review schedule that fits every website.
A small company website with two administrators has different access-management needs from a large publishing platform with dozens of editors, developers and external partners.
A practical approach is to review access whenever something changes.
For example:
Periodic reviews are still useful because not every access change is handled perfectly when it happens.
The more people and external partners work on a website, the more valuable a regular review becomes.
The same applies to the other components that accumulate around a WordPress website over time. If you’re reviewing access, it may also be a good opportunity to audit the plugins your website still depends on.
The most obvious accounts are rarely the interesting ones.
You know why the current developer needs access.
You know why your content manager has an account.
The accounts worth investigating are usually the ones that make you ask:
“Who is this?”
A WordPress website can remain online for years while employees, agencies, developers, integrations and business processes change around it.
Access permissions and credentials should change with them.
Open Users → All Users today.
If you cannot explain who every Administrator is and why they still need that level of access, you already know where to start.
And if “Who is this?” appears next to an Administrator account, don’t ignore it.
What does the European Accessibility Act mean for WordPress websites? Learn which businesses may be affected, what accessibility information may need to be published and how to identify common problems with keyboard navigation, forms, content and custom WordPress components.
How much does a WordPress website cost in 2026? Learn what determines the price, which costs are often left out of development quotes and how to compare two WordPress proposals based on scope, not price alone.
Your WordPress contact form looks like it works, but no emails arrive? Learn how to identify whether the problem is caused by the form, WordPress, SMTP, DNS authentication or email delivery.
Your 24wp website is developed by experts from Cubes — an IT company that has been creating complex IT ecosystems and stable web systems for a decade.
Visit cubes.rs