Auditing dormant WordPress user accounts

Dormant WordPress user accounts are accounts that still exist but appear to be no longer actively used. They may belong to former employees, old contractors, previous agency partners, customers who no longer need access, abandoned test accounts or administrators who were created for a project that ended years ago.

Leaving these accounts untouched can quietly increase the number of identities capable of accessing a WordPress installation.

The problem is not simply that an old account exists. The real questions are:

• Does the person still need access?
• When was the account last used?
• What role and capabilities does it still have?
• Does it own posts, media, orders or other important data?
• Does it still have active WordPress sessions?
• Does it have Application Passwords or other programmatic credentials?
• Should access be reduced, suspended or permanently removed?

A good dormant-account audit answers these questions before taking destructive action.

This guide explains how to audit dormant WordPress user accounts safely, how WordPress stores account information, why registration date and last login are different signals, how to prioritize privileged users and how to remove unnecessary access without accidentally destroying valuable site history.

What is a dormant WordPress user account?

There is no universal WordPress definition of a dormant account.

WordPress Core does not automatically classify users as:

active
inactive
dormant
expired

A dormant account is therefore an operational classification that you define according to your own site’s access policy.

A simple definition

You might define a dormant account as:

a user that has not logged in
for 180 days

Another organization might use:

90 days

while a membership website might consider:

365 days

completely normal.

There is no single inactivity threshold that is correct for every WordPress site.

Context matters more than the raw number

Consider these two users:

User A
Role: Administrator
Last login: 8 months ago

User B
Role: Subscriber
Last login: 14 months ago

User A may deserve more urgent attention even though User B has been inactive for longer.

That is because the consequence of compromised administrator credentials is considerably greater.

Why dormant WordPress accounts matter

Every account that can authenticate represents another identity whose credentials must remain secure.

An account that nobody remembers may still have:

• a valid password;
• administrative privileges;
• an active session;
• Application Passwords;
• access to private content;
• permissions added by plugins;
• WooCommerce or membership privileges.

If the legitimate owner no longer monitors the account, suspicious activity may also be less likely to be noticed.

Dormant accounts conflict with least privilege

The principle of least privilege says that users should have only the access required for their current responsibilities.

If somebody no longer works on the site, then:

required privileges
=
none

Leaving that user as an Administrator indefinitely does not fit that principle.

Account-management guidance from organizations such as OWASP similarly recommends establishing an acceptable inactivity period and disabling or removing identities that no longer require access.

Start by inventorying every WordPress user

Before deciding which users are dormant, understand what accounts actually exist.

Go to:

Users
→
All Users

and review the account list.

Record the useful fields

For each account, useful information includes:

• username;
• display name;
• email address;
• role;
• registration date;
• last successful login, if recorded;
• content ownership;
• whether the person still belongs to the organization;
• whether the account is human or programmatic.

Do not begin the audit by deleting obviously unfamiliar names.

First determine what they are.

Pay particular attention to privileged roles

Start with accounts that can make consequential changes.

Common WordPress roles include:

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

Plugins can introduce additional roles, and individual accounts can sometimes receive additional capabilities outside the expected role model.

For a deeper review of the permission system, read WordPress user roles and capabilities, explained and How to audit user roles on a WordPress site.

Registration date is useful, but it is not activity

WordPress stores the time at which an account was created in the user_registered field.

For example:

2024-04-16 09:32:17

The field is useful because it tells you the age of the account.

It does not tell you whether the account is still being used.

An old registration date does not mean dormancy

An administrator may have been registered six years ago and still log in every morning.

Conversely, an account created two months ago may have been used only once.

Therefore:

registration date
≠
last activity

Use registration date as supporting evidence

It becomes especially useful when combined with other signals:

registered 4 years ago
+
never logged in recently
+
old contractor email
+
Administrator role

That combination deserves investigation.

TheOneWP Registration Date exposes WordPress’s native registration date in a sortable Users-table column, making old or unusually recent account creation patterns easier to inspect.

WordPress does not track last login by default

This is one of the most important facts in a dormant-account audit.

Standard WordPress does not maintain a native database field equivalent to:

last_login

You therefore cannot install a fresh tracking solution today and reconstruct every historical login from five years ago.

