WordPress Account Offboarding Checklist

A WordPress account offboarding checklist helps administrators remove access safely when an employee, contractor, agency, client or temporary collaborator no longer needs a WordPress account.

Account offboarding sounds simple:

User no longer needs access
↓
Delete account
↓
Done?

In practice, that approach can create unnecessary problems.

A WordPress user may own content, have active sessions on several devices, hold custom capabilities, receive system emails, belong to multiple sites, own API credentials or remain connected to external services.

A safer offboarding process therefore looks more like:

Confirm departure
↓
Review account
↓
Restrict future authentication
↓
Terminate active sessions
↓
Review permissions and integrations
↓
Transfer content ownership
↓
Preserve required records
↓
Delete or retain account
↓
Verify access is actually gone

This guide provides a complete WordPress account offboarding checklist covering immediate access removal, session termination, roles and capabilities, content ownership, integrations, application passwords, Multisite, audit records and long-term account cleanup.

If you first need to understand how WordPress permissions are structured, see WordPress User Roles and Capabilities, Explained.

What is WordPress account offboarding?

Account offboarding is the process of safely removing or restricting a user’s access when that person no longer needs to work inside a WordPress installation.

Common examples include:

• an employee leaving the company;
• a contractor finishing a project;
• an agency relationship ending;
• a client no longer needing backend access;
• a temporary reviewer completing their work;
• a developer losing production access;
• a compromised account being retired;
• a duplicate account being removed;
• an old administrator account being replaced.

The objective is not simply to make the username disappear from the Users screen.

The objective is to remove access while preserving everything the organization still needs.

Why deleting the user immediately can be a mistake

A WordPress user is not just a login credential.

The account can be connected to:

• posts;
• pages;
• custom post types;
• media;
• comments;
• user metadata;
• plugin-specific records;
• custom roles;
• application passwords;
• active browser sessions;
• external integrations.

Deleting the account before reviewing those relationships can destroy information or make historical ownership harder to understand.

WordPress provides wp_delete_user() for deleting a user and optionally reassigning their posts and links to another user.

That optional reassignment is important because deleting an account without deciding what happens to its content can have consequences far beyond authentication.

Offboarding should begin before account deletion

A useful sequence is:

1. Identify the account
2. Determine urgency
3. Restrict authentication
4. Destroy active sessions
5. Review permissions
6. Review owned content
7. Review credentials and integrations
8. Transfer responsibilities
9. Preserve required history
10. Delete or retain the account
11. Verify the result

The order matters.

You generally want to stop unwanted access before beginning the slower process of reviewing historical content, integrations and account relationships.

Step 1: Confirm the exact WordPress account

Do not perform offboarding based only on a display name.

A WordPress account can contain:

User ID
Username
Display name
Email address
Roles
Capabilities
Metadata

Display names are not necessarily unique.

Confirm the correct account using stable identifying information such as the user ID and username before making destructive changes.

Step 2: Determine whether access removal is routine or urgent

Not every offboarding event has the same risk level.

A scheduled contractor departure may allow a controlled transition.

A suspected compromised administrator account requires a different response.

Routine offboarding
→ Review and transfer responsibilities
→ Restrict access at agreed time
→ Verify

Security offboarding
→ Restrict immediately
→ Destroy sessions immediately
→ Investigate activity
→ Rotate affected credentials
→ Review changes

For suspicious authentication activity, How to Monitor WordPress Login Attempts explains what login activity can tell you before and during an access review.

Step 3: Prevent future login

If the account should no longer be used, prevent it from authenticating again.

Simply changing its role does not necessarily solve this problem.

For example:

Administrator
↓
Subscriber

reduces WordPress permissions, but the account still exists and may still authenticate.

If your actual requirement is:

This account must no longer be able to log in

then treat authentication blocking as its own control.

TheOneWP provides a Block User Login module for disabling authentication for selected accounts without immediately deleting them.

Why temporary account suspension is useful

There is often a useful period between:

Access ends
and
Account is deleted

During that period, administrators can:

• review content ownership;
• inspect account metadata;
• transfer responsibilities;
• review integrations;
• preserve historical records;
• confirm that nothing depends on the account.

Suspension separates the urgent security decision from the slower data-retention decision.

Step 4: Terminate all active WordPress sessions

Preventing future login does not automatically mean an already authenticated browser session has disappeared.

If the user currently has WordPress open on:

Office desktop
Laptop
Home computer
Mobile browser

those existing sessions should be considered separately.

WordPress provides the WP_Session_Tokens class for managing user authentication sessions.

To destroy every session for a particular user:

$user_id = 123;

$sessions = WP_Session_Tokens::get_instance(
    $user_id
);

$sessions->destroy_all();

The destroy_all() method invalidates all sessions belonging to that user.

For the complete process, see How to Force Logout a WordPress User Immediately.

Blocking login and destroying sessions are different actions

A reliable offboarding workflow understands the difference:

Block login
→ Prevent future authentication

Destroy sessions
→ Invalidate existing authentication

If you only destroy sessions but leave the credentials valid, the user may simply authenticate again.

If you only block future authentication without considering already active sessions, you may leave an existing authenticated state untreated depending on how the restriction is implemented.

For definitive access removal, both states need consideration.

Step 5: Review the user’s roles

Before deleting or permanently retaining the account, document what access it actually had.

WordPress includes standard roles such as:

• Administrator;
• Editor;
• Author;
• Contributor;
• Subscriber.

Many production installations also contain custom roles created by plugins or custom code.

The account might therefore be:

Shop Manager
SEO Manager
Client Editor
Content Reviewer
Support Agent
Custom Administrator

Role names alone do not tell the whole story.

How to Audit User Roles on a WordPress Site provides a more complete method for reviewing existing role assignments.

Step 6: Review capabilities, not only roles

WordPress authorization ultimately depends on capabilities.

A user may receive capabilities through:

• a role;
• multiple roles;
• direct user capabilities;
• custom plugin logic;
• Multisite privileges.

Examples include:

edit_posts
publish_posts
edit_pages
manage_options
edit_users
install_plugins
activate_plugins
upload_files

If you are auditing access programmatically, WordPress provides user_can() for evaluating whether a particular user has a capability.

For designing more precise restrictions, see Restricting WordPress Features by User Role.

Step 7: Check whether the user has multiple roles

Some WordPress installations allow users to hold more than one role.

An account could therefore have:

Editor
+
SEO Manager
+
Custom Client Role

Removing one role does not necessarily remove all effective permissions.

TheOneWP’s Multi-Role Assignment module is relevant on sites where accounts intentionally combine responsibilities, because offboarding those users requires reviewing the complete role set rather than one visible label.

Step 8: Review custom capabilities

Some accounts accumulate direct capabilities independently of their normal role.

This can happen through:

• role-management tools;
• custom development;
• temporary access changes;
• legacy configuration;
• manual capability assignments.

An account that appears to be an ordinary Editor may therefore have unexpected administrative abilities.

Before treating a role downgrade as complete access removal, verify the effective permissions.

TheOneWP’s Role Manager can help administrators inspect and maintain more deliberate WordPress role structures.

Step 9: Identify content owned by the user

Before deleting an account, determine which WordPress content uses that account as its author.

This may include:

• posts;
• pages;
• custom post types;
• products;
• portfolio entries;
• documentation;
• knowledge-base articles;
• other plugin-defined content.

Custom post types deserve particular attention because a site may contain important content that does not appear in the ordinary Posts or Pages screens.

For the underlying model, see WordPress Post Types vs. Custom Post Types.

Step 10: Decide who should own the content afterward

If the departing user authored content that should remain on the site, identify the new owner before deleting the account.

For example:

Departing user:
Jessica

Content:
47 posts
8 pages
12 case studies

Reassign to:
Editorial Team

WordPress can reassign authored posts and links when deleting a user through wp_delete_user().

The important part is deciding intentionally where that ownership should go.

