# WordPress force logout all users: what each option ends

WordPress force logout all users, one account or idle sessions: what each option ends, what it leaves, and how to see WordPress active sessions first.

By BetterShield Team, Oct 11, 2026. Updated Oct 26, 2026 by Nazmul Hasan Rupok.

There are good reasons to make WordPress force logout all users at once: a laptop left on a train, a contractor whose job is done, a password that may have been shared somewhere it should not have been. Signing people out takes a minute. Knowing what it actually ends, and what it leaves running, is the part that decides whether it worked.

This guide shows how to see WordPress active sessions first, the ways to end them with and without a plugin, and what each one does and does not end. BetterShield's way is shown with its exact labels and linked to the docs.

## Quick summary

- A WordPress session represents a browser sign-in. Core authentication cookies default to two days, or fourteen with Remember Me; plugins and site policy can change this.
- A sign-out does not revoke credentials. End active unauthorized access promptly, then replace affected passwords and review the other ways to sign in.
- **Sign out everyone you can**, on **BetterShield › Protection › Login & Access**, ends every session of every account you may edit, yours included.
- Rotating the sign-in keys makes every other session stop working at once, without changing anybody's password.
- No sign-out revokes application passwords. Those are separate credentials, revoked separately.
- An idle sign-out and a per-account limit keep sessions short from then on, but they apply to every role, store customers included.

## Why you would sign everyone out

- **A lost or stolen device.** A phone or laptop that was signed in stays signed in until its session ends.
- **Someone leaving.** A staff member, a contractor or an agency handing a site back.
- **A password that may have leaked.** Reused somewhere else, typed on a shared computer, sent in a chat.
- **After a clean-up.** If you think someone else got into an administrator account, every session that account held is suspect, and so is any session it could have created.

In each case the goal is the same: whoever is signed in now should have to sign in again, with a password and a second factor they actually hold.

## First, see WordPress active sessions

Before ending anything, look at who is signed in.

- **WordPress itself.** Your own profile offers **Log Out Everywhere Else** when you are signed in on another device, and an administrator editing another user sees **Log Out Everywhere**. WordPress does not list sessions across accounts.
- **WP-CLI.** `wp user session list <user>` lists one account's sessions.
- **BetterShield.** **Who is signed in**, under **Sessions** on **BetterShield › Protection › Login & Access**, lists every account with a live session: its roles, and for each session when it signed in, when it was last seen and the network it came from (a /24 or /64, never a full address). On a store, customers are in the list too. The **Signed in** tile at the top of the screen counts them.

## Decide how wide to go

| Situation | Start with | Then |
|---|---|---|
| One person lost a device | They press **This was not me** beside that device, or you press **Sign out all their sessions** | They change their password |
| Someone is leaving | **Sign out all their sessions** | Remove or demote the account, and revoke its application passwords |
| A password may have leaked | Change it. With BetterShield, that account's other sessions end | Check **Who is signed in** |
| Someone else may have used an administrator account | Change the administrators' passwords, then rotate the sign-in keys or press **Sign out everyone you can** | Revoke application passwords, and read the [activity log](/docs/activity-log/) |

## Option 1: Sign out everyone you can

1. Open **BetterShield › Protection › Login & Access** and scroll to **Sessions**.
2. Under **Who is signed in**, press **Sign out everyone you can**.
3. Read the confirmation. It says your own session is included and, when some accounts are out of your reach, how many sessions it ends and how many it leaves. Press **Yes, do it**.

**It ends** every session of every account you have permission to edit, on every device. On a typical single site, an administrator can edit the other accounts, but multisite and custom capability rules can restrict that scope. Your own session ends too, and you land on the sign-in page. One press reaches up to 500 accounts, network administrators and staff accounts first; on a larger site, press it again.

**It leaves** everyone's password and application passwords, and the sessions of accounts you cannot edit, which happens when you manage BetterShield without permission to edit other users, or on one site of a multisite network. With **Ask for my password before an action that removes a protection** on, it asks for your password first. The activity log records "Sessions signed out".

## Option 2: Sign out one account

Beside each account in **Who is signed in**, **Sign out all their sessions** ends every session that account holds. The account and its password are untouched. It needs permission to edit that account, and on a multisite network it ends the sessions on every site, because the network shares accounts.

Without a plugin, the same is **Log Out Everywhere** on that user's profile, or `wp user session destroy <user> --all` from WP-CLI. To do it for everyone from the command line: `wp user list --field=ID | xargs -I % wp user session destroy % --all`.

## Option 3: Let people sign themselves out

Often the person who lost the phone is the fastest to act. With BetterShield, every user has **Where you are signed in** on their own profile, and store customers have it on My Account under **Sign-in security**. **This was not me** ends one session, and **Sign out everywhere except this device** ends the rest. Each is recorded as "Signed out of a device". See [Your profile](/docs/your-profile/).

## Option 4: Rotate the sign-in keys

WordPress signs every login cookie with the secret keys in wp-config.php. Change the keys and every existing cookie stops working.

