How to Block a WordPress User from Logging in

Blocking a WordPress user from logging in is useful when an account needs to remain in the database but should temporarily or permanently lose authentication access.

This is different from deleting the user.

It is also different from changing the user’s role.

A blocked account can still exist with:

• its user ID;
• profile information;
• content authorship;
• metadata;
• historical references;
• role assignments.

while interactive authentication is denied.

The resulting state is:

WordPress user exists
+
historical data remains
+
login access denied

This can be useful for:

• former employees;
• contractors whose access is suspended;
• temporarily disabled customer accounts;
• accounts under security investigation;
• dormant administrators awaiting review;
• seasonal or temporary staff;
• accounts that should retain content ownership but no longer need login access.

WordPress does not provide a standard Core “Blocked” switch on every user account, but its authentication hooks make this behavior straightforward to implement without deleting the user or modifying WordPress Core.

This guide explains how to block a WordPress user from logging in, how to store the blocked state, how to intercept authentication safely, how to terminate existing sessions, how role-wide blocking differs from individual blocking and why Application Passwords and other authentication paths need separate consideration.

Quick answer: how do you block a WordPress user from logging in?

A clean WordPress implementation can:

1. Store a blocked flag
   in user metadata

2. Check the flag during
   authentication

3. Return WP_Error
   when the user is blocked

4. Destroy existing sessions

5. Remove the flag
   when access is restored

For example:

User ID 42

project_login_blocked = 1

↓
credentials are correct
↓
WordPress authentication hook runs
↓
blocked flag detected
↓
authentication rejected

This preserves the account while preventing new interactive login sessions.

TheOneWP Block User Login provides this type of account suspension without requiring the administrator to delete the user.

Blocking a user is not the same as deleting a user

Deleting a WordPress user changes the account lifecycle permanently.

Depending on the deletion process, you may also need to decide what happens to:

• posts;
• pages;
• custom post types;
• comments;
• metadata;
• content attribution;
• plugin relationships.

The official wp_delete_user() documentation shows that WordPress can reassign content during user deletion.

Blocking login is intentionally less destructive.

Delete user
→ account removed

Block login
→ account preserved
→ authentication denied

When should you block instead of delete?

Blocking is particularly useful when the account may still matter historically or operationally.

For example:

Former editor
↓
owns 1,200 posts
↓
should no longer log in
↓
content attribution
should remain intact

Deleting the account may be unnecessary if the real requirement is simply:

stop authentication

For a broader account lifecycle review, see Auditing Dormant WordPress User Accounts.

Blocking login is not the same as changing the role

A WordPress role controls capabilities.

The official WordPress Roles and Capabilities documentation explains that roles define collections of permissions such as:

edit_posts
publish_posts
manage_options
install_plugins

If you change an Administrator to Subscriber, the user can normally still authenticate.

They simply have fewer capabilities after login.

The distinction is:

Role
→ what the authenticated user may do

Login block
→ whether the user may authenticate

For the complete permission model, see WordPress User Roles and Capabilities, Explained.

Do not use role reduction when the real requirement is suspension

Imagine a contractor currently has the Editor role.

You could change them to Subscriber.

But they would still have:

valid account
+
valid password
+
ability to log in

If access should be completely suspended, an explicit login block communicates the policy much more accurately.

Store the blocked state in user metadata

WordPress provides a metadata system specifically for information associated with user accounts.

The official WordPress User Metadata documentation provides APIs including:

get_user_meta()
update_user_meta()
delete_user_meta()

A simple blocked state could use:

project_login_blocked

with:

1
→ blocked

missing value
→ normal access

Block a user with update_user_meta()

For example:

update_user_meta(
    $user_id,
    'project_login_blocked',
    '1'
);

The official update_user_meta() documentation explains how user metadata is created or updated.

Check whether a user is blocked

function project_user_login_is_blocked(
    $user_id
) {

    return '1' === get_user_meta(
        $user_id,
        'project_login_blocked',
        true
    );
}

The official get_user_meta() documentation covers retrieval of stored account metadata.

Unblock the user by removing the flag

When access should return:

delete_user_meta(
    $user_id,
    'project_login_blocked'
);

This produces a straightforward state model:

metadata exists
→ account suspended

metadata absent
→ normal authentication policy

For a broader explanation of user metadata, see WordPress User Meta, Explained.

Where should WordPress login blocking happen?

The goal is not merely to hide the login form.

The goal is to reject authentication for a particular user.

That means the check belongs in the authentication lifecycle.

WordPress exposes several related hooks.

Two important ones are:

authenticate

wp_authenticate_user

The authenticate filter

The official authenticate documentation describes a filter that receives:

$user
$username
$password

and can return:

WP_User
WP_Error
null

This filter is part of WordPress’s standard credential authentication pipeline.

The wp_authenticate_user filter

For account blocking, an especially useful hook is:

wp_authenticate_user

