When Someone Leaves: How to Close WordPress Access Without Security Gaps
A practical routine for removing access, ending active sessions, changing shared secrets and checking the company website after a change of role.
Category: Website Security
When an employee leaves or an agency engagement ends, disabling a single WordPress user is not enough. The person may still have access to hosting, domain management, analytics tools, cloud storage, code repositories, forms and external services. Passwords and API keys may also be stored locally or shared between several people.
A proper offboarding routine must therefore treat the website as a chain of systems. The goal is not only to close the visible user account, but to remove all access paths without disrupting operations, content or ownership.
Start with an actual access map
The most common problem is that no one has a complete overview of who has access to what. WordPress only shows the users in the publishing system itself. It says nothing about access to the server, backups or the accounts that keep the website running.
Create a simple access map showing the system, account owner, administrators, access type and responsible internal contact. For a typical company website, the map should include at least:
- WordPress and any online stores or multilingual solutions
- Hosting, server panel and file access
- Domain, DNS and email configuration
- Database and database administration tools
- Cloud storage, backups and staging environments
- Code repositories and automated publishing routines
- Analytics, tag management and search tools
- Forms, newsletters, payment and integration services
- Security tools, monitoring and alerting
The access map should show both personal accounts and shared credentials. Shared passwords are particularly important to identify, because they cannot be disabled by deactivating a single user.
Clarify what must be preserved before removing the account
A user may own content, automations, reports or integrations. If the account is deleted without preparation, the company may lose access to important data or cause errors on the website.
Before making changes, clarify who will take over responsibility and ownership. In WordPress, published content must be assigned to another user. In external services, reports, folders and projects must be moved to a company-controlled account.
Also take a fresh backup before making major access changes. The backup must include both files and the database, and it should be stored somewhere the departing person does not control. This is not because the offboarding is expected to go wrong, but because access changes can affect integrations and automated processes.
Disable personal accounts first
Personal accounts should be deactivated rather than reused by others. This preserves traceability in logs while ensuring that the former user loses access.
In WordPress, check the user role before removing the account. An Editor has different capabilities from an Administrator, but both may have access to unpublished or business-critical content. Make sure the content is transferred to an active user, then close the account or remove all permissions.
The same review must be carried out for hosting, code repositories, domain management, security tools and cloud services. A disabled WordPress account is of little value if the person can still upload files directly to the server or change where the domain points.
End active sessions
Changing a password is not always the same as ending a logged-in session. A user may still be logged in through a browser or on a mobile device. Therefore, use features to log out of active sessions wherever available.
For high-risk accounts, you should also revoke app passwords, recovery codes, trusted devices and approved third-party applications. These forms of access are easily overlooked because they do not appear as ordinary user accounts.
Change shared passwords and technical secrets
If the person knew a shared password, the password must be changed. This applies even if there are no signs of misuse. A password may be stored in a browser, a note, an old project tool or a local configuration file.
Also review technical secrets such as API keys, database passwords, integration keys and keys used for automated publishing. Do not change everything at once without a plan. First map where each key is used, create a new key, update the integration, test that it works and then revoke the old one.
This sequence reduces the risk of contact forms, payments, newsletters or other important functions stopping. Changes should be documented without writing the secrets themselves in an ordinary document.
Check authentication for those who remain
Offboarding is a good time to clean up the remaining access. Remove old test users, accounts with no known owner and administrator privileges that are no longer necessary.
Require personal accounts for everyone who works on the website. Administrators and people with access to hosting, the domain or backups should use multifactor authentication. The second factor should be tied to the individual, not to a phone or inbox shared by several people.
At the same time, make sure the company has a controlled solution for emergency access. A single administrator must not be the only person who can restore access. The emergency account should be well protected, used rarely and monitored closely.
Look for changes that have already been made
Once access has been closed, investigate activity from the period before the offboarding. The purpose is not to suspect anyone, but to identify errors, forgotten integrations and unauthorized changes early.
Check, among other things:
- New or modified administrator users
- Installation and activation of extensions or themes
- Changes to files, configuration and database
- Created API keys, app passwords and forwarding rules
- Changes to DNS, domain or server configuration
- Unusual logins and failed login attempts
- Changes to forms, payment settings and notification recipients
If the logs do not provide an answer, it is an operational issue that should be addressed. A business website should have sufficient traceability for the responsible person to see who made an administrative change and approximately when it occurred.
Combine the offboarding with a vulnerability check
Old access is only one possible entry point. Outdated extensions, themes and server components can give an attacker other ways in. After a major change in responsibility or provider, the website should therefore be reviewed for known vulnerabilities and missing updates.
Updates should first be applied in a suitable test environment when the website has important integrations or e-commerce functionality. Check logins, forms, search, payments, email delivery and other key user journeys before deploying the changes to production.
Remove components that are not in use. A deactivated extension still remains on the server and may pose a risk. If a component cannot be updated or is no longer maintained, it should be replaced or retired according to a plan.
Monitor more closely during the first few days
After access and keys have been changed, the person responsible for operations should monitor logins, error messages, changes and availability particularly closely. New alerts may be caused both by attempts to use old access and by integrations that still use an expired key.
Agree on who receives the alerts and what should trigger action. An alert without an owner quickly becomes mere noise. Critical events, such as creating a new administrator or changing key files, should be assessed more quickly than ordinary failed login attempts.
Make the procedure part of the employee and supplier process
The safest offboarding is planned before anyone leaves. HR, management, IT and the person responsible for the website should know who initiates the process, who approves the access changes and who confirms that they have been completed.
A practical checklist can be divided into three points in time:
- Before the departure: Map access, transfer ownership, secure the necessary documentation and take a controlled backup.
- On the departure day: Deactivate personal accounts, terminate sessions and revoke direct access.
- After the departure: Change shared secrets, review logs, update vulnerable components and monitor the website more closely.
The procedure should also be used when an employee changes roles, an agency engagement is scaled back or a freelancer has completed a deliverable. Access should follow a documented need, not the history of the project.
Good access management ultimately comes down to ownership. The company must control the accounts, backups and keys that keep the website running. When this is in order, offboarding, provider changes and security incidents all become easier to manage.