Do not automatically assign everything to Administrator

A common shortcut is to reassign all departing-user content to the main Administrator account.

That works technically, but it can produce poor editorial attribution.

Depending on the site, a better destination might be:

• another editor;
• a generic editorial account;
• the company account;
• the responsible department;
• the replacement employee.

Choose the owner according to the site’s editorial model rather than whichever account happens to have the highest privileges.

Step 11: Review custom post types before deletion

Custom post types can behave differently during user deletion depending on how they were registered and how plugins manage ownership.

Examples include:

Products
Events
Properties
Courses
Jobs
Projects
Testimonials
Documentation

Before deleting an important account, verify whether those objects:

• have an author;
• are reassigned correctly;
• are deleted with the user;
• use separate ownership metadata;
• are managed by another plugin-specific relationship.

This is one reason account deletion should come near the end of the checklist rather than at the beginning.

Step 12: Review user metadata

WordPress and plugins can store substantial information against a user account.

Examples include:

• preferences;
• plugin settings;
• workflow assignments;
• notification preferences;
• custom profile fields;
• integration identifiers;
• access configuration;
• internal operational data.

WordPress User Meta, Explained explains how this information is associated with user accounts.

Before deleting an account, determine whether any plugin stores operational information there that needs to be transferred or preserved.

Step 13: Review application passwords

WordPress application passwords can provide external applications with authenticated access without using the user’s normal interactive login password.

This means an account may participate in:

External publishing tool
Mobile application
Automation
REST API integration
Third-party service

An offboarding review should therefore ask:

Does anything authenticate as this user outside the browser?

If the answer is yes, identify those integrations before deleting or disabling the account.

Step 14: Move integrations away from personal accounts

If a business-critical integration authenticates using an employee’s personal WordPress account, offboarding exposes an architectural weakness.

For example:

Employee account
↓
REST API integration
↓
External CRM
↓
Business-critical automation

When the employee leaves, the organization should not be forced to keep that person’s account active merely to preserve an integration.

Where appropriate, operational integrations should use dedicated accounts with narrowly defined permissions rather than personal employee accounts.

Step 15: Review REST API access

If the departing account was used by custom applications or integrations, review how those systems authenticate and what permissions they have.

For the security fundamentals, see WordPress REST API Security Basics.

Offboarding is also a useful moment to identify API access that was created long ago and no longer has a clear operational owner.

Step 16: Review external systems connected to WordPress

WordPress may be only one part of the person’s access.

Depending on the environment, review related access to:

• hosting;
• DNS;
• CDN services;
• analytics;
• search tools;
• email services;
• SMTP providers;
• payment systems;
• Git repositories;
• deployment systems;
• backup storage;
• object storage;
• monitoring platforms;
• password managers.

Removing the WordPress account does not revoke credentials belonging to external systems.

Step 17: Rotate shared credentials when necessary

If the departing person knew credentials shared by several team members, disabling their individual WordPress account does not revoke knowledge of those credentials.

Examples include:

Shared hosting password
Shared SFTP password
Shared database credential
Shared API token
Shared staging password

Where practical, use individual credentials instead of shared credentials.

When shared credentials cannot be avoided, rotate them during offboarding if the departing user knew them.

Step 18: Review privileged WordPress access

Administrator accounts deserve extra scrutiny because they may have been able to:

• install plugins;
• activate plugins;
• manage users;
• change settings;
• modify site configuration;
• access security tools;
• create additional accounts.

If an administrator is leaving unexpectedly or under suspicious circumstances, review whether additional accounts or permissions were created before departure.

How to Audit User Roles on a WordPress Site can help establish the site’s current access structure.

Step 19: Check for unexpected accounts

When a privileged account is being offboarded for security reasons, review other users for unexpected additions.

Look for:

• recent administrator accounts;
• unfamiliar usernames;
• unexpected email domains;
• duplicate-looking accounts;
• accounts with unusual roles;
• recently activated dormant users.

If registrations themselves appear suspicious, Detecting Spam Registrations on WordPress provides additional context for identifying unwanted accounts.