The official wp_authenticate_user documentation explains that it allows additional validation after WordPress’s basic user validation but before the user is logged in.

The callback receives:

WP_User or WP_Error
+
submitted password

If the account should not authenticate, the callback can return:

WP_Error

Block one WordPress user during authentication

A simple implementation can look like:

add_filter(
    'wp_authenticate_user',
    'project_block_user_login',
    20,
    2
);

function project_block_user_login(
    $user,
    $password
) {

    if ( is_wp_error( $user ) ) {
        return $user;
    }

    if (
        ! $user instanceof WP_User
    ) {
        return $user;
    }

    if (
        project_user_login_is_blocked(
            $user->ID
        )
    ) {
        return new WP_Error(
            'account_login_blocked',
            __(
                'This account is not currently allowed to sign in.',
                'project'
            )
        );
    }

    return $user;
}

The account still exists.

The password has not been deleted.

The role remains unchanged.

Authentication is simply rejected while the stored block state is active.

Do not use the submitted password

The wp_authenticate_user filter receives the password because it is part of the authentication process.

Your blocked-user check does not need it.

Never:

• save it;
• log it;
• send it to an external service;
• store it in metadata;
• include it in an audit record.

The password should remain completely irrelevant to the block decision.

Why check after WordPress resolves the user?

At this stage, your code has an actual:

WP_User

object.

You can therefore check:

$user->ID

instead of attempting to manually determine whether the submitted string represents:

• a username;
• an email address;
• a valid account;
• a nonexistent identity.

WordPress handles that earlier part of the authentication process.

Do not create a parallel authentication system unnecessarily

A poor implementation might manually query:

wp_users

using the submitted login value and then try to reproduce WordPress’s authentication logic.

That creates unnecessary complexity.

Use WordPress’s existing authentication pipeline and add the extra account-state rule at the appropriate hook.

Blocked login vs incorrect credentials

An implementation needs to decide what blocked users should see.

Possible responses include:

Login failed.

Account access suspended.

This account is not currently
allowed to sign in.

There is no one message appropriate for every website.

Consider account enumeration

A highly specific error can reveal that:

the account exists
+
the account is blocked

to an unauthenticated visitor.

For public login forms, a generic response may be more appropriate.

For internal systems where users already know their account status, an explicit suspension message may provide better usability.

For the broader issue of authentication responses, see WordPress Login Error Messages Explained.

Blocking future logins is only half the problem

Suppose an administrator blocks a user at:

14:00

but the user logged in earlier at:

09:00

The user’s browser may already hold a valid WordPress authentication session.

A filter that rejects future logins does not automatically answer:

What happens to the
existing session?

WordPress sessions are represented by session tokens

WordPress provides the:

WP_Session_Tokens

API for user session management.

The official WP_Session_Tokens documentation describes creation, retrieval and destruction of WordPress session tokens.

Destroy all active sessions for the blocked user

You can invalidate every normal WordPress session for one account:

function project_destroy_user_sessions(
    $user_id
) {

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

    $sessions->destroy_all();
}

The official destroy_all() documentation confirms that the method destroys all sessions for the selected user.

Block and invalidate sessions together

A stronger account-suspension function can therefore be:

function project_block_user(
    $user_id
) {

    $user_id = absint(
        $user_id
    );

    if ( ! $user_id ) {
        return false;
    }

    update_user_meta(
        $user_id,
        'project_login_blocked',
        '1'
    );

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

    $sessions->destroy_all();

    return true;
}

Now the workflow becomes:

mark account blocked
↓
destroy browser sessions
↓
future interactive login denied

Destroying sessions is important during offboarding

If an employee or contractor loses access, you normally do not want an old browser tab to remain authenticated merely because the person has not logged in again.

The sequence should be closer to:

revoke access
↓
invalidate active sessions
↓
review other credentials

rather than:

prevent next login
↓
ignore existing sessions

wp_logout() is not the same as destroying another user’s sessions

The WordPress:

wp_logout()

function logs out the current user.

The official wp_logout() documentation shows that it destroys the current session, clears authentication cookies and resets the current user.

That is useful when the blocked person is currently executing a request.

For an administrator blocking another user, the session-token API is the more direct way to invalidate that other user’s sessions.

TheOneWP ends active blocked-user access too

TheOneWP Block User Login does not treat account blocking as only a future-login rule.

When a blocked user already has an active normal WordPress session, the module checks that account during regular page requests, signs the blocked user out and redirects them to the configured destination.

This prevents a previously authenticated browser session from continuing indefinitely after the user becomes blocked.

TheOneWP can block an individual account

An administrator can block one specific user without affecting every other account with the same role.

For example:

Editor A
→ normal access

Editor B
→ blocked

Editor C
→ normal access

This is useful when the restriction concerns the person or account rather than the permission profile.

TheOneWP can also block complete roles

