Audit WordPress access before an old account becomes a current problem

A WordPress access audit should answer two questions: who can change the site, and which external tools can act through those accounts? A list of staff names answers only the first. An old integration credential can remain relevant after the person who created it has stopped logging in.

Begin with a recoverable copy of the site and a confirmed owner-controlled administrator account. Then review named users, their actual capabilities and their application passwords. This guide assumes a standard single-site WordPress installation. Multisite, membership products and role-management plugins can change the model, so verify the permissions on the installation rather than treating a role label as proof.

Start with a task, not the most convenient role

WordPress's roles and capabilities documentation describes the default permission groups. A Contributor can write and manage their own posts but cannot publish them; an Author can publish their own posts; an Editor can manage other people's posts. An Administrator has broader site-management powers. Those differences matter when a contractor only needs to submit a draft.

For each account, write one sentence describing the current job. “Uploads the weekly report for editorial review” is more useful than “marketing.” Compare that job with the actions the account can perform. Where standard roles do not fit, define the requirement before installing or changing a role plugin, and test the resulting capability set rather than trusting its display name.

Do not share an administrator login to avoid creating another user. A named account lets the team remove one person's access without deliberately distributing a replacement password to everyone else. Maintain an owner-controlled recovery route so that removing an agency or contractor does not also remove the only person able to administer the site.

Test a proposed lower-privilege role with representative work: saving a draft, uploading needed media, editing the intended content and attempting an action that should be forbidden. A standard Contributor cannot upload files, so a workflow that requires image uploads needs a considered adjustment. Solve the specific requirement, not every possible future request by granting administration.

Inventory application passwords as separate credentials

WordPress's REST API authentication guide describes application passwords for authenticated API access over HTTPS. They are separate from the user's normal login password. Their useful operational feature is that an integration can have its own credential instead of receiving the person's everyday password.

Record which account owns each credential, which service uses it, who maintains that service and whether the connection is still needed. A descriptive name helps identify the purpose; it is not, by itself, a restriction on what requests the credential can make. Keep the service account's permissions aligned with the work the integration actually performs.

The WordPress application-password integration guide explains the feature's management and revocation model. Use a separate credential for each connection so that retiring one tool does not require breaking every other integration attached to the user. Do not paste application passwords into an audit spreadsheet, support email or public issue; record the owner and purpose, not the secret.

When an integration's owner is unknown, investigate before deleting blindly. Identify the related publishing job, backup task or synchronization and find the person accountable for it. Unknown does not mean harmless, but it also does not mean unused. The audit should turn uncertainty into an explicit keep, replace or revoke decision.

Revoke access in a controlled sequence

For a planned departure, first identify what must continue: scheduled publication, content ownership, media handling and integrations. Transfer operational responsibility and create any replacement credentials through the authorized account. Confirm that the replacement works before retiring a credential required for a continuing service.

For suspected compromise, prioritize containment and follow the site's incident process rather than waiting for a routine handover. This guide is an access review, not an incident-response guarantee. Preserve relevant records and involve the responsible administrator or security specialist where the situation requires investigation beyond ordinary account cleanup.

For an ordinary cleanup, revoke the chosen application password, confirm that the old connection no longer authenticates and check that unrelated integrations still work. Then reduce or remove the person's interactive access as appropriate. Revocation is not verified merely because someone clicked a button; the expected denied request and the unaffected working process are the useful evidence.

Before deleting a user, review what the deletion will do to their content and authorship, and deliberately choose any required reassignment. Do not turn access cleanup into accidental editorial deletion. The controlled-change principles in our WordPress staging and rollback guide are useful where a role plugin or other configuration change is involved.

Make the access record small enough to maintain

Keep one entry per user and a linked entry per integration: purpose, owner, role or capabilities, review date and decision. Store credential secrets in the team's approved secret-management system, not beside the readable inventory. The inventory should help a successor understand the site without giving that successor every secret by default.

Add an explicit trigger for review when a contract ends, a person changes duties or a tool is retired. A periodic review can catch omissions, but an offboarding event should not wait for the next calendar reminder. Include the process in the site's maintenance routine with a named person responsible for completing it.

At the end, test both sides of the change. The retained editor should still be able to do the intended work; the retired account or credential should fail at the action it no longer has permission to perform. Record the test and result without claiming that this proves the whole site is secure.

A useful audit ends with fewer unexplained privileges, not necessarily fewer accounts. Separate, purposeful accounts can be easier to manage than a small collection of shared administrator logins. The goal is to make every active permission defensible and every removed permission demonstrably gone.