What WordPress does provide

WordPress fires the:

wp_login

action after a user has successfully authenticated.

The official wp_login hook documentation confirms that it fires after a successful login.

A plugin or custom implementation can listen to that event and store a timestamp in user metadata.

A simple last-login implementation

Conceptually:

function mysite_record_last_login(
    $user_login,
    $user
) {
    update_user_meta(
        $user->ID,
        'mysite_last_login',
        time()
    );
}

add_action(
    'wp_login',
    'mysite_record_last_login',
    10,
    2
);

The timestamp then becomes available for future audits.

This is a typical example of using WordPress user metadata, which is explained in more depth in WordPress user meta, explained.

Use Last Login data carefully

A last-login timestamp is valuable, but it is not absolute proof that an account is unnecessary.

No recorded login may mean several things

If a system displays:

Never

that can mean:

• the account really has never authenticated;
• the account was created before login tracking began;
• login tracking was temporarily disabled;
• a previous plugin stored activity under another field;
• the account is used through another authentication mechanism.

You need to understand when tracking began before interpreting historical results.

Last login is stronger for future audits

If you enable tracking on January 1 and an account still shows no successful login twelve months later, that information is much more meaningful than installing the tracker today and immediately labelling every account without metadata as dormant.

Using TheOneWP Last Login

TheOneWP Last Login records each successful user login and adds a sortable Last Login column to the WordPress Users screen.

The recorded timestamp updates from WordPress’s successful-login event rather than failed authentication attempts.

This distinction matters:

failed password attempt
≠
successful user activity

A useful audit view

Combining:

Registration Date
+
Last Login
+
Role

provides a practical starting point for account review.

You can quickly identify cases such as:

Administrator
Registered: 2022
Last Login: 2024

or:

Subscriber
Registered: 2026
Last Login: Never

Those two cases should not necessarily receive the same response.

Define an inactivity policy before changing accounts

Do not decide account-by-account with no consistent rule.

Create a simple policy.

Example policy

A business WordPress site might define:

Administrators:
review after 90 days inactivity

Editors / Authors:
review after 180 days inactivity

Subscribers:
review after 365 days inactivity

These numbers are examples, not universal security requirements.

Your own thresholds should reflect:

• how frequently users legitimately need access;
• the sensitivity of the site;
• role privilege;
• contractor turnover;
• regulatory or internal requirements;
• the ease with which access can later be restored.

Review is not the same as automatic deletion

A sensible policy says:

90 days
→
review account

rather than:

90 days
→
delete account automatically

Human review is especially important for privileged or content-owning accounts.

Classify users before taking action

A useful dormant-account audit can divide users into several categories.

Active and required

The user still works with the site and has appropriate access.

Action:

keep

Active but overprivileged

The person still needs an account but no longer requires their current role.

Example:

former developer
Administrator
now only writes articles

Action:

reduce privileges

Temporarily inactive

The person may need access again but should not currently authenticate.

Action:

suspend login

No longer required

The person has left the company or finished the project.

Action:

remove access
then decide whether
the user record should remain

Unknown account

Nobody recognizes the account.

Action:

investigate immediately

Unknown does not automatically mean malicious, but privileged unknown accounts should be treated seriously.

Audit administrators first

A large user database may contain thousands of Subscribers and only five Administrators.

Start with the five Administrators.

Ask these questions

• Who is this person?
• Do they still work with the organization?
• Why do they need Administrator access?
• When did they last log in?
• Is their email address still controlled?
• Do they need all current capabilities?
• Do they have active sessions?
• Do they have Application Passwords?
• Is two-factor authentication enabled?

A dormant Administrator should generally receive more attention than a dormant Subscriber because the possible impact of unauthorized use is much larger.

Review roles and actual capabilities

Do not assume a role label tells the entire story.

WordPress permissions are based on capabilities.

The role is primarily a convenient collection of those capabilities.

For example:

Administrator
↓
manage_options
edit_users
install_plugins
...

Plugins can introduce their own capabilities and custom roles.

Look for unnecessary privilege

A dormant account becomes particularly concerning when it still possesses capabilities that allow it to:

• manage plugins;
• edit users;
• change configuration;
• publish content;
• manage orders;
• access private customer information.

Use TheOneWP Role Manager when you need a clearer view of how roles and capabilities are configured.

Check whether the user owns content

Deleting a WordPress user is not equivalent to disabling a login.

A user may own:

• posts;
• pages;
• custom post types;
• media-related content;
• plugin-specific records;
• WooCommerce or membership data.

Content ownership matters

Suppose:

Jane Smith
Role: Editor
Posts authored: 620
Employment status: left company

The correct security objective may be:

Jane cannot log in anymore

not:

erase Jane from every historical record

Deletion can require reassignment

When deleting a WordPress user, WordPress may offer options to delete their content or attribute it to another user.

Choose deliberately.

Do not turn an access-control cleanup into an accidental content purge.

Suspending access is often safer than immediate deletion

There are many situations where preserving the user record is desirable while removing authentication access.

Examples include:

• employees on extended leave;
• contractors whose project has paused;
• former staff whose authored content should remain attributed;
• accounts awaiting internal confirmation;
• temporary compliance holds.

Block login without deleting the account

TheOneWP Block User Login can block selected accounts or roles from authenticating while leaving their user records intact.

This creates a useful middle state:

account exists
+
historical data preserved
+
login denied

The module can also end active sessions for blocked users, preventing an already authenticated session from simply continuing indefinitely.

Do not forget existing sessions

Blocking future authentication does not automatically answer the question:

is the user already logged in?

WordPress manages logged-in sessions through session tokens.

A user can have multiple sessions representing different browsers or devices.

WordPress can invalidate sessions

WordPress provides session-management APIs, and WP-CLI can list and destroy sessions.

For example:

wp user session list username

and:

wp user session destroy username --all

The official WP-CLI user session documentation describes these commands.

Why this matters during offboarding

If somebody leaves the organization at 10:00 and their password is changed at 10:05, you should not assume every existing browser session has automatically disappeared unless the chosen access-control process actually invalidates it.

For high-privilege accounts, active sessions should be part of the audit.

Audit Application Passwords too

A WordPress account can have more than one type of credential.

Application Passwords provide revocable credentials for programmatic access to WordPress APIs.

They are not used for normal interactive login through wp-login.php.

They can still provide authenticated programmatic access as the associated user.

A dormant human account may still support an active integration

Imagine:

User:
old-agency@example.com

Normal login:
unused for 18 months

Application Password:
still used by publishing automation

Blindly deleting the account may break that integration.

Conversely, leaving the forgotten Application Password forever is not a good lifecycle strategy either.

Review credentials individually

WordPress exposes Application Password management on the user profile, including information about existing credentials and their usage.

The official WordPress Application Passwords documentation recommends revoking credentials that are no longer required and creating separate credentials for separate integrations.

During an audit, determine:

• what each Application Password is for;
• whether the integration still exists;
• whether it should belong to a dedicated service account instead;
• when the credential was last used;
• whether it should be revoked or rotated.

Separate human and service accounts

Not every WordPress user represents a person.

Some accounts may exist for:

• API integrations;
• content importers;
• automation tools;
• mobile applications;
• publishing systems.

A service account can appear dormant from browser-login data

If it never uses the normal login form, its recorded interactive last login may be:

Never

while the account is still actively used through an API.

This is one reason last-login data should not be the only signal.

Document service accounts clearly

Ideally you should know:

• what system owns the account;
• which capabilities it needs;
• who is responsible for it;
• which credentials it uses;
• when it should expire;
• how access can be rotated safely.

Look for abandoned contractor and agency accounts

External collaborators are a common source of dormant WordPress users.

A site may have passed through:

Agency A
↓
freelancer
↓
Agency B
↓
internal developer

and every transition may have left another Administrator behind.

Compare users against current relationships

Look for email domains belonging to:

• former web agencies;
• old marketing companies;
• freelancers;
• previous hosting providers;
• former employees.

Ask whether those relationships still exist.

Do not keep emergency access forever

A temporary Administrator created for a one-week support task should not quietly become a permanent identity.

Temporary access should have an explicit end-of-life process.

Check accounts that have never logged in