The module can apply login blocking to selected WordPress roles.

For example:

Administrator
→ allowed

Editor
→ blocked

Author
→ blocked

Subscriber
→ allowed

Every user assigned to a blocked role is treated as blocked while the role rule remains active.

Role-wide blocking is much broader

Blocking one user affects:

one account

while blocking a role can affect:

dozens
hundreds
or
thousands of accounts

Review the role membership before applying a role-wide rule.

See How to Target WordPress Users by Role for the broader role-selection concept.

Custom WordPress roles need consideration too

Many plugins register additional roles such as:

Shop Manager
SEO Manager
Course Instructor
Vendor
Support Agent

A role-aware login block should use the roles actually registered on the site rather than hardcoding only the default WordPress roles.

TheOneWP Role Manager can help inspect and maintain those role definitions.

For the architectural choice between custom roles and combinations of existing permissions, see Custom WordPress Roles vs. Combining Existing Ones.

Be extremely careful when blocking Administrator

A role-wide rule for:

Administrator

can include the account configuring the feature.

A self-protection rule on an individual user-edit screen does not automatically protect you from a role-wide configuration that includes your own role.

Before applying broad authentication rules, maintain an alternative recovery method.

Keep a recovery path

For sensitive access changes, maintain at least one alternative such as:

• hosting panel access;
• SSH;
• SFTP;
• database administration;
• WP-CLI;
• another trusted administrator;
• a staging test environment.

Do not experiment with global Administrator blocking on the only production account you can use to reverse the setting. Humanity has already generated enough support tickets that way.

Do not let users block themselves accidentally

An individual block-user interface should normally prevent casual self-blocking.

For example, if the control is displayed on:

Users
↓
Edit User

you can omit it from the current user’s own:

Profile

screen.

The current TheOneWP Block User Login interface follows this approach for individual account blocking.

Role-level rules remain a separate issue and should still be reviewed carefully.

Use capability checks around block controls

Not every user who can edit content should be able to suspend other accounts.

Administrative actions that modify login eligibility should require an appropriate capability.

The official WordPress security documentation for roles and capabilities emphasizes checking capabilities before performing sensitive operations.

Example administration action

A simplified action could require:

edit_users

or another deliberately selected custom capability.

For example:

if (
    ! current_user_can(
        'edit_users'
    )
) {
    wp_die(
        esc_html__(
            'You are not allowed to manage this user.',
            'project'
        )
    );
}

Choose the capability according to the application’s permission model.

Do not authorize by checking only the role name

A fragile implementation might say:

if (
    in_array(
        'administrator',
        $user->roles,
        true
    )
) {
    // Allowed.
}

WordPress authorization is built around capabilities.

Custom roles can possess capabilities that default roles do not, and plugins can modify permission structures.

See How to Audit User Roles on a WordPress Site.

Use nonces for administration actions

If a block or unblock state is changed through a form or AJAX request, protect the action against cross-site request forgery.

The operation should normally combine:

capability check
+
nonce verification
+
validated user ID

before writing the new state.

Blocking a user should be auditable

Account suspension can have operational consequences.

Useful audit information can include:

target user ID
administrator who changed state
blocked or unblocked
timestamp

Do not include:

• passwords;
• authentication cookies;
• session tokens;
• 2FA secrets.

TheOneWP records individual block changes

When an administrator changes the individual Block User Login state, the current TheOneWP implementation records the block or unblock action in its audit system.

This provides useful historical context when several administrators manage the same installation.

Redirect blocked users deliberately

An implementation can either:

• return a normal authentication error;
• redirect blocked users to an explanatory page;
• redirect already authenticated blocked users after logout.

If you use redirects, validate the destination.

Use wp_safe_redirect() for controlled local redirects

WordPress provides:

wp_safe_redirect()

which validates the redirect destination against permitted hosts.

The official wp_safe_redirect() documentation explains the safe redirect process.

Remember that:

wp_safe_redirect()

does not automatically terminate PHP execution.

Use:

wp_safe_redirect(
    $destination
);

exit;

when appropriate.

TheOneWP supports a global blocked-user destination

The current Block User Login module can redirect blocked accounts to either:

• a published WordPress page;
• a configured custom URL.

If no usable destination exists, the module can fall back to the site homepage.

Individual users can override the global redirect

An individually blocked account can use:

global destination

or have its own configured destination.

This can be useful when different suspension states need different instructions.

For example:

Former employee
→ access removed page

Customer awaiting verification
→ contact support page

Temporarily suspended member
→ account status page

Do not create an open redirect

If administrators can enter a custom URL, the implementation must handle allowed hosts deliberately.

Do not accept an arbitrary request parameter such as:

?redirect=https://malicious.example/

and feed it directly into an unrestricted redirect.

Use WordPress redirect validation APIs and controlled configuration.

Blocking login does not necessarily revoke Application Passwords

This is one of the most important account-suspension details.

