Who Actually Has Access? How to Conduct an Access Audit in WordPress
Old user accounts, shared passwords and administrator privileges that are never removed create unnecessary risk. A regular access review gives the organization control over who can do what on the website.
Category: Cybersecurity
Access permissions in WordPress tend to accumulate. A former employee still has a user account. The agency that built the website has several administrators. The marketing department shares a login with an external consultant. An integration uses an account that no one remembers creating.
Each individual access permission may once have had a valid justification. The problem arises when no one reviews them collectively or removes them when the need disappears. The organization is then left with more potential entry points to the website than necessary.
An access review is a systematic examination of users, roles, login methods and technical accounts. The goal is not merely to tidy up WordPress. You should be able to answer three questions: Who has access, why do they have access, and what can they do?
Why access management is about more than passwords
A strong password does little if the account belongs to someone who left a year ago. Two-factor authentication reduces the risk of stolen passwords, but does not solve the problem of overly broad permissions. Updates fix known software vulnerabilities, but cannot prevent misuse of a valid administrator account.
Good website security therefore requires multiple layers. Updates, backups, vulnerability management and monitoring are important measures, but access management determines who can affect these layers. An administrator can install plugins, change code, create new users and disable security features. Treat the permission as a key to the entire website, not as a convenient default role.
Start with a complete access map
Do not limit the review to the user list in WordPress. A business website often consists of several systems with their own access permissions. Map at least the following:
- user accounts and roles in WordPress
- access to web hosting, servers or control panels
- domain administration and DNS
- code repositories and publishing solutions
- backups, security tools and monitoring
- analytics tools, form solutions and other integrations
- email accounts used for password resets
- API keys, application passwords and technical users
Record the owner, purpose, access level and date of the last confirmation. If no one can explain why an account or key exists, it should not automatically be left in place. First check whether it is used by an integration or a planned process, then remove or rotate the access in a controlled manner.
Assess the need, not the job title
A common mistake is to give everyone who works on the website an administrator role. This is easy at the outset, but creates lasting risk. A content producer normally does not need to install plugins. A translator does not need to change users. A developer may need administrator privileges for a limited period, but not necessarily permanent access to the production environment.
Use the principle of least privilege: Each person and service should have exactly enough access to perform its task. No more.
Ask four questions about each access permission
- Is the need still active? Confirm that the person or system still performs the task.
- Is the role appropriate? Check whether the task can be completed with fewer permissions.
- Is the access personal? People should use individual accounts, not a shared common user.
- Does the access have an owner? A named person must be responsible for overseeing it.
Personal accounts make it possible to remove one person’s access without affecting others. They also provide better event logs. If five people use the same administrator account, it becomes difficult to determine who changed a setting or installed a plugin.
Distinguish between people and machines
Technical access is often forgotten because it does not appear as ordinary employees. A publishing tool may have an application password. A form may send data to another system using an API key. An operations provider may use automated keys for maintenance.
Such access should not be tied to an employee’s personal account. Create a clearly named service account when the solution requires one, and document what it is used for. Limit its permissions to the specific function. Secrets should be stored in a suitable system, not in email, spreadsheets or internal documents with broad access.
Also establish a routine for changing keys and passwords. Rotation is especially important when a provider ends an assignment, a key may have been exposed, or you no longer know who has had access.
Make strong authentication mandatory
All accounts with significant influence over the website should be protected with two-factor authentication. This applies not only to WordPress administrators, but also to web hosting, domain administration, email and other systems that could be used to take over or modify the website.
Passwords must be unique and stored in a password manager. Do not reuse a password from other services, and do not send passwords by email or chat. Where possible, the organization should use centralized login. This makes it easier to enforce authentication requirements and disable an employee’s access collectively.
At the same time, plan for login failures. Document how the organization can gain access if a phone is lost, an employee becomes unavailable or the identity provider experiences an outage. Backup codes and emergency access must be stored securely, tested and available to at least two trusted people. An emergency user must not be used for day-to-day work.
Build access management into the employment lifecycle
The best cleanup is the cleanup you do not have to repeat manually after every staffing change. Access to the website should be included in the procedures for onboarding, role changes and offboarding.
When someone starts
- Create a personal account with the appropriate role.
- Enable two-factor authentication before granting elevated privileges.
- Explain how passwords and recovery codes should be handled.
- Record who approved the access and why it is necessary.
When responsibilities change
- Remove previous privileges before adding new ones.
- Consider time-limited access for projects and temporary replacements.
- Review access for external providers when the assignment changes.
When someone leaves
- Close personal accounts at the agreed time.
- Revoke active sessions and recovery options.
- Change shared secrets the person may have known.
- Transfer ownership of integrations, domains and technical accounts.
- Retain necessary content without leaving the account ready for login.
Simply deleting the WordPress user is not enough. The person may still have access through the web host, an external identity account, the code repository or the email address that receives password reset messages.
Monitor changes in privileges
An access review shows the situation at a single point in time. Monitoring should capture what happens between reviews. Prioritize alerts for new administrators, role changes, numerous failed login attempts, disabled security features and logins from unexpected circumstances.
An alert has little value without a recipient and an agreed response. Decide who investigates the incident, how quickly this should happen and how an account is blocked if the activity cannot be explained. Logs must also be accessible if the website itself is compromised.
Also keep WordPress, themes and plugins up to date. An unused administrator account and a vulnerable extension are two different problems, but together they can increase the consequences. After major updates, check that roles, two-factor authentication, integrations and logging still work as intended.
Restrict access to backups
Backups are the last line of defence in the event of errors, attacks or unwanted changes. Therefore, not all WordPress administrators should automatically have permission to delete or modify backups. Otherwise, an attacker with full administrator access could compromise both the website and the ability to restore it.
Where possible, separate day-to-day website administration from control over backups. Document who can initiate a restoration, who approves it and how access works if the production environment is unavailable. Backup testing should also verify that the necessary keys and accounts are actually accessible in a crisis.
Conduct the review at regular intervals
For most organizations, it makes sense to review access several times a year and additionally after major changes. Websites with online stores, personal data, many editors or frequent use of consultants may require closer follow-up.
Conclude each review with a brief decision log:
- which accounts and keys were removed
- which roles were reduced
- which exceptions were approved, by whom and for how long
- which deficiencies need to be addressed
- date and person responsible for the next review
The result should not be an extensive document that quickly becomes outdated. A simple, up-to-date overview with clear ownership is more valuable than a detailed report no one uses.
A good end point: No unknown keys
A successful access review does not mean that as few people as possible should be able to work on the website. It means that all access is necessary, personal or clearly technical, properly restricted and possible to revoke.
When the organization knows who holds the keys, both day-to-day operations and incident response become easier. You can update more safely, investigate anomalies more quickly and restore the website without depending on an unknown account or a former provider.
