Sign-in security screen

Sign-in security manages the unlocked personal profile’s master-password change, TOTP-based 2FA binding, and, for the Owner, active server sessions. VaultPilot sign-in uses username, master password, and an authenticator code when 2FA is enabled.

Access, role, and server-settings context

Sign-in security needs no separate license feature, and every role can see the tab. Owner, Admin, and Auditor see the other Server settings tabs as well; User sees only Sign-in security. A non-Owner who tries to open License or Integrations is sent to this tab.

Owner, Admin, and User can change their own password and 2FA; Auditor can see the forms but the server refuses the change. Changes need a writable license, so a read-only license blocks them even though the controls are not disabled in advance. Listing and revoking active sessions is Owner-only.

This tab covers only your own profile. The Owner does not reset another user’s password or 2FA here. The founding Owner’s tools for other non-Owner users are on Users and have their own role, target, confirmation, and read-only rules.

What you can do here

• Confirm the current master password, then enter and confirm a new master password of at least 14 characters.
• When 2FA is off, generate a TOTP secret and QR code, then turn on the binding with the first six-digit authenticator code.
• When 2FA is active, check whether both encrypted copies of the binding are ready.
• If a phone is lost or an app is changed while the profile is still unlocked, revoke the current binding after confirmation and start setup again.
• As Owner, review active sessions by user, role, last seen, expiry, and current-session state; revoke a session other than your own.
• Use the topbar Lock vault and sign out action to lock this browser profile manually.

There is no lock-timeout setting, failed-sign-in lockout policy, or trusted-device list on this tab. Automatic lock is fixed at 15 minutes and cannot be changed here.

Change master password

Change master password affects only the current unlocked user’s profile. The current password is required; the new value must have at least 14 characters and match its confirmation. Repeated attempts in a short time are refused for a while.

The browser re-encrypts your profile keys and, when present, your 2FA copy with the new password. The server checks the current password and stores the new encrypted material. Master passwords are never stored on the server in readable form.

A successful change is recorded in the audit history and ends your other sessions while keeping the current one. The success message says the profile keys were re-wrapped. This is not a temporary password for another user, a profile reset, or forgotten-password recovery.

2FA states and setup

2FA off / Setup pending

Start 2FA setup generates a new TOTP secret in the browser. Regenerate QR replaces that not-yet-saved secret; the old QR is not an enabled binding. The setup card shows a QR code, a formatted manual key, and a six-digit code field.

A placeholder appears while the QR code is drawn. If the QR code fails, an error appears and the manual key can still be available. Both the QR code and manual key are highly sensitive. Add the account to the authenticator, enter the current six-digit code, then choose Enable 2FA. The code is checked in the browser and again on the server, allowing for small clock differences; repeated attempts in a short time are refused for a while.

On success, the binding is stored twice: once encrypted with your master password for recovery, and once encrypted by the server for sign-in checks. Your other sessions end, and the audit history records that 2FA was turned on. The next normal unlock requires an app code.

2FA active / Ready or Check

An Active binding shows Code required on unlock. When both encrypted copies are present, the state is Ready / Dual-encrypted binding. If either is missing, the state is Check / Binding check pending; do not treat it as healthy.

An older profile with 2FA turned on but missing the server copy is refused at unlock. The recovery guidance points to an administrator backup or profile reset; there is no email, recovery code, or way to skip TOTP.

Revoke binding and reset boundary

After confirmation, Revoke binding removes your authenticator binding, ends your other sessions, and is recorded in the audit history. The current session stays open. You can then set up a new device; no existing secret is shown and no recovery code is generated.

You cannot revoke it yourself when you are locked out without the authenticator, because the profile and session must already be open. On Users, the founding Owner can reset 2FA only for another non-Owner user, never for themselves or an Owner account.

Active sessions

Active sessions loads only for the Owner and refreshes automatically while the tab is open. Refresh reloads it immediately. The list shows unexpired sessions of active users in the organization.

Summary counts show total active, current, and revocable sessions. Each row shows a short public session ID, user and display name, role, last-seen time, expiry, state, and action. It does not show IP address, browser name, or device, so the table alone cannot identify a physical device.

The current row is marked Current and its Revoke button is disabled. Revoke on another row acts immediately without a second confirmation. Success removes the session, refreshes the list, and is recorded in the audit history. Do not include session IDs or usernames in shared evidence.

