Skip to content

Login sessions & identity confirmation

Vesana deliberately keeps sign-ins long and makes them revocable at any time: every browser sign-in is a server-side session you can see and end in your account. What protects sensitive actions is not a short session but the identity confirmation right before them.

Stay signed in

The "Stay signed in" checkbox on the login page is pre-selected. With it, the sign-in survives browser, PC and device restarts — including as an installed app on the phone. If you untick it, you are signed out as soon as the browser is closed; this also applies to accounts with 2FA (from v1.9.437).

Operators can disable the option instance-wide (see below) — then every sign-in ends when the browser closes, e.g. in terminal operation.

Limits

Two limits bound every session; both apply instance-wide and can be changed under Admin → Login & Security → 2FA & Sessions → Login sessions:

Setting Default Meaning
Sign out after inactivity 30 days While you use Vesana the session extends automatically. Only after this period without use is a new sign-in required. Selectable from 1 hour to 90 days
Absolute limit (even when active) 90 days A new sign-in is due at the latest by then — regardless of how active the account was. Selectable up to 1 year, never shorter than the inactivity limit
Sign everyone out on restart off A restart of Vesana or the Vesana machine signs out all users. Updates do not count as a restart — an announced update carries running sessions over
Offer "Stay signed in" on Whether the checkbox appears on the login page

If an admin extends a limit, it applies immediately to running sessions too. The limits also apply to sign-ins via API token (Bearer): even a token chain that keeps extending itself via refresh ends at the absolute limit at the latest.

See and sign out your own devices

Settings → Sessions lists all active sign-ins of your own account: browser/device, IP address, signed in since, last used. The current session is marked.

  • Sign out a single other session (button in the row)
  • Sign out everywhere else — ends all other devices and browsers; the current session stays
  • The current session ends via the normal Sign out

Signing out takes effect server-side and within seconds: an ended or revoked login cookie no longer works on any device afterwards, not even within the token's remaining lifetime. An already-used login token that shows up again (a sign of theft) ends the whole session immediately.

What ends other sessions

Event Effect
Change password (Settings → Profile) All other sessions are signed out; the current one stays. The response states how many there were
Deactivate account All sessions of the account end immediately
Admin → Users → "Sign out all sessions" Emergency brake for compromised accounts: all sessions of the user on every device; password and 2FA remain unchanged. Asks for confirmation and reports the count (from v1.9.437 also as a button in the user row)
Admin → Users → "Reset 2FA" Removes the second factor and signs out all sessions — see 2FA
Instance restart only if "Sign everyone out on restart" is enabled

Logout reason on the login page

Whoever was signed out sees why on the login page — for example: inactive for too long, maximum duration reached, signed out elsewhere (sign-out-everywhere-else or an administrator), password changed, account deactivated, Vesana restarted, or session ended for security reasons (reused token). This helps tell "expired normally" from "someone intervened".

Confirm identity (step-up)

Before actions that change the security level of an account or the instance, Vesana requires a fresh confirmation of identity — regardless of how long the session has been running. The "Confirm identity" dialog opens automatically; after confirmation the action is carried out.

Valid for 15 minutes, per session. A fresh login counts as a confirmation itself. A second device of the same account must confirm on its own.

Which actions

  • Change your own password, set up/disable your own 2FA, add/remove passkeys, regenerate backup codes
  • Create, change, delete users, set passwords, reset 2FA, change script permissions
  • Create, change, delete roles
  • Delete a tenant, generate a tenant API key
  • Security settings: session limits, 2FA enforcement rules and exemptions, admin access, portal layout, split-container switch
  • Create, change, delete SSO providers
  • SMTP settings, licence key change (from v1.9.437), AI configuration
  • Regenerate collector keys; set up the Active Collector and change its execution approvals
  • Toggle the agent gateway, apply an offline update, change storage retention
  • Send/download a support bundle, download a backup, empty the trash completely

How to confirm

The dialog offers the methods set up for the account — in this order: passkey/security key, code from the authenticator app, password, backup code. SSO accounts without a local factor confirm by signing in again at the identity provider and return afterwards. If an account has no confirmation method (no password, no second factor), an administrator must set one.

A TOTP code is valid exactly once — the same code confirms neither a second sign-in nor another security prompt (from v1.9.437).

Tokens never in addresses

Login tokens appear neither in web addresses nor in server logs — not even for live logs or TV mode. Scripts and API clients use the Bearer path, see Auth flow.

Next