Accounts showing no recorded successful login deserve their own review.

They may represent:

• unused invitations;
• abandoned customer registrations;
• spam signups;
• automatically provisioned users;
• accounts created before login tracking began.

Combine registration date and login data

For example:

Registered:
2 years ago

Last Login:
Never

Role:
Administrator

is a very different case from:

Registered:
yesterday

Last Login:
Never

Role:
Subscriber

The second may simply be a new user who has not yet returned.

Watch for spam patterns

If you find many accounts with:

• similar usernames;
• random email addresses;
• registration timestamps seconds apart;
• no successful login;

you may be looking at automated registration rather than ordinary dormancy.

See Detecting spam registrations on WordPress for the dedicated audit process.

Use WP_User_Query for custom audits

Developers can build more detailed account reports with WP_User_Query.

The official WP_User_Query documentation supports filtering and ordering users by fields such as:

• role;
• registration date;
• user metadata;
• email;
• login;
• post count.

Find users by role

$users = new WP_User_Query(
    array(
        'role' => 'administrator',
    )
);

Order by registration date

$users = new WP_User_Query(
    array(
        'orderby' => 'registered',
        'order'   => 'ASC',
    )
);

Query custom last-login metadata

If your site stores a numeric timestamp such as:

mysite_last_login

you can use user-meta query parameters to build custom inactivity reports.

Do not copy a metadata key from an unrelated plugin and assume your own site uses the same field. Confirm the actual implementation first.

WP-CLI is useful on large user databases

For large WordPress installations, WP-CLI can be considerably faster than clicking through hundreds of Users pages.

List users

wp user list

Default output can include fields such as:

• ID;
• user_login;
• display_name;
• user_email;
• user_registered;
• roles.

List administrators

wp user list \
    --role=administrator

Export useful fields as CSV

wp user list \
    --fields=ID,user_login,user_email,user_registered,roles \
    --format=csv

You can then compare the exported inventory against employee, contractor or customer records.

The official WP-CLI user list documentation documents the supported fields and filtering options.

Build a risk-based audit score

On larger sites it can help to rank accounts rather than treating them all equally.

A simple conceptual model could be:

Risk =
privilege
+
inactivity
+
uncertain ownership
+
credential exposure

Higher-risk example

Administrator
Last login: 18 months ago
Former contractor
Unknown Application Password
Active session exists

Lower-risk example

Subscriber
Last login: 14 months ago
Known customer
No elevated capabilities
No programmatic credentials

The first account deserves immediate investigation.

The second may simply fall under normal retention policy.

Choose the right response for each dormant account

After investigation, there are several possible actions.

Keep the account unchanged

Use when the account remains legitimate and properly privileged.

Reduce its role

Use when the user still needs access but has more privileges than necessary.

Block login temporarily

Use when access should stop but the account and its historical relationships should remain intact.

Invalidate active sessions

Use when current authentication sessions should end immediately.

Revoke Application Passwords

Use when old integrations should no longer authenticate.

Enable stronger authentication

For retained privileged accounts, additional authentication controls can reduce account-takeover risk.

TheOneWP Two-Factor Authentication can add a second authentication factor for accounts that should remain active.

Delete the account

Use only after determining:

• the account is no longer needed;
• content ownership has been addressed;
• plugin-specific relationships have been reviewed;
• service integrations will not break;
• organizational retention requirements permit deletion.

Do not confuse inactivity with compromise

An old account is not automatically a compromised account.

Likewise, a frequently used account is not automatically safe.

Dormancy is one risk signal.

Look for unexpected recent activity

An especially important case is:

account believed to be abandoned
+
recent successful login

If a former employee’s account suddenly logged in yesterday, the situation is no longer a normal inactivity review.

Investigate:

• whether the login was expected;
• active sessions;
• changes made by the account;
• password reset activity;
• application credentials;
• access logs where available.

For broader account protection, use A WordPress login hardening checklist.

Create a repeatable dormant-account audit process

An audit should not be a one-time cleanup performed after somebody notices seventeen Administrators whose names nobody recognizes.

Make it periodic.

Step 1: inventory users

Export or review all users.

Step 2: prioritize privileged roles

Review Administrators and other high-capability users first.