Step 20: Review login history

Before permanently removing an important account, login history can provide useful operational context.

You may want to know:

When was the account last used?
Was it recently active?
Were there suspicious login attempts?
Did activity continue after the expected departure date?

TheOneWP’s Last Login module can help surface recent account usage during user administration.

Last-login information is a signal rather than proof of legitimate or malicious activity, but it can help identify accounts that deserve closer review.

Step 21: Review dormant accounts at the same time

Offboarding one user is a convenient opportunity to notice whether several other obsolete accounts are still present.

For example:

Former developer
Last login: 2 years ago

Old agency account
Last login: 18 months ago

Test administrator
Last login: never

Former employee
Still Administrator

Auditing Dormant WordPress User Accounts provides a systematic process for reviewing accounts that may no longer require access.

Step 22: Review temporary accounts

Temporary accounts are particularly easy to forget after the original project or support request has ended.

Typical examples include:

• freelancers;
• support technicians;
• developers;
• SEO consultants;
• designers;
• client reviewers;
• external auditors.

If an account was intended to be temporary, compare its current access with the original reason it was created.

If that reason no longer exists, the account should enter the same offboarding process as any other user.

Step 23: Use expiration policies for temporary access

Some accounts have a predictable end date from the moment they are created.

For example:

Campaign contractor
Expires: October 31

External auditor
Expires: December 15

Seasonal editor
Expires: January 10

For these accounts, an expiration policy can reduce dependence on somebody remembering to disable access manually.

The underlying principle is simple:

Temporary responsibility
↓
Temporary permission
↓
Defined expiration
↓
Access review or automatic restriction

Even when expiration is automated, the rest of the offboarding checklist may still be necessary because content ownership, integrations and historical records remain separate concerns.

Step 24: Review two-factor authentication implications

If the account uses two-factor authentication, remember that 2FA protects authentication but does not replace offboarding.

A departing user who still controls:

Password
+
Second factor

still possesses valid authentication material unless the account itself is restricted.

TheOneWP’s Two-Factor Authentication module can strengthen active accounts, but access termination remains a separate administrative process.

Step 25: Review email destinations

A departing user may receive WordPress-generated emails such as:

• administrative notices;
• security notifications;
• workflow messages;
• form notifications;
• plugin reports;
• backup alerts;
• site health information.

Check whether the person’s email address appears in:

• WordPress settings;
• plugin settings;
• forms;
• SMTP configuration;
• custom code;
• notification workflows.

Removing the WordPress account does not automatically rewrite every email destination stored elsewhere.

Step 26: Review the site administration email

The WordPress administration email is particularly important because it may receive site-level communications.

Do not leave a former employee’s address configured as the site’s administrative contact.

Check the current administrative email and move it to an appropriate organizational address when necessary.

Step 27: Review internal notification workflows

If your WordPress installation contains role-based or user-specific notifications, remove the departing user from those workflows.

For example:

Editorial review recipients
Security alerts
Client approval notifications
Publishing notifications
Maintenance notices

For sites using WordPress as part of a collaborative workspace, Internal Team Communication inside WordPress explains how internal communication can become part of the administration workflow.

Step 28: Reassign unfinished work

Content ownership is not the same as responsibility for unfinished work.

A departing editor may have:

• drafts awaiting completion;
• scheduled posts;
• pending reviews;
• unresolved editorial comments;
• client changes;
• SEO tasks;
• unpublished landing pages.

Identify who becomes responsible for those items before the original account disappears from normal workflows.

Step 29: Review scheduled content

Check whether the user owns content scheduled for future publication.

Examples include:

Blog posts
Campaign pages
Announcements
Product launches
Events
Promotional content

Verify that those items still have the correct ownership, publication status and responsible reviewer after offboarding.

Step 30: Review editorial notes and internal history

If your workflow stores internal comments, review notes or approval history, decide whether that information should remain attributed to the departing user.

Historical attribution can remain useful even after authentication has been disabled.