WordPress Application Passwords are separate credentials designed for programmatic API authentication.

The official WordPress Application Passwords documentation explains that they are intended for API clients rather than interactive browser login through wp-login.php.

Therefore:

interactive login blocked
≠
all API credentials revoked

Application Password authentication uses a separate path

WordPress provides:

wp_authenticate_application_password()

for Application Password authentication.

The official wp_authenticate_application_password() documentation describes that API-specific process.

Do not assume that a filter designed around normal interactive username/password login automatically blocks every Application Password request.

Review Application Passwords when suspending an account

An account may have:

normal password
+
browser sessions
+
one or more Application Passwords

A complete offboarding process should review all three.

Application Passwords may belong to legitimate integrations

Before deleting them, determine whether they support:

• publishing automation;
• mobile applications;
• external reporting;
• deployment scripts;
• REST API integrations.

A user account sometimes acts as both:

human identity
+
integration identity

which is usually worth untangling rather than breaking blindly.

WordPress can delete all Application Passwords for a user

When full credential revocation is genuinely required, WordPress exposes:

WP_Application_Passwords::
delete_all_application_passwords(
    $user_id
);

The official delete_all_application_passwords() documentation covers that API.

This is destructive to the user’s API credentials, so use it only when that is the intended policy.

You can also prevent Application Password use conditionally

WordPress exposes:

wp_authenticate_application_password_errors

after an Application Password has successfully matched.

The official wp_authenticate_application_password_errors documentation states that plugins can add additional constraints that prevent the credential from being used.

Example: extend the blocked state to Application Passwords

add_action(
    'wp_authenticate_application_password_errors',
    'project_block_application_passwords',
    10,
    4
);

function project_block_application_passwords(
    $error,
    $user,
    $item,
    $password
) {

    if (
        ! $user instanceof WP_User
    ) {
        return;
    }

    if (
        project_user_login_is_blocked(
            $user->ID
        )
    ) {
        $error->add(
            'account_login_blocked',
            __(
                'This account is not currently allowed to authenticate.',
                'project'
            )
        );
    }
}

Again, the hook exposes the supplied Application Password.

Do not log or store it.

Interactive suspension and API suspension should be explicit

There are legitimate cases where an organization might want:

human login disabled
+
service integration retained

and other cases where the requirement is:

all account authentication disabled

Those are different policies.

Define which one you mean before implementing the block.

Password reset is another consideration

A blocked user may still be able to request a password reset unless you separately change that workflow.

This is not necessarily a problem.

If the authentication block remains active after the password is changed, resetting the password does not restore login eligibility.

That is one advantage of keeping:

password state

separate from:

account access state

Do not “block” users by setting a random password

Replacing a user’s password with an unknown random value is not a clean suspension mechanism.

It mixes two different concepts:

credential
and
account eligibility

It also creates additional questions around:

• password reset;
• Application Passwords;
• existing sessions;
• auditability;
• restoring access.

A dedicated blocked state is clearer.

Do not “block” users by changing their email address

The email address is part of the account’s identity and recovery workflow.

Changing it simply to prevent authentication creates avoidable side effects and still does not represent a proper suspension state.

Do not “block” users by removing every capability

A user with almost no capabilities can still potentially authenticate.

Capabilities determine authorization after authentication.

If the account must not log in, enforce that explicitly.

Do not rely on hiding wp-admin

Removing admin menu items or redirecting the user away from:

/wp-admin/

does not prevent authentication.

A user could still possess a valid authenticated session.

Account blocking needs to happen at authentication or session level.

Do not rely on CSS or JavaScript

This is not security:

.login-form {
    display: none;
}

nor is removing the submit button with JavaScript.

The server must reject the account’s authentication.

Do not block users by IP when the problem is the account

Suppose a former employee connects today from:

198.51.100.20

You could blacklist that address.

Tomorrow they could connect from:

203.0.113.40

The account remains valid.

When the policy is:

this user should not authenticate

block the account.

When the policy is:

requests from this network
should not authenticate

use an IP control.

See TheOneWP Access Manager for IP rules and repeated login-attempt controls.

Do not confuse account blocking with rate limiting

Rate limiting reacts to repeated authentication behavior.

Account blocking represents an explicit administrative decision.

Rate limiter
→ too many failures

Block User Login
→ this account is not
currently allowed access

See How to Limit Login Attempts in WordPress.

Monitor blocked-account attempts

If a blocked user repeatedly attempts authentication, that information can be operationally useful.

Possible reasons include:

• the person did not know access had been removed;
• saved credentials are retrying automatically;
• an attacker is targeting the account;
• an integration still uses the identity.

See How to Monitor WordPress Login Attempts.

A blocked account can still be a security signal

For example:

Account blocked:
old-admin

Authentication attempts:
47 in one hour

The block is working, but the activity may still justify investigation.

Do not expose unnecessary account status