Step 3: compare registration and last-login information

Look for old accounts with little or no recent activity.

Step 4: verify account ownership

Confirm that each account belongs to a current person, team or documented integration.

Step 5: inspect actual permissions

Check roles and capabilities, not just usernames.

Step 6: check content ownership

Determine what would happen if the user were removed.

Step 7: inspect sessions and programmatic credentials

Review existing login sessions and Application Passwords.

Step 8: classify the account

Mark it as:

retain
reduce
suspend
remove
investigate

Step 9: apply the action

Use the least destructive option that achieves the access-control goal.

Step 10: document the decision

Record why the account was retained, changed or removed.

Step 11: repeat on a schedule

Depending on the site, that might be:

monthly
quarterly
twice yearly

Privileged business systems usually benefit from more frequent review than small personal sites.

A practical WordPress dormant-account checklist

• List every WordPress user.
• Identify every Administrator.
• Identify custom privileged roles.
• Confirm who owns each privileged account.
• Review the email address associated with each account.
• Check whether that person still needs access.
• Review the account’s registration date.
• Review its last successful login where tracking exists.
• Document when last-login tracking was first enabled.
• Do not treat missing historical login data as proof of inactivity.
• Review each user’s role.
• Inspect actual capabilities when needed.
• Look for excessive privileges.
• Review accounts belonging to former employees.
• Review former contractor and agency accounts.
• Review unused temporary Administrator accounts.
• Identify human accounts versus service accounts.
• Review user-owned posts and content.
• Check plugin-specific data relationships before deletion.
• Review active WordPress sessions.
• Invalidate sessions when access is revoked.
• Review Application Passwords.
• Revoke unused Application Passwords.
• Investigate unexpected recent logins on supposedly dormant accounts.
• Look for never-used accounts.
• Look for automated or spam registration patterns.
• Reduce roles when full removal is unnecessary.
• Suspend login when preserving the account is useful.
• Require stronger authentication for retained privileged users.
• Delete only after content and integration dependencies have been reviewed.
• Document account-management decisions.
• Define an organization-specific inactivity threshold.
• Repeat the audit periodically.

Using TheOneWP for a dormant-account workflow

Several TheOneWP modules can support different parts of the audit rather than treating dormant-user management as a single toggle.

Registration Date

Registration Date exposes the account creation date already stored by WordPress and makes it sortable from the Users screen.

Last Login

Last Login records successful authentication activity and adds a sortable Last Login column.

Role Manager

Role Manager helps inspect and manage the role structure surrounding those users.

Block User Login

Block User Login provides a non-destructive option when you want to preserve a user while removing authentication access.

Two-Factor Authentication

Two-Factor Authentication strengthens accounts that pass the audit and should remain privileged.

Together, the workflow becomes:

identify
↓
measure
↓
understand permissions
↓
reduce or suspend
↓
protect retained accounts

Related WordPress access guides

Continue with these related guides:

• WordPress user roles and capabilities, explained
• How to audit user roles on a WordPress site
• WordPress user meta, explained
• A WordPress login hardening checklist
• Detecting spam registrations on WordPress
• How to target WordPress users by role
• How to limit login attempts in WordPress
• WordPress login hooks explained

Final thoughts

Auditing dormant WordPress user accounts is not simply a search for the oldest usernames in the database.

A useful audit combines several signals:

registration date
+
last successful login
+
role
+
capabilities
+
account ownership
+
content ownership
+
active sessions
+
programmatic credentials

The most important distinction is between:

removing access

and:

deleting the user record

Those are not the same operation.

If an old account still owns content or historical activity, suspending authentication may be safer than immediate deletion.

If a person still needs the account but no longer requires administrative power, reducing privileges may be the correct response.

If an account is unknown, privileged and unexpectedly active, the situation deserves investigation rather than routine cleanup.

WordPress Core gives you useful account information such as registration dates, roles, capabilities and sessions, but it does not natively maintain a historical last-login field. Start recording successful login activity before you need it, define an inactivity policy appropriate to your organization and review privileged users regularly.

A smaller, better understood user list is easier to secure than years of accumulated accounts whose owners, permissions and purpose have been forgotten.