Original author or reviewer
↓
Account disabled
↓
Historical identity preserved
↓
Past decisions remain understandable

This is another reason retaining a blocked account can sometimes be preferable to immediate deletion.

Step 31: Decide whether to retain or delete the account

Once access has been disabled and dependencies reviewed, decide whether the WordPress account should remain in the database.

Retention can make sense when:

• historical attribution matters;
• plugin records depend on the user ID;
• audit history should remain readable;
• the account owns complex custom data;
• operational records require preservation.

Deletion can make sense when:

• the account is unnecessary;
• content has been safely reassigned;
• no integration depends on it;
• required records have been preserved;
• the site’s retention requirements allow deletion.

Disabled account vs. deleted account

The difference can be summarized as:

Disabled account

Authentication:
Blocked

User record:
Preserved

Historical relationships:
Preserved


Deleted account

Authentication:
Impossible

User record:
Removed

Historical relationships:
Must be handled during deletion

Neither approach is automatically correct for every site.

The decision depends on operational, security and data-retention requirements.

Step 32: Reassign content before deleting

If the account is going to be deleted, verify the reassignment target before proceeding.

WordPress’s wp_delete_user() accepts a second parameter representing the user ID that should receive reassigned posts and links.

Conceptually:

Departing user ID:
123

Replacement owner:
45

Delete user 123
↓
Reassign supported content to user 45

Do not execute destructive deletion code casually on a production installation. Confirm the content behavior of the site’s custom post types and plugins first.

Step 33: Back up before significant account deletion

For high-value sites, create or verify a recent backup before deleting an important account with substantial content ownership.

This is especially useful when:

• the account owns large amounts of content;
• custom post types are involved;
• plugins store user-linked data;
• the site uses custom user metadata;
• the deletion behavior has not been tested.

A backup is not a substitute for understanding the deletion process, but it provides a recovery path if something unexpected happens.

Step 34: Test account deletion on staging when risk is high

For complex sites, test the deletion and reassignment process in a staging environment first.

This lets you inspect:

• post ownership;
• custom post types;
• plugin data;
• user metadata;
• frontend attribution;
• broken relationships;
• unexpected deletions.

For teams already using a controlled deployment process, Building a Staging-First WordPress Update Workflow provides useful principles for validating changes before production.

Step 35: Understand WordPress Multisite before deleting users

WordPress Multisite changes the meaning of user removal.

A user can belong to several sites inside the same network.

Removing the account from one site is therefore not necessarily the same as deleting the network user.

WordPress provides remove_user_from_blog() for removing a user from a particular site in a Multisite network.

This distinction matters during offboarding because the required scope may be one site rather than the entire network.

Removing access from one Multisite site

Consider:

Network User
├── Site A: Administrator
├── Site B: Editor
└── Site C: Subscriber

If the person should lose access only to Site B, deleting the entire network user would be excessive.

The desired change is:

Site A: Keep
Site B: Remove
Site C: Keep

Multisite offboarding should therefore begin by determining the required scope.

Deleting a Multisite user is a much larger action

Network-level deletion can affect the user’s relationship with multiple sites.

Before deleting a Multisite user, review:

• every site membership;
• roles on each site;
• content ownership on each site;
• network-level responsibilities;
• integrations using the account.

Do not treat a network user as if it were an isolated single-site account.

Step 36: Review ownership outside standard WordPress authorship

Some plugins store ownership relationships in custom tables or metadata rather than post_author.

Examples might include:

• assigned support tickets;
• CRM contacts;
• project ownership;
• course instructors;
• sales representatives;
• workflow assignments;
• approval records.

WordPress cannot automatically understand every plugin’s business logic when a user is deleted.

Review important plugins individually.

Step 37: Review automation ownership

The departing account may be referenced in automation rules.

For example:

When form submitted
↓
Assign to User #123

When post reaches review
↓
Notify User #123

When product changes
↓
Email User #123

If User #123 disappears, those workflows may become incomplete or fail silently.

Search automation configuration for account-specific references before final deletion.

