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
Script changes require identity confirmation on See Confirm script changes

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, including sign-ins via the API; the current session stays. With the checkbox Also revoke API and AI access (off by default) all API access of the account and its AI account is revoked as well
  • 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, including API sign-ins without a browser; the current one stays. The response states how many there were. With the checkbox Also revoke API and AI access (off by default) all API access of the account and its AI account ends too; without it they stay valid
Deactivate or delete account All sessions and API access of the account end immediately
Admin → Users → "Set Password" All sessions of the user end, including sign-ins via the API and the app
Disable/delete an SSO provider or directory All sessions of its users end immediately; accounts disabled in Active Directory or removed from the group within 15 minutes at the latest
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

  • Set up/disable your own 2FA, add/remove passkeys, regenerate backup codes (changing your own password requires your current password instead)
  • Create, change, delete users, set passwords, reset 2FA, change script permissions and "Access & teams"
  • Create, change, delete roles; create, change, delete teams; move a tenant into a tenant group
  • Delete a tenant, generate a tenant API key
  • Security settings: session limits, 2FA enforcement rules and exemptions, admin access, portal layout, split-container switch (including cancelling and reverting it)
  • Create, change, delete SSO providers and directories (Active Directory / LDAP)
  • SMTP settings and test mail, licence key change, AI configuration and AI connection test
  • Regenerate collector keys; set up, add, remove and make primary Active Collectors, and change their execution approvals
  • Move agents or collectors to a different server URL
  • Instance certificate: every changing action (settings, access check, dry run, issue, install, renew, upload, revert)
  • Accept a changed SSH key of a device
  • Toggle the agent gateway, apply an offline update, change storage retention
  • View/send/download a support bundle; download, restore and delete backups, change backup retention, start a cleanup run
  • Trash: permanently delete a single entry and empty the trash completely
  • Script and command changes (can be switched off, see Confirm script changes)

Confirm script changes

Scripts and custom commands run on the monitored machines: through the agent as SYSTEM or root, and through the collector with the device credentials. Anyone who changes this code therefore confirms their identity first. This applies to every account, including super admins. The permission decides who may change scripts; the confirmation makes sure it really is that person at the keyboard and not someone with a hijacked session.

A confirmation is valid for 15 minutes, counted from the moment of confirmation. It only applies to the session in which you confirmed. Within these 15 minutes you can change any number of scripts and commands without being asked again. After that, the next script change asks again. Working does not extend the period. A fresh login also counts as a confirmation, again for 15 minutes. It is the same confirmation as for the other actions above: if you confirmed for any of them, you are not asked again for script changes within the 15 minutes.

A confirmation is required whenever the code that runs changes:

  • Creating a script in the script library, including "as own script" while editing a check
  • Changing the content or interpreter of an existing script (also through "adjustable values", which live as a header line in the script)
  • Setting or changing a check's own script content "for this device only"
  • Setting or changing a custom command (check types with a "Command" field, e.g. agent command, SSH command): when creating or editing a check, when creating a host with such checks, and in a profile
  • Setting or changing the program or arguments of a plugin check ("Plugin (Nagios)") and the inline body of an agent script check
  • Importing profiles from a file, if the profile brings scripts or commands

No confirmation is required for: assigning an existing script to a check, setting a script's values on a check, changing a script's name, description or output format, deleting scripts, changing intervals and thresholds, and installing or updating profiles from the Vesana library (only versions signed by Vesana). When saving a check, the interface often sends the whole configuration; you are only asked if code actually changes.

Turning it off: under Admin → Login & Security → 2FA & Sessions → Login sessions, switch "Script changes require identity confirmation" (default: on, also after an update). Changing the switch is itself a security setting and requires a confirmation. It is recorded in the audit log (session_settings_update). We recommend leaving it on. Agent Lock adds protection on important servers: changed scripts only run there once they are approved on the server itself.

The same applies to API automation as above: the login counts as a confirmation for 15 minutes. A script that runs longer and then changes scripts gets 403 with code: STEP_UP_REQUIRED (reason: script_change). It must then confirm again via POST /api/v1/auth/step-up or log in again.

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