What the session page shows
Open Settings → Security to review active human browser sessions. Every signed-in user can see their own sessions.
A user with users:manage can also switch to All sessions to review and revoke sessions across local users.
Each row contains operational metadata only:
- the browser or client description;
- the network source recorded by the server;
- when the session was last used;
- when it expires;
- whether it is active or is the current browser session; and
- the local user and role in the all-sessions view.
The page never displays reusable credentials. Search and filters operate only on the returned session metadata.
Use search for an approved user, client description, role, or network-source value. Filter to This session before revoking the current browser, or Other sessions when containing another device without intentionally ending the current session. Select Refresh after an incident action; an empty filtered result is not proof that no other sessions exist until the unfiltered list also loads successfully.
Revoke one session
Use Revoke when a device, browser, or network source is no longer recognised or approved. Review the confirmation before continuing. Revocation takes effect on the server; closing a browser tab is not a substitute.
Revoking the current session signs that browser out immediately and returns it to the sign-in page. Revoking another session leaves the current browser signed in.
Revoke several sessions
In Your sessions, Sign out everywhere ends all of your active sessions, including the current browser.
In All sessions, Revoke all ends every active human browser session. This is a broad incident-response action: every user, including the administrator performing it, must authenticate again. Confirm the scope and coordinate the action before continuing.
Disabling or deleting a user, resetting or changing a password, or changing a user's assigned role invalidates the affected sessions. Expired and explicitly revoked sessions are also rejected. Do not wait for a suspicious session to expire naturally.
If a revocation request fails, do not assume the session ended. Refresh the list, check application/database health, and retry from a trusted browser. When immediate containment matters and the scope is uncertain, use the confirmed all-session action after coordinating that every user will need to authenticate again.
Incident-response checklist
- Revoke the affected session, or all sessions when the scope is unknown.
- Reset the affected user's password and review their role assignment.
- Review activity logs and the client's network and identity-provider records.
- Rotate separate service-account API keys only if those non-human credentials may also be affected; browser sessions and service-account keys are different credential types.
- Record the response without copying cookies, tokens, passwords, API keys, or verification data into tickets.
Valid sessions normally remain active across an application service restart. Users may still be asked to sign in again after a security action, expiry, recovery, or an update that changes authentication behavior.
Use individual accounts so session ownership remains attributable. See Users, roles & permissions for the wider local access model.