WordPress force logout all users: what each option ends

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.

Contain the right access

A sign-out is not credential revocation

Select the access route that needs to end.

1. 01
   Existing browser session

   End the session.

2. 02
   Future person sign-ins

   Review passwords and passkeys.

3. 03
   Connected tools

   Revoke their grants separately.

Existing browser session

What this means

The selected browser must authenticate again. A valid credential can create a new session.

Your next check

Check the session list after the action and verify the old session no longer works.

Future person sign-ins

What this means

Reset a compromised password, review enrolled passkeys and secure the recovery mailbox. Session cleanup alone does not do this.

Your next check

Remove credentials the departing or unauthorized person can still use.

Connected tools

What this means

Application passwords and assistant connections do not rely on ordinary browser sessions.

Your next check

Review both application passwords and connected assistant grants, plus hosting access.

Decide how wide to go

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.

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.
• 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.

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. 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.
• 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 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 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

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. Every option on the screen is covered in the Sessions guide.