WordPress Administrator Access Audit Checklist: Remove Stale Privileged Access

Last reviewed: April 13, 2026

Most WordPress teams know they should protect administrator access, but far fewer can answer a more useful operational question: exactly which people, bots, integrations, and old service accounts still have privileged access to production right now? That gap matters because WordPress incidents are not always caused by a fresh vulnerability or an exploit chain. Sometimes the easiest path is a stale administrator account, a forgotten contractor login, or an integration that still authenticates as a highly privileged user long after its original purpose is gone.

A serious access review is not a one-line reminder to “use strong passwords.” It is a concrete audit of who has which role, whether those privileges are still justified, which accounts authenticate interactively, which ones authenticate through Application Passwords or other programmatic flows, and how quickly the team can revoke access without breaking a production workflow. For operators responsible for live WordPress environments, privileged access should be small, explicit, and easy to explain.

Who this guide is for

This article is for WordPress administrators, agencies, platform teams, and security operators responsible for production sites. It is especially relevant for teams with multiple admins, outside contractors, API integrations, shared support access, or any site that has accumulated users over time without regular review.

Key takeaways

• Administrator access should be treated as a small exception set, not the default role for anyone who “might need it later.”
• An access audit has to include both human logins and programmatic access such as Application Passwords, because integrations often persist after the original owner or project has changed.
• The right outcome is not just a cleaner user list. It is a repeatable review process with owners, revocation steps, and a clear rule for when a user should have admin at all.

WordPress administrator access audit checklist

1. List every administrator account and treat the output as a risk register, not a directory. WordPress roles and capabilities are the foundation of access control, and the built-in Administrator role on a single-site install is the highest normal privilege level. Start by enumerating every account with the administrator role and comparing that list against what the team believes is true. This is where you usually find the gap between documented access and actual access: departed employees, old agency users, break-glass accounts with weak naming, duplicated test accounts, or emergency users created during an incident and never cleaned up.
2. Separate interactive human users from service or integration identities. Not every privileged account should behave the same way. A person logging into wp-admin should not be mixed conceptually with a headless publishing script, CI job, or third-party integration. WordPress Application Passwords are designed specifically so applications do not need a user’s main password, and the official docs emphasize that they are individually revocable and intended for programmatic access. If an integration is still authenticating as a human administrator account instead of an explicit service user, that should be treated as technical debt and an avoidable blast-radius problem.
3. Challenge whether each admin role is still justified. Many WordPress sites accumulate administrators because it is faster than defining a cleaner operational boundary. But roles exist for a reason, and the Plugin Handbook is clear that roles map to sets of capabilities. A real audit asks whether an editor, support person, agency contributor, or content operator truly needs admin-level capability, or whether a lower role and a documented escalation path would be enough. If the answer is “we left admin in place just in case,” that is not a reason. It is the finding.
4. Review Application Passwords as part of privileged access, not as a separate convenience feature. Application Passwords are safer than handing a service the main password for a WordPress user, but they still represent real access. The official handbook notes that they are tied to a user account, intended for API authentication, and should be individually revocable. During an access audit, list which users have Application Passwords, which integrations they belong to, when they were last used, and whether the user account behind them still needs the privileges it has. A stale application credential tied to an administrator is still stale privileged access.
5. Review evidence of ownership and recency. An account with admin rights but no clear owner should be treated as suspect until proved otherwise. The same goes for old service accounts with vague names, accounts whose email addresses no longer match active staff, or credentials that have not been used in a long time but still retain privileged capability. WordPress and WP-CLI give enough visibility to make this practical. What matters is that the team uses the data to decide whether access should stay, change, or be revoked.
6. Make revocation and downgrade part of the audit, not an optional follow-up. Security reviews fail when they stop at reporting. If an admin does not need admin, remove the role or replace it with a lower one. If an integration is obsolete, revoke its Application Password. If a contractor account should no longer exist, disable or remove it according to your retention process. The useful test is whether the team can reduce privileged access during the review window without confusion about who owns the decision or how rollback would work if a business workflow breaks.
7. Require stronger controls for the small set of admins that remain. WordPress’ own brute-force hardening guidance recommends strong passwords and 2FA for all administrators and privileged users, while using Application Passwords for trusted API access instead of reusing the main login password. After the cleanup pass, the remaining admins should be the best-protected identities in the environment: strong unique passwords, 2FA where available, at least two enrolled authenticators or a clear recovery path, and no unnecessary sharing of credentials between people or systems.

Useful commands or validation steps

# List all administrator accounts
wp user list --role=administrator --fields=ID,user_login,user_email,display_name,user_registered --format=table

# List all users for broader review
wp user list --fields=ID,user_login,user_email,roles,user_registered --format=table

# List application passwords for a user
wp user application-password list 123 --fields=uuid,name,created,last_used,last_ip

# Remove an unnecessary role from a user
wp user remove-role 123 administrator

wp user list --role=administrator is the fastest starting point and is explicitly recommended in WordPress’ own WP-CLI security guidance. Pair that with Application Password review so you are not only auditing who can sign into the dashboard, but also which integrations still authenticate as privileged users behind the scenes.

What to verify before calling the audit complete

• Every privileged account has a named owner. No anonymous break-glass, shared, or “temporary” admin should remain unexplained.
• Every admin role has a business reason. If the person only manages content or support tasks, the role should likely be lower.
• Service access is separated from human access. Integrations should use explicit service identities and revocable Application Passwords where appropriate, not a staff member’s primary admin login.
• Unused or unclear credentials are removed or downgraded. The value of the audit is privilege reduction, not just documentation.
• The remaining admin set is strongly protected. Strong passwords, 2FA or equivalent controls, and a known recovery process should apply to every account that keeps admin-level authority.

Common mistakes

• Leaving administrators in place “just in case.” That turns temporary convenience into permanent risk.
• Ignoring Application Passwords during access reviews. Human logins and API credentials are part of the same privileged surface when they map back to the same user account.
• Sharing one admin across multiple people or tools. Shared accounts destroy attribution and make revocation harder during an incident.
• Assuming lower-risk teams need admin because WordPress is “easier that way.” That is usually a process shortcut, not a real requirement.
• Stopping at the spreadsheet. If no roles are downgraded and no stale credentials are revoked, the audit created paperwork, not risk reduction.

What to document or review next

• The approved criteria for assigning or keeping the administrator role on each site.
• The list of service users and which integrations or automations they belong to.
• The exact revocation workflow for employees, contractors, incident responders, and temporary support access.

Related reading

If integrations still authenticate as highly privileged users, follow this with WordPress Application Password Security Checklist: Create, Scope, Rotate. If you want a broader production access baseline for backend-only deployments, pair it with Headless WordPress Security Checklist: 5 Controls to Enable Before Launch.

References and further reading

• Plugin Handbook: Roles and Capabilities
• Common APIs Handbook: User Roles and Capabilities
• Advanced Administration Handbook: Application Passwords
• Advanced Administration Handbook: Brute Force Attacks
• REST API Handbook: Authentication
• WordPress Developer Blog: Website security checks with WP-CLI