To remove a contractor's WordPress access safely, inventory human logins and machine credentials separately, establish replacement ownership, then verify revocation. Deleting one administrator account does not remove hosting access, SSH keys, identity-provider membership, or an integration credential stored elsewhere.
This guide covers planned offboarding. If there is suspected compromise or active misuse, follow the incident-response process and prioritize containment with the authorized security owner rather than waiting for a normal handoff window.
Establish a Working Replacement Administrator
Have the business owner sign in using an independently controlled account and recovery method. Confirm access to the host, DNS, backup controls, and any separate identity provider. Avoid discovering after revocation that the departing contractor was the only person able to restore the site.
Use the maintenance handoff checklist for the broader transfer. Here, create a narrower access register: system, account, purpose, replacement, revocation action, verification result. Store secrets separately.
Inspect WordPress Users and Machine Credentials
Review the departing user's roles and any multisite access. List application passwords associated with the account and identify the integration behind each one. WordPress application passwords are separately revocable API credentials, not browser-login passwords.
For an authorized operator, these read-only commands help inventory a known user. Replace 123 with the verified account ID:
wp user get 123 --fields=ID,user_login,roles
wp user session list 123
wp user application-password list 123 --fields=uuid,name,last_used
Keep session details and usage metadata private. A recent-use field can help identify a worker, but absence of recent activity does not prove a monthly integration is unused.
Verification record for Remove a Contractor's WordPress Access Without Breaking the Site. Fill in your own evidence.
Replace Dependencies Before Scheduled Revocation
Suppose the contractor's application password powers a nightly catalog import. Create an appropriately scoped replacement through the approved account process, test one synthetic or controlled operation, and update the worker's secret configuration. Then revoke the old credential and confirm it no longer authenticates.
Also inspect SSH keys, deployment tokens, remote maintenance tools, OAuth connections, hosting collaborators, and backup storage accounts. Changing a WordPress password does not update those independent systems. If a shared credential must be rotated, coordinate all legitimate consumers first.
End Access and Verify the Result
At the agreed cutoff, remove the relevant privileges and revoke associated credentials. End active sessions as appropriate; WP-CLI documents session destruction for a specific account. Do not run broad user or session deletion commands copied from another site's incident.
Test the revoked access path without soliciting or sharing the departing person's private password. The responsible administrator can verify permission state and use controlled credentials retained through the approved process. Verify the replacement integration separately.
Before deleting an author account, decide how its posts and other owned records will be reassigned or retained. Review the deletion screen carefully, including plugin-specific data that may not follow core's content handling. Removing access and deleting historical attribution are separate decisions.
Close With a Dependency Check
Observe the next scheduled import, backup, deployment, and important notification. Record any exception with an owner and deadline. A clean user list is not a completed offboarding if the next day's automation fails.
For an unclear custom worker or persistent access route, HandL WP can help audit the technical dependency. Provide account names and the intended outcome, not a public bundle of passwords and recovery codes.
References checked September 29, 2026. Diagrams and examples are explanatory, not measured customer results.