A public login response such as:

The account old-admin
was terminated on September 3
and is permanently blocked.

reveals far more information than authentication requires.

Keep public messages appropriate to the site’s threat model.

Role-wide login blocking can be useful for temporary workflows

Sometimes the requirement applies to a complete group.

Examples include:

• temporarily suspending customer accounts during migration;
• preventing a discontinued role from authenticating;
• pausing a group of contractors;
• disabling a membership tier during an account migration.

Review role membership first

Before blocking a complete role, inspect who actually has it.

A role name that sounds harmless may contain accounts with operational responsibilities.

TheOneWP Role Manager can help inspect the role configuration, while How to Audit User Roles on a WordPress Site covers the broader review process.

Consider multi-role users

WordPress users can, through custom implementations or plugins, have more than one assigned role.

Suppose:

User:
Alice

Roles:
Editor
SEO Manager

and your blocked-role list contains:

Editor

You need a clear rule:

Does any blocked role
block the account?

or

Must every role
be blocked?

A conservative role-block implementation usually treats the presence of a blocked role as sufficient, but the policy should be explicit.

Example role-blocking function

function project_user_role_is_blocked(
    $user
) {

    if (
        ! $user instanceof WP_User
    ) {
        return false;
    }

    $blocked_roles = array(
        'editor',
        'author',
    );

    foreach (
        (array) $user->roles
        as $role
    ) {
        if (
            in_array(
                $role,
                $blocked_roles,
                true
            )
        ) {
            return true;
        }
    }

    return false;
}

Combine account and role rules

function project_user_is_blocked(
    $user
) {

    if (
        ! $user instanceof WP_User
    ) {
        return false;
    }

    if (
        project_user_login_is_blocked(
            $user->ID
        )
    ) {
        return true;
    }

    if (
        project_user_role_is_blocked(
            $user
        )
    ) {
        return true;
    }

    return false;
}

The authentication hook can then use one clear decision function.

Use one source of truth

A maintainable implementation should avoid scattered checks such as:

login form
→ one rule

admin page
→ different rule

frontend
→ third rule

REST endpoint
→ forgotten rule

Centralize the blocked-state decision and reuse it across the relevant authentication and session layers.

Current sessions need ongoing enforcement if you do not destroy them immediately

If your administration action does not destroy session tokens at the moment the user is blocked, you need another request-time check that identifies already-authenticated blocked users.

The logic becomes:

user already authenticated
↓
normal request arrives
↓
blocked state checked
↓
wp_logout()
↓
redirect

Example request-time logout

add_action(
    'init',
    'project_logout_blocked_user'
);

function project_logout_blocked_user() {

    if (
        ! is_user_logged_in()
    ) {
        return;
    }

    $user = wp_get_current_user();

    if (
        ! project_user_is_blocked(
            $user
        )
    ) {
        return;
    }

    wp_logout();

    wp_safe_redirect(
        home_url( '/' )
    );

    exit;
}

The official wp_get_current_user() documentation describes retrieval of the current authenticated user.

Avoid redirect loops

If the blocked-user destination itself passes through the same forced-logout logic, make sure your implementation cannot repeatedly redirect the request.

A clean design should decide:

which destination is public
+
which request states
should bypass further redirects

Destroying sessions immediately is cleaner when possible

If an administrator changes the account state directly, invalidating existing sessions at that moment reduces the need to wait for another normal request.

You may still retain request-time enforcement as defense in depth.

What happens to the blocked user’s content?

Nothing needs to happen merely because login access changes.

Existing:

• posts;
• pages;
• comments;
• media attribution;
• custom post relationships;
• profile metadata;

can remain connected to the same user ID.

This is one of the main reasons suspension can be preferable to deletion.

Blocking is reversible

To restore access:

delete_user_meta(
    $user_id,
    'project_login_blocked'
);

After the flag is removed, normal authentication can proceed again, assuming:

• the account still exists;
• credentials are valid;
• another role-wide rule does not block it;
• no other authentication plugin denies access.

Unblocking does not restore destroyed sessions

If you destroyed all session tokens while suspending the account, removing the blocked state does not recreate those sessions.

The user must authenticate again.

That is desirable.

Blocked
↓
sessions destroyed
↓
Unblocked
↓
fresh authentication required

Review 2FA when restoring access

When a privileged user is reinstated, verify that any required stronger authentication is still correctly configured.

TheOneWP Two-Factor Authentication addresses the separate requirement for an additional authentication factor.

Block login vs two-factor authentication

These controls answer completely different questions.

Block User Login
→ Is this account allowed
to authenticate at all?

Two-Factor Authentication
→ What additional proof
must an allowed account provide?

A blocked account should not become allowed merely because the user can supply a second factor.

Block login vs login attempt limiting

Block User Login
→ account-specific policy

Login attempt limiting
→ behavioral abuse control