Placeholder rows appear while sessions load. There is no separate error card; if loading fails, the panel can show No active sessions are available. Do not treat that empty state as proof of zero sessions until you have refreshed and checked the connection and your Owner session.

Manual lock, automatic lock, and fast unlock

Topbar Lock vault and sign out clears revealed and copied values, the generated share package, the unlock code, any unfinished 2FA setup, fast unlock, and cached data; it removes unlocked keys and signs out of the server. It does not clear the share passphrase, the selected share records, or the share package details; the screen locks, but these can remain in browser memory.

The vault locks automatically after 15 minutes without activity in the browser. Mouse, keyboard, scrolling, and switching back to the tab reset the timer. At timeout, revealed and copied values, the share package and passphrase, selected share records, fast unlock, the server session, cached data, and unlocked keys are cleared. Unlike manual lock, automatic lock does not clear the share package details or unfinished unlock and 2FA setup data; the lock screen hides them, but do not rely on automatic lock to clean up after exposing share details, a QR code, or a manual key.

If you abandon a sharing or 2FA workflow that showed sensitive data, do not rely on either lock alone; reload the page fully.

After a normal unlock, fast unlock can keep your session in browser memory for 15 minutes. It never stores the master password or keys derived from it in browser storage. Manual or automatic lock clears fast unlock.

Password, profile reset, and recovery boundaries

• Change master password re-wraps your own profile keys; it does not delete profile data.
• Users > Set password is a separate action for the founding Owner on another non-Owner user. It ends that user’s sessions, resets their 2FA, and re-wraps their personal-vault key to a new temporary password.
• Reset server profile is not a Sign-in security control. It is a separate destructive Owner action that requires an Owner session and an exact typed confirmation phrase; it deletes the organization, users, vaults, secrets, sharing, integration and directory data, audit data, and every session. It is not a simple forgotten-password reset.
• The lock-screen recovery message first asks you to check the master password, Caps Lock, and TOTP, then points lasting server or profile failures to a VaultPilot Backup Tool restore. Support never knows and never asks for your master password, TOTP secret, or session cookie.

There is no email password reset, recovery code, SMS, IdP redirect, or support-side way around sign-in.

Recommended workflows

Set up the first 2FA binding

1. Confirm the profile is unlocked, the session is confirmed, and the license is writable.
2. Choose Start 2FA setup.
3. Scan the QR code in the authenticator or type the manual key directly; do not take a screenshot.
4. Enter the current six-digit code and choose Enable 2FA.
5. Confirm Active and Ready / Dual-encrypted binding.
6. Lock deliberately and confirm unlock with username, master password, and a fresh TOTP code.

Revoke a suspicious old session

1. As Owner, refresh Active sessions.
2. Compare user, role, last seen, and expiry; the table has no device or IP details.
3. Select the approved row that is not Current.
4. Revoke acts without a second confirmation; press it once.
5. Confirm the list changed and the audit history shows the revocation.

Screen states

Before you act

• Tell apart an action on your own profile, on another user, and on the whole server profile.
• Confirm your role and a writable license; Auditor can see the forms but cannot change the profile.
• Turn off screen sharing and recording while a QR code or manual key is visible.
• Expect your other sessions to end after a master-password or 2FA change.
• Session Revoke has no second confirmation, and the current session cannot be revoked from the table.
• Confirm an approved backup and a way back in before revoking 2FA or resetting a profile.

Safe evidence

• Safe to share: role, 2FA off/active/ready/check state, total and revocable session counts, approximate last-seen and expiry window, general error, and broad time range.
• Keep private: username and display name, master password, TOTP secret, QR code, six-digit code, encrypted key material, session ID, token or cookie, backup files, and exact times.
• The session table holds no device or IP details; do not invent them in evidence.
• Do not just blur a manual TOTP key in a screenshot. Mask it completely and check that no copy keeps it.

When to stop and escalate

Stop making security changes when 2FA is on but stays Check, the server copy is missing, the profile cannot be opened after a password change, other sessions stay active after a change, the session list shows an unexpected user, or automatic lock does not clear expected sensitive data. Email support@vaultpilot.io with your role, general state, broad time window, error message, and last safe step, without secret values.

Operator notes

Sign-in security is not an identity-provider or email-account screen. Master password, TOTP, and sessions live within the VaultPilot server profile and the browser. Never share recovery material, TOTP secret, master password, cookie, or one-time code.

Related

• First run, owner and license
• Users screen
• Server settings screen
• Session 401 after login KB
• Security and trust model

Back to Documentation →