Step 38: Review custom code

Custom themes and plugins occasionally contain hardcoded user references.

Examples include:

if ( get_current_user_id() === 123 ) {
    // Special access.
}

or:

$notification_recipient = 123;

If the account was important to the site’s operation, search custom code and configuration for references to its user ID, username or email address.

Step 39: Review custom redirects

If login or logout behavior differs by role or user, verify that the departing account is not referenced in custom redirect logic.

For role-based behavior, see WordPress Login Redirects by Role, Explained.

TheOneWP also provides Redirect After Login and Redirect After Logout for managing navigation after authentication and logout.

Step 40: Review administrative UI restrictions

Some WordPress installations customize the backend for different roles.

A departing user may have belonged to a role with a specially configured admin interface.

Reviewing those rules is useful when:

• the role was created specifically for that person;
• the role will no longer be used;
• custom menu rules reference it;
• notification rules target it;
• dashboard configuration depends on it.

If the role itself has become obsolete, clean up the surrounding configuration after the account is removed.

Step 41: Do not remove a custom role before checking other users

If the departing user has a custom role, do not assume the role can also be deleted.

First determine whether other accounts use it.

A role such as:

regional_editor

may belong to one departing employee or many active users.

Custom WordPress Roles vs. Combining Existing Ones provides useful context when deciding whether a specialized role still belongs in the site’s permission model.

Step 42: Preserve audit history where necessary

Offboarding should not erase evidence of previous administrative actions when that history matters.

Useful records may include:

• content approvals;
• configuration changes;
• editorial comments;
• security events;
• login history;
• deployment activity;
• client approvals.

If a plugin’s audit history references a WordPress user ID, test what happens to those records when the account is deleted.

Step 43: Document why the account was disabled or removed

For business sites, a concise administrative record can prevent confusion later.

For example:

User:
jessica.example

User ID:
123

Access ended:
2026-09-17

Reason:
Contract completed

Sessions terminated:
Yes

Content reassigned:
Editorial Team

Account:
Deleted after review

Record only information that is operationally useful for understanding the access change.

Step 44: Verify that active sessions no longer work

After terminating sessions, verify the result rather than assuming the administrative action completed correctly.

From an existing session, test:

• refreshing the dashboard;
• opening another admin page;
• saving content;
• performing an authenticated AJAX action;
• making an authenticated API request.

The old authentication state should no longer provide access.

Step 45: Verify that new login attempts are blocked

If the account is being suspended rather than merely logged out, test the second half of the process too.

Existing session
→ Must fail

Fresh login
→ Must fail

Testing only one of those conditions leaves half the offboarding process unverified.

Step 46: Verify content after deletion or reassignment

After deleting an account, inspect representative content previously owned by that user.

Check:

• author attribution;
• frontend output;
• custom post types;
• media relationships;
• archives;
• structured data;
• plugin-specific ownership.

Do not assume successful account deletion proves successful content migration.

Step 47: Verify scheduled and draft content

Published pages are the obvious items to inspect, but drafts and scheduled posts can be easier to miss.

Confirm that unfinished content remains:

• accessible;
• assigned appropriately;
• scheduled correctly;
• visible to the responsible editors.

Step 48: Verify integrations after offboarding

After disabling or deleting the account, monitor important integrations.

Check whether:

• scheduled imports still run;
• API connections still authenticate;
• publishing integrations still work;
• forms still deliver notifications;
• automations still complete;
• external applications still communicate correctly.

If something breaks, move the integration to an appropriate operational account rather than indefinitely restoring access to the former user’s account.

Step 49: Review security controls after privileged departures

When a highly privileged user leaves, the event is a useful trigger for a broader security review.

Consider checking:

• administrator accounts;
• password policies;
• two-factor authentication;
• login-attempt protection;
• custom roles;
• application passwords;
• external integrations;
• hosting access;
• backup access.

A WordPress Login Hardening Checklist provides a broader framework for strengthening authentication after the immediate offboarding work is complete.

Step 50: Make offboarding repeatable