A blocked account does not need to fail five times before the restriction takes effect.

Block login vs IP blacklist

User block
→ follows the account

IP blacklist
→ follows the network source

If the account should remain inaccessible regardless of where the person connects from, the account-level rule is the relevant one.

Block login vs role management

Login block
→ authentication eligibility

Role Manager
→ permissions after authentication

Use Role Manager when the account should still log in but needs a different permission set.

Block login vs deleting the account

Block
→ reversible
→ user ID preserved
→ content attribution preserved

Delete
→ account lifecycle ends
→ content handling required

Choose according to the actual administrative goal.

Use Last Login before suspending uncertain accounts

When auditing a large user list, successful authentication history can provide useful context.

TheOneWP Last Login records successful access and adds a sortable Last Login column to the Users screen.

This can help identify accounts that appear unused.

Registration date provides additional context

TheOneWP Registration Date exposes account creation dates in the Users interface.

Combined with Last Login, administrators can distinguish:

new account
never used

old account
actively used

old account
dormant for years

Do not block solely because an account is old

Age by itself does not prove that an account is unnecessary.

Investigate:

• owner;
• role;
• last activity;
• content ownership;
• integrations;
• business purpose.

Then decide whether to:

retain
reduce privileges
block login
or
delete

Offboarding workflow

A strong staff or contractor offboarding process can look like:

identify account
↓
review role and capabilities
↓
review content ownership
↓
review integrations
↓
block interactive login
↓
destroy browser sessions
↓
review Application Passwords
↓
review API integrations
↓
document change
↓
delete later only if appropriate

Do not delete first and investigate later

An account can be tied to:

• published content;
• e-commerce operations;
• API integrations;
• automation;
• plugin ownership data;
• workflow history.

Blocking gives administrators time to investigate while access remains suspended.

Use a temporary block during investigations

If suspicious activity appears on an account, a reversible suspension can be appropriate while administrators review:

• recent logins;
• sessions;
• role changes;
• plugin installations;
• content changes;
• Application Passwords;
• other credentials.

The useful property is reversibility.

Account blocking should not replace incident response

If you suspect compromise, simply blocking the account is not the end of the investigation.

Also review:

• whether the attacker created other users;
• whether roles changed;
• whether plugins or themes changed;
• whether files changed;
• whether API credentials were created;
• whether existing sessions remain;
• whether other accounts reused the same password.

Use login monitoring for context

How to Monitor WordPress Login Attempts explains how authentication-event visibility complements account controls.

The relationship is:

monitor
→ identify suspicious activity

block user
→ suspend selected account

destroy sessions
→ remove active browser access

investigate
→ determine what happened

Use login hardening for accounts that remain active

Users who legitimately keep access should still be protected through:

• strong unique passwords;
• 2FA where appropriate;
• rate limiting;
• least privilege;
• account review;
• secure sessions.

See A WordPress Login Hardening Checklist.

Blocking one account does not fix weak global login security

If one compromised account is suspended but every other Administrator remains protected only by weak reused passwords, the wider authentication problem remains.

See WordPress Login Security Layers, Explained.

WordPress Multisite requires extra planning

A Multisite user can potentially belong to multiple sites within the same network.

You need to define whether the blocked state means:

blocked from one site

or

blocked from the
entire network

Those are different policies.

User metadata is network-wide in Multisite

A custom block state stored as ordinary user metadata belongs to the user record rather than one particular site’s role configuration.

If the same blocking plugin is active across the network and checks that metadata everywhere, a user-level flag can effectively become network-wide.

Test the intended scope carefully.

Site membership is another control

WordPress provides:

remove_user_from_blog()

for removing a user from a specific Multisite site.

The official remove_user_from_blog() documentation covers this separate operation.

Removing site membership and blocking authentication are not the same thing.

Do not accidentally block a Super Admin network-wide

Test Multisite restrictions using dedicated accounts before deploying role-wide or metadata-driven rules to privileged network users.

Custom SSO needs separate testing

A site may use:

• OAuth;
• SAML;
• corporate SSO;
• external identity providers;
• custom authentication plugins.

Do not assume a standard WordPress authentication filter controls every external authentication architecture.

Test the actual integration.

Social login can alter the normal authentication flow

A plugin might authenticate a user through an external provider and then establish the WordPress session.

Your blocked-state logic must be applied at a point that still governs that login path.

One reliable pattern is to make the blocked-state function reusable so custom authentication integrations can call it before establishing a session.

Do not rely only on the wp-login.php form

A visual form check such as:

if blocked
    hide submit button

does not protect alternative authentication flows.

Server-side account-state enforcement is required.

Test password login

Use a dedicated test user.

Confirm:

user unblocked
→ correct password succeeds

user blocked
→ correct password fails

user blocked
→ incorrect password still fails

user unblocked again
→ correct password succeeds

Test active-session behavior

Open the test account in one browser.

Then block it from another administrator session.