- **With BetterShield:** **Sign everyone out on demand** sits under **Signing in** on **Login & Access**. Applying it mixes a strong secret into the keys WordPress derives, without editing wp-config.php. Once applied, **Rotate keys now** generates a new secret. Applying, rotating and undoing all sign out every session except the one you are using, including your own on other devices. Made from the dashboard, the session you are using is carried over; made from the command line or by an AI assistant, yours ends too. Nobody's password changes, and a page cache may keep serving cached pages to signed-out visitors until it clears. On a network it is done from **BetterShield › Network** and ends every session on every site. See [Hardening](/docs/hardening/).
- **Without a plugin:** replace the eight key lines in wp-config.php with a fresh set from the WordPress.org secret-key generator. Everyone, you included, is signed out once, and no password changes.

The difference from Option 1: rotation does not ask whose account it is. Every other session on the site stops working, whatever the number of accounts.

## Option 5: Change the password

With BetterShield active, when an account's password changes, its other sessions end. Someone changing their own password keeps the device they did it on; a password set by an administrator or through a reset link ends every session. The same happens when a second factor or a passkey is removed, or when a role change gives or takes away a role that can manage settings or users. The log records "Sessions ended after a credential change".

## Keep sessions short from now on

Under **Sessions** on Login & Access:

- **Sign out after idle (minutes)** ends a session that has gone that long without activity: 5 to 1440 minutes, or 0 to leave sessions open. Opening a page or saving something counts as activity; the dashboard's background check-in does not. On a WooCommerce store, nobody is signed out on the cart or checkout.
- **Sessions per account** limits how many sessions one account holds: 1 to 100, or 0 for no limit. Each new sign-in past the limit ends the oldest.

Both apply to every role, customers and members included. We recommend about 120 minutes on a site where only staff sign in, 0 or 1440 on a store, and on a membership site a limit of 2 or 3 sessions rather than a short timeout. See [Sessions](/docs/sessions/).

## What none of these end

- **Application passwords.** They are separate credentials for tools, with no session to end. Revoke them on each account under **Users**. See [WordPress application passwords](/blog/wordpress-application-passwords/). BetterShield's **Lock the site down** makes them unavailable while it lasts, signs out every other dashboard session and refuses sign-ins from accounts that cannot manage the site. See [Site lockdown](/docs/site-lockdown/).
- **The password.** Signing someone out does not stop them signing back in. Change the password first.
- **Accounts you cannot edit.** **Sign out everyone you can** says how many it left.
- **A cached page.** A page cache may keep serving pages that were cached earlier until it clears.

## A practical offboarding and containment check

For routine offboarding, arrange the account and content handover before access ends. Review application passwords, passkeys, assistant connections and hosting credentials alongside the browser session. Removing one route does not revoke the others.

If there is active unauthorized use, end the relevant access promptly from a trusted device. Do not wait for a perfectly ordered checklist while the account is making changes. Preserve available session and activity metadata when practical, then work through:

- Replace compromised account credentials and secure the recovery mailbox.
- End the affected browser sessions, using the scope shown in the confirmation.
- Remove unauthorized passkeys and revoke affected application passwords and assistant grants.
- Check for additional accounts or role changes made during the access window.
- Recheck sessions and try a fresh authenticated request with a revoked test credential where appropriate. A public page loading does not prove access remains.

**Worked example (fictional):** a former contractor's browser session is ended, but their publishing integration keeps posting through an application password. The sign-out worked; it covered the browser session. Revoke the integration credential or transfer the integration to a new, suitably limited account, then verify that the old credential cannot perform its authenticated task.

Use [the first-hour response guide](/blog/wordpress-security-incident-response/) when activity is unexplained. A broad sign-out can interrupt staff and customers, so choose its scope deliberately and tell the people operating the site what to expect.

## Common mistakes

- **Treating a sign-out as a complete response.** A retained password, passkey or API credential can restore access. Review credentials and sessions together.
- **Forgetting application passwords.** A tool connected with one keeps working after every sign-out.
- **Forgetting you are included.** **Sign out everyone you can** ends your session too. Have your password, your second factor and your [recovery link](/docs/set-up-recovery/) at hand.
- **A short idle timeout on a store.** It reaches customers as well as staff.
- **A session limit of 1.** People who use a phone and a laptop sign themselves out every time they switch.

## Frequently asked questions

### How do I force logout all users in WordPress?

With BetterShield, press **Sign out everyone you can** under **Sessions** on **BetterShield › Protection › Login & Access**, then **Yes, do it**. Without a plugin, replace the secret keys in wp-config.php, or end each account's sessions with `wp user session destroy <user> --all`.

### How can I see WordPress active sessions?

WordPress shows only a sign-out button on each profile. `wp user session list <user>` lists one account's sessions. BetterShield's **Who is signed in** lists every signed-in account with each session's sign-in time, last activity and network.

### Does signing everyone out change their passwords?

No. Every account keeps its password and its application passwords. People sign in again the usual way.

### Will it sign out my store's customers?

**Sign out everyone you can** and a key rotation reach customers too, because customers are accounts. The idle sign-out and the session limit also apply to customers, though nobody is signed out on the cart or checkout by the idle sign-out.

### Does BetterShield end sessions when a password changes?

Yes. The account's other sessions end. If the person changed their own password, they keep the device they did it on.

## Conclusion

Forcing everyone out of WordPress is easy; making the containment last means addressing the credentials as well, picking the narrowest option that covers the problem, and remembering that application passwords are separate. Look at **Who is signed in** before and after, and let an idle sign-out or a session limit keep things tidy from then on.

BetterShield is free on [WordPress.org](https://wordpress.org/plugins/bettershield/).
Every option on the screen is covered in the [Sessions](/docs/sessions/) guide.