The safest offboarding process is a documented and repeatable procedure.

A simple operational template might be:

ACCOUNT

[ ] Confirm user identity
[ ] Confirm departure date
[ ] Block authentication
[ ] Destroy active sessions

ACCESS

[ ] Review roles
[ ] Review capabilities
[ ] Review Multisite membership
[ ] Review external systems
[ ] Review API credentials

CONTENT

[ ] Identify owned content
[ ] Reassign content
[ ] Review drafts
[ ] Review scheduled posts
[ ] Review custom post types

INTEGRATIONS

[ ] Review application passwords
[ ] Review automations
[ ] Review API integrations
[ ] Review email notifications

RETENTION

[ ] Preserve required history
[ ] Decide retain vs delete
[ ] Back up if necessary
[ ] Delete account if appropriate

VERIFICATION

[ ] Existing sessions fail
[ ] New login fails
[ ] Content remains correct
[ ] Integrations still work
[ ] Offboarding documented

Build offboarding into the user lifecycle

Offboarding becomes easier when access was designed properly during onboarding.

Compare these two environments:

Environment A

Everyone is Administrator
Shared passwords
Personal accounts run integrations
No expiration policy
No login history

Environment B

Least-privilege roles
Individual accounts
Dedicated integration users
Temporary access is reviewed
Sessions can be terminated
Login activity is visible

The second environment requires considerably less investigation when somebody leaves.

Use least privilege from the beginning

An account should receive only the permissions necessary for its responsibilities.

If a copywriter only needs to edit articles, giving that person full Administrator access makes both normal operation and eventual offboarding riskier.

TheOneWP’s Role Manager can help maintain more appropriate permission structures instead of relying entirely on WordPress’s default roles.

Understand custom roles before offboarding

Custom roles can make access more precise, but they also need to be understood during offboarding.

A role name is only a label. The important part is the collection of capabilities assigned to it.

For example:

Client Editor

edit_pages
edit_posts
upload_files
custom_project_access

When a user leaves, inspect the role itself as well as the account.

Custom WordPress Roles vs. Combining Existing Ones provides more context for deciding how specialized access should be structured.

Avoid shared WordPress accounts

A shared account such as:

Username:
marketing

Password:
shared by six people

makes offboarding significantly harder.

If one person leaves, you cannot simply disable their account because other people are using the same identity.

You also lose reliable attribution:

Who changed this page?
→ marketing

Who approved this post?
→ marketing

Who changed this setting?
→ marketing

Individual accounts make access revocation, auditing and accountability much cleaner.

Do not use one administrator account for an entire external team

The same principle applies to agencies and external collaborators.

Instead of:

agency_admin
shared by:
developer
designer
SEO specialist
account manager

prefer individual accounts with appropriate permissions.

When one collaborator leaves the project, their access can then be removed without changing credentials for everybody else.

Plan temporary access before it becomes permanent

If an account is known to be temporary, define its expected lifetime when it is created.

This is particularly useful for:

• support technicians;
• temporary developers;
• campaign collaborators;
• auditors;
• freelancers;
• client reviewers.

Even if the site does not automatically expire the account, recording an expected review or end date makes future offboarding considerably more reliable.

Use login information during periodic access reviews

Offboarding should not depend exclusively on someone formally telling the WordPress administrator that a person has left.

Periodic reviews can identify:

Accounts unused for 12 months
Unknown administrators
Expired contractors
Old agency accounts
Unused client accounts
Test users left in production

TheOneWP’s Last Login module can add useful context to those reviews.

Do not wait for an incident to clean up users

An abandoned Administrator account retains its permissions regardless of how long it has been unused.

Old accounts increase the number of credentials and identities that need to remain secure.

Regularly combine offboarding with the process described in Auditing Dormant WordPress User Accounts.

How TheOneWP can support account offboarding

A reliable WordPress offboarding process involves several separate controls rather than one universal account-removal action.

TheOneWP can support different parts of that lifecycle:

• Block User Login can prevent selected accounts from authenticating again.
• Last Login can provide account-activity context during access reviews.
• Role Manager can help administrators maintain deliberate role and capability structures.
• Multi-Role Assignment matters when users hold several roles that need to be reviewed together.
• Two-Factor Authentication can strengthen accounts while they remain active.

The important principle is that authentication, active sessions, authorization, content ownership and account retention are separate concerns.

A strong offboarding workflow addresses each one deliberately.

WordPress account offboarding checklist

• Confirm the exact user account.
• Record the user ID and username.
• Determine whether offboarding is routine or security-sensitive.
• Prevent future authentication.
• Terminate active WordPress sessions.
• Verify existing sessions no longer work.
• Verify fresh authentication is blocked when required.
• Review the user’s roles.
• Review multiple role assignments.
• Review direct and custom capabilities.
• Review Multisite memberships.
• Identify all owned posts and pages.
• Identify owned custom post type content.
• Review drafts.
• Review scheduled content.
• Choose a new content owner.
• Reassign content before deletion.
• Review user metadata.
• Review editorial notes and workflow history.
• Review application passwords.
• Review REST API integrations.
• Review external applications.
• Review automation rules.
• Review custom code for account-specific references.
• Review notification recipients.
• Review the WordPress administration email.
• Review hosting access.
• Review SFTP or SSH access.
• Review database access.
• Review CDN and DNS access.
• Review analytics and search tools.
• Review Git and deployment access.
• Review backup storage access.
• Rotate shared credentials where necessary.
• Review newly created privileged accounts if security is a concern.
• Review recent login activity.
• Review dormant accounts.
• Preserve required audit history.
• Decide whether the account should be disabled or deleted.
• Back up before high-risk deletion.
• Test complex deletion behavior on staging.
• Verify content after reassignment.
• Verify custom post types after reassignment.
• Verify scheduled content.
• Verify integrations after account changes.
• Document the completed offboarding process.

Related guides

• How to Force Logout a WordPress User Immediately
• Auditing Dormant WordPress User Accounts
• How to Audit User Roles on a WordPress Site
• WordPress User Roles and Capabilities, Explained
• A WordPress Login Hardening Checklist

Final recommendation

A WordPress account should not be deleted simply because somebody no longer works on the site. Start by removing access, then determine what should happen to the data and responsibilities associated with the account.

First, prevent future authentication and terminate any existing sessions. If immediate removal is required, follow How to Force Logout a WordPress User Immediately so already authenticated browsers do not remain trusted after the access decision has been made.

Next, review the user’s complete authorization state. Roles are only part of the picture. Custom capabilities, multiple roles, Multisite memberships and plugin-specific permissions can all affect what an account can access. How to Audit User Roles on a WordPress Site is a useful companion process for privileged accounts.

Do not delete the user until content ownership has been reviewed. Posts, pages and custom post types may need reassignment, while plugins may store additional relationships through user metadata or custom tables. For important production sites, verify the behavior on staging before deleting an account with substantial ownership.

Review authentication paths beyond the ordinary login form as well. Application passwords, API integrations, automations and external systems can remain dependent on a personal account even after nobody uses that account interactively. Business-critical integrations should generally be moved to dedicated, narrowly privileged identities rather than kept alive through a former employee’s account.

For accounts that should remain historically intact, disabling authentication can be preferable to deletion. TheOneWP’s Block User Login can preserve the WordPress user record while preventing future authentication, while Last Login can provide additional context during access reviews.

Account lifecycle management should also begin before somebody leaves. Use individual accounts, least-privilege permissions and clearly defined access periods for temporary collaborators. TheOneWP’s Role Manager and Multi-Role Assignment can help maintain clearer permission structures while accounts remain active.

Finally, treat offboarding as a repeatable security process rather than an occasional cleanup task. Individual accounts, explicit session termination, controlled content reassignment, authentication blocking and periodic reviews of dormant users make departures predictable and reduce the number of forgotten identities that remain capable of accessing WordPress long after their original purpose has disappeared.