Confirm the active session is:

• invalidated immediately;
• or terminated on the next request;

according to your chosen implementation.

Test multiple browsers

A user can have several sessions:

Chrome
Safari
mobile browser
another computer

Do not test only one browser and assume all session tokens were invalidated.

Test role-wide blocking

Use multiple users with the target role.

Confirm:

all target-role users
→ blocked

unrelated roles
→ unaffected

Test multi-role users

If the installation supports multiple roles per user, test the exact policy applied when one of those roles is blocked.

Test unblocking

Confirm that removing the blocked state:

• restores normal authentication;
• does not recreate old sessions;
• does not unexpectedly change roles;
• does not alter the user’s password.

Test password reset after blocking

Decide whether the user should still be able to request a reset.

Then confirm that changing the password does not accidentally remove the separate blocked state.

Test Application Passwords separately

If account suspension is intended to include API credentials, verify that Application Password authentication is also denied or revoked.

Do not infer this from the browser login test.

Test REST and XML-RPC integrations

If the blocked account is used by API clients, test those clients before and after the suspension.

This is particularly important when the website has:

• mobile applications;
• external publishing systems;
• automation;
• CRM connections;
• reporting tools.

Test redirects carefully

If blocked users are sent to another page, confirm:

• the destination exists;
• the destination does not require the blocked session;
• there is no redirect loop;
• the URL is validated;
• external destinations are intentionally allowed.

Test your own recovery path

Before applying broad role blocks, confirm you can reverse them through another administrative route.

Security settings are substantially less charming after they successfully secure the administrator out of their own website.

Common mistake: deleting the user when suspension is enough

If historical ownership and account data still matter, blocking may be a safer intermediate state.

Common mistake: changing the role instead of blocking login

A reduced role normally still allows authentication.

Use a real login block when the account should not sign in.

Common mistake: changing the password as the block mechanism

Password rotation and account suspension are separate states.

Store the suspension explicitly.

Common mistake: forgetting active sessions

Preventing the next login does not necessarily remove access already granted to existing browsers.

Invalidate session tokens or enforce a logged-in blocked-user check.

Common mistake: forgetting Application Passwords

Browser login and programmatic API credentials are different authentication channels.

Review both during complete account suspension.

Common mistake: blocking by IP instead of account

An account-level problem should follow the account regardless of network location.

Common mistake: relying on JavaScript

Client-side interface changes do not enforce authentication security.

Common mistake: hiding wp-admin

Redirecting or hiding administration screens is not the same as preventing authentication.

Common mistake: no permission checks on the block control

Account suspension is a sensitive administrative operation.

Protect it with appropriate capabilities and request validation.

Common mistake: allowing self-blocking casually

Individual user controls should make accidental administrator self-lockout difficult.

Common mistake: assuming role-wide blocking cannot affect you

If your own account belongs to the selected role, a role-wide policy can include you.

Common mistake: no audit trail

When several administrators manage users, recording who suspended or restored an account can be valuable.

Common mistake: account status revealed in excessive detail

Do not expose unnecessary internal employment, moderation or security information on a public login form.

Common mistake: redirecting to an unvalidated URL

Use controlled destinations and WordPress redirect-validation APIs.

Common mistake: blocking a dormant service account without checking integrations

Some apparently inactive accounts may still own Application Passwords used by external systems.

Investigate before destructive credential removal.

Common mistake: not testing Multisite scope

User identity, site membership and role assignment behave differently in Multisite.

Define whether the block should be site-specific or network-wide.

Common mistake: assuming every SSO plugin uses the same hooks

Test custom authentication systems separately.

Common mistake: unblocking without reviewing why the account was blocked

Before restoring access, confirm:

• the user still needs the account;
• the role is appropriate;
• credentials are safe;
• 2FA requirements are met;
• the original suspension reason has been resolved.

A practical account suspension workflow

Need to suspend user
↓
identify exact account
↓
review roles
↓
review content ownership
↓
review integrations
↓
set blocked flag
↓
destroy active sessions
↓
review Application Passwords
↓
log administrative action
↓
monitor further attempts
↓
periodically review status

Restoring access workflow

Review suspension reason
↓
confirm user still needs access
↓
review role and capabilities
↓
review password security
↓
review 2FA
↓
remove blocked flag
↓
require fresh login
↓
monitor successful access

How TheOneWP Block User Login fits into this workflow

Block User Login provides both account-specific and role-based suspension controls.

The current module can:

• block individual WordPress users;
• block complete registered roles;
• preserve the user account and existing content;
• prevent blocked users from completing normal authentication;
• sign already authenticated blocked users out during subsequent normal requests;
• redirect blocked users to a selected WordPress page;
• use a configured custom URL as the destination;
• allow an individually blocked account to override the global destination;
• record individual block and unblock changes in the TheOneWP audit system.

The individual account control is intentionally non-destructive

