Who Really Has Access? How to Audit WordPress Users
A regular access audit reduces the risk of compromised accounts, former employees retaining access, and an unnecessary number of administrators in WordPress.
Category: Website Security
A business website may be up to date, monitored, and backed up, yet still have a serious weakness: too many people have too much access. Old user accounts, shared administrator accounts, and external providers who were never removed are common results of a website that has been operating for several years.
The problem cannot be solved with strong passwords alone. The business needs a regular procedure for checking who has access, why they have it, and whether the level of access is still appropriate. A quarterly access audit is a practical place to start.
Access Is Part of the Attack Surface
Every user account represents a possible way into the website. The risk increases when the account has administrator privileges, lacks two-factor authentication, or belongs to someone who no longer works on the website.
An attacker does not need to find a technical vulnerability if it is possible to take over a valid account. Stolen passwords, reused login credentials, and access to a former employee’s email account may be enough. User administration must therefore be treated in the same way as updates, backups, and monitoring: as an ongoing operational task with clear ownership.
The access audit should not be limited to the user list in WordPress. It must also cover web hosting, domain administration, analytics tools, cloud services, security solutions, code repositories, and other systems that can affect the website.
Start with a Complete Access Inventory
The first step is to identify all the places where a person or service can obtain administrative access. For a typical business website, the inventory may include:
- WordPress user accounts
- Administration with the operations or hosting provider
- Access to the domain and DNS
- File transfer, database, and command-line access
- Code repositories and publishing solutions
- Analytics, form, and marketing tools
- Backups and monitoring systems
- API keys, integrations, and technical service accounts
Create a simple overview with the name, system, access level, justification, owner, and date of the last review. For technical accounts, specify which integration uses the account and who is responsible for it.
If no one can explain why access exists, it should not automatically be retained. First check whether the account is still in use, and remove or disable it if the need cannot be confirmed.
Separate Personal Accounts from Service Accounts
Everyone who works in WordPress should have a personal account. Shared accounts such as “admin,” “editorial,” or “agency” make it difficult to know who made a change. They also create practical problems when someone leaves: the password must be changed and redistributed to everyone else.
Personal accounts provide better traceability and make deprovisioning easier. Activity logs become more useful because changes can be linked to the correct user. It is also possible to remove one person’s access without affecting the rest of the team.
Service accounts may be necessary for integrations and automated tasks. They should not be used by people in their day-to-day work. Give them only the permissions required for the task, document their purpose, and store secrets in a suitable solution. An API key should be treated as access, not as a random technical setting.
Reduce the Number of Administrators
The administrator role in WordPress provides extensive control. An administrator can install plugins, change users, edit content, and affect the website’s technical configuration. The role should therefore be reserved for people who genuinely need this authority.
An editor who publishes articles usually does not need to install plugins. A content producer may only need to create and edit their own posts. An external adviser conducting a limited review does not necessarily need permanent administrator access.
Use the principle of least privilege:
- Describe the task the person will perform.
- Choose the lowest access level that makes the task possible.
- Set an end date if the need is temporary.
- Extend access only when a specific need arises.
- Remove the extension when the task is complete.
It is better to handle a justified request for more access than to let everyone retain the administrator role as a precaution.
Make Two-Factor Authentication Mandatory
A strong and unique password is necessary, but not always sufficient. Two-factor authentication adds an additional control at login and reduces the risk if the password becomes known to others.
At a minimum, the requirement should apply to administrators, editors, vendors, and people with access to hosting, the domain, or backups. For a business website, it is often simpler to make the requirement general than to maintain many exceptions.
Implementation must also account for the loss of a phone or authentication device. Backup codes should be stored securely, and the process for restoring access must be known. If support staff can disable two-factor authentication without thoroughly verifying the user’s identity, the weakness is merely shifted to the recovery process.
Check External Providers Separately
Web agencies, developers, consultants, and marketing partners often need access for limited periods. Nevertheless, such access is easily left in place after a project is completed or the contact person changes jobs.
Supplier access should be tied to named individuals, not to a general company account. The agreement should clarify who approves new users, how two-factor authentication is handled, and how quickly access must be removed when the engagement ends.
Ask the supplier to confirm the current user list during each audit. At the same time, the organization should verify this in its systems rather than relying solely on an email confirmation. Temporary access should have a clear end date or be included on a list of accounts to review after the engagement ends.
Connect HR procedures with website operations
Many outdated access permissions arise because information about role changes and terminated employment does not reach the person responsible for managing the website. Decommissioning digital access must therefore be part of the organization’s routine when someone leaves or changes roles.
A simple checklist should cover WordPress, hosting, the domain, email, password vaults, analytics tools, code repositories and relevant third-party services. Access should be removed at an agreed time, not only after someone later discovers that the account still exists.
When someone changes roles, deleting the user is not always the right approach. It may be sufficient to reduce their access level. Content and history should be transferred in a controlled manner so that important pages do not lose their designated owner.
Look for signs of misuse before removing the account
An unknown or unexpected administrator should not simply be deleted without further consideration. The account may indicate that someone has already gained unauthorized access. Check when the user was created, who created it, the last login and any relevant changes.
Also look for new administrators, changed email addresses, installed extensions, file changes and unexpected logins. If something cannot be explained, it should be handled as a potential security incident. Preserve necessary information before making major changes that could erase traces.
Activity logging is useful here, but only if logs are actually retained, reviewed and protected against alteration. Clarify which events should trigger alerts, such as the creation of an administrator or changes to security settings.
Conduct the audit as a regular work session
An access audit does not have to become a major project. For a straightforward business website, it can be organized as a regular quarterly work session:
- Export or review active users in all relevant systems.
- Confirm employment status, supplier relationship and actual need.
- Check roles, administrator privileges and temporary access.
- Confirm that two-factor authentication is enabled where required.
- Investigate accounts that are unknown, inactive or lack a clearly identified owner.
- Remove, disable or reduce access that cannot be justified.
- Document who approved the outcome and which discrepancies remain.
The audit should have one person responsible for it, but involve the website manager, technical supplier and people responsible for employees and supplier agreements. None of them will necessarily have the complete picture on their own.
Assess whether access is actually under control
A completed review is not necessarily a good review. Instead, track a few simple governance indicators: the number of administrators, accounts without a named owner, users without two-factor authentication, temporary access without an end date, and accounts belonging to former employees or suppliers.
The goal is not to remove as many accounts as possible. The goal is for every access permission to be necessary, personal, traceable and properly secured. When the organization can explain who has access, why they have it and how it will be removed, an important part of website security becomes manageable.