Blocking does not:

• delete the WordPress user;
• delete their posts;
• change their password;
• remove their role;
• erase their profile metadata.

It creates the middle state:

account retained
+
normal login suspended

Role Manager remains a separate module

Role Manager should be used when the question is:

What may this user do?

Block User Login should be used when the question is:

May this user authenticate?

Last Login remains a separate module

Last Login helps administrators identify when accounts were last successfully used.

This can provide useful context before deciding whether to suspend a dormant account.

Registration Date provides account-age context

Registration Date makes account creation history easier to review from the Users screen.

Access Manager handles network and attempt-level controls

Access Manager is appropriate for:

• IP blacklist rules;
• IP whitelist rules;
• failed-login limits;
• temporary lockouts;
• authentication-event visibility.

That remains separate from account-specific suspension.

Two-Factor Authentication protects accounts that remain allowed

Two-Factor Authentication adds another authentication factor to accounts that are still permitted to sign in.

These layers work together:

Block User Login
→ account eligibility

Access Manager
→ source and attempt controls

Two-Factor Authentication
→ stronger identity proof

Role Manager
→ authorization

Last Login
→ successful access history

WordPress user blocking checklist

• Confirm that suspension is preferable to deletion.
• Identify the exact user account.
• Review the user’s role and capabilities.
• Review content owned by the user.
• Review account integrations.
• Store a clear blocked state rather than manipulating the password.
• Use WordPress user metadata for account-specific state when appropriate.
• Enforce the block inside the authentication lifecycle.
• Use wp_authenticate_user or another appropriate server-side authentication hook.
• Return a WP_Error when authentication should be rejected.
• Never log the submitted password.
• Never store authentication secrets in the block metadata.
• Destroy existing browser sessions when immediate revocation is required.
• Use WP_Session_Tokens for session invalidation.
• Do not assume future-login blocking ends sessions already in progress.
• Review Application Passwords separately.
• Decide whether API credentials should remain valid or be revoked.
• Test REST or XML-RPC integrations where relevant.
• Use capability checks around block and unblock controls.
• Use nonce protection for administrative state changes.
• Record block and unblock events where auditability matters.
• Use validated redirect destinations.
• Avoid account-enumeration details in public messages.
• Prevent accidental self-blocking where practical.
• Review role-wide blocks carefully.
• Test multi-role users.
• Test custom roles.
• Keep a recovery path before blocking privileged roles.
• Test existing sessions in multiple browsers.
• Test unblocking and fresh authentication.
• Review 2FA when restoring privileged users.
• Test password-reset behavior.
• Test Multisite scope separately.
• Test custom SSO separately.
• Do not use IP blocking when the policy concerns one account.
• Do not use role reduction when the policy requires complete login suspension.
• Do not rely on CSS, JavaScript or hidden administration menus.
• Review dormant accounts periodically.
• Monitor authentication attempts against blocked accounts.
• Document why the account was suspended.
• Review whether the account should eventually be restored or deleted.

Related guides

• Auditing Dormant WordPress User Accounts
• How to Audit User Roles on a WordPress Site
• WordPress User Roles and Capabilities, Explained
• How to Limit Login Attempts in WordPress
• How to Monitor WordPress Login Attempts
• A WordPress Login Hardening Checklist

Final recommendation

When a WordPress account should no longer be allowed to authenticate, block the account explicitly rather than trying to simulate suspension by deleting permissions, changing the password or hiding the administration interface.

The clean account state is:

user preserved
+
content preserved
+
metadata preserved
+
login denied

For a custom implementation, store a dedicated blocked flag in user metadata and enforce it during the WordPress authentication process.

A practical architecture is:

user meta
→ stores blocked state

wp_authenticate_user
→ prevents new normal logins

WP_Session_Tokens
→ invalidates existing sessions

Application Password controls
→ handle API credentials separately

audit log
→ records administrative changes

Do not forget the session layer. Rejecting future authentication does not automatically solve the problem of a browser that authenticated before the account was suspended.

Do not forget Application Passwords either. Interactive browser authentication and programmatic API credentials are separate WordPress authentication mechanisms and should be reviewed independently when complete account revocation is required.

Use role blocking only when the policy genuinely applies to every account in that role. Use individual blocking when the restriction concerns one user. Keep roles and capabilities separate because authorization after login is not the same thing as permission to log in at all.

For offboarding and security investigations, blocking provides a particularly useful intermediate state because the account can remain available for auditing, content ownership and dependency analysis while authentication is immediately suspended.

TheOneWP Block User Login implements this non-destructive model with individual-user and role-based rules, active-session enforcement, configurable redirect destinations and audit tracking for individual block-state changes.

Used together with Access Manager, Two-Factor Authentication, Last Login and Role Manager, account blocking becomes one clearly defined layer inside a broader WordPress user-access strategy rather than an improvised replacement for account lifecycle management.