Passwords and two-factor
Set who must use two-factor or a passkey, alert people to sign-ins from somewhere new, sign out idle sessions, keep break-glass administrators, and understand how sessions follow your sign-in settings.
Local accounts work out of the box: everyone can sign in with their email and a password unless single sign-on is required for their domain. Settings > Single sign-on (in the People and access group) is the page for how your whole team signs in: passwords, two-factor, single sign-on, where from, sessions and API tokens. It decides who must also use two-factor, and shows whether you have a way in if your identity provider ever fails. Only administrators can open it. Each person's own password, two-factor and passkeys are in Settings > Password and two-factor.
Password rules
- Passwords are at least 12 characters unless you change it. A short sentence works well. The Password rules card on the same page sets the minimum length, whether capitals, numbers and symbols are needed, how many earlier passwords are remembered, expiry and lockout after wrong passwords: see Sessions, IP allowlists and API tokens.
- Changing a password, or setting a new one from a reset link, signs that account out everywhere else.
- Forgot password? on the sign-in page emails a link that works once, within 60 minutes (Password reset links last in the Sessions card changes that), and at most one is sent a minute. The page answers the same way for every address, so it never reveals who has an account.
- Administrators can send the same link from Settings > Users. See Users.
The two-factor policy
Two-factor adds a code from an authenticator app to the password, with ten single-use recovery codes for a lost phone. Under Two-factor for password sign-in, choose:
| Setting | Who must use two-factor with a password |
|---|---|
| Optional | Nobody, but anyone can turn it on for themselves in Settings > Password and two-factor |
| Administrators | Administrators |
| Everyone | Everyone |
Single sign-on is exempt from this policy: the identity provider runs its own multi-factor.
Requiring two-factor
- Go to Settings > Single sign-on.
- Under Two-factor for password sign-in, choose Administrators or Everyone.
It applies straight away. Anyone it now covers who signed in without a code, you included, is asked to sign in again within 15 minutes and sets it up then: the sign-in page shows a QR code or key, asks for a code, shows the recovery codes once, and only then lets them in. Nobody can turn off two-factor that the policy requires.
Tip: Set up two-factor on your own account first, from Settings > Password and two-factor, so you are not interrupted when you turn the policy on.
When someone loses their phone
They sign in with a recovery code and set two-factor up again. If they have none left, reset their two-factor from their user in Settings > Users. Whenever two-factor is turned on for an account, or an administrator resets it, an email goes to the account's address saying what happened and to tell an administrator straight away if it was not them.
Passkeys and security keys
Staff can add passkeys (a fingerprint, face or screen lock on their computer or phone) and hardware security keys from Settings > Password and two-factor. A passkey signs them in on its own, with no password; either also works instead of an authenticator code after a password. See Your profile, security and notifications.
To make sign-in phishing-resistant, require them:
- Go to Settings > Single sign-on and find the Two-factor card.
- Under Require a passkey or security key, choose Administrators or Everyone (the default is No one).
- Press Save.
People it applies to add a passkey or security key at their next password sign-in, and from then on a code from an authenticator app no longer does on its own. Sessions already running carry on until they next sign in. Single sign-on is not affected. Adding or removing a passkey emails the person and is recorded in the audit log; administrators can remove someone's passkey from Sessions and tokens on their row in Settings > Users.
Note: Passkeys belong to your Tenvara address, so on a white-labelled install the browser shows your own domain and product name. They work on your own custom addresses for the staff app and the customer portal too.
New sign-in alerts
With Email people about a sign-in from somewhere new on (it is by default), anyone who signs in from a browser they have not used before, or from another country, is emailed straight away. The email says when, the browser and system, the address and roughly where, and has a This wasn't me link. A notification lands in their inbox too.
- A country counts as new after a number of days (90 by default) without a sign-in from it. Countries need a location service, chosen under Session locations (see Sessions, IP allowlists and API tokens).
- An account's very first sign-in is only recorded, never alerted.
The link opens a page that shows the sign-in; opening it changes nothing, so mail scanners cannot end anything. This wasn't me: end that sign-in signs that session out at once, everywhere including remote control and backup, records it, and offers a password reset. The same button is on each session under Where you are signed in in Settings > Password and two-factor.
Sign out when idle
Under Sessions on Settings > Single sign-on:
- Sign out when idle after: Off (the default), 30 minutes, or 1, 4, 8 or 12 hours without using the app.
- Longest a sign-in lasts: however much the app is used, people sign in again this many days after they signed in (30 by default).
- Stay signed in for: how long someone stays signed in on a device without using it, and Access token lifetime: how long a signed-in browser acts before it quietly renews. A shorter lifetime means a turned-off account stops working sooner everywhere.
A key, a click, a tap, scrolling or the window getting focus counts as using the app, in any open tab. Two minutes before the limit every tab shows "You'll be signed out in 2:00" with Stay signed in and Sign out. Anything someone was typing in a ticket reply or note is kept and is still there when they sign in again. The customer portal has the same two settings in Settings > Customer portal.
Break-glass administrators
A problem at your identity provider must never lock everyone out of Settings. That is what break-glass administrators are for.
- Only administrators can be marked Break-glass administrator, in their user in Settings > Users. The mark goes if they stop being an administrator.
- A break-glass administrator can always sign in with their password, even where single sign-on is required for their domain, and a password reset can reach them.
- A break-glass sign-in always needs two-factor, whatever the policy above. Without it set up, they set it up at that sign-in.
The page says how many break-glass administrators you have: "1 break-glass administrator. They keep password sign-in where single sign-on is required, and always need two-factor to use it." Keep one or two.
What Tenvara refuses
Tenvara refuses any change that would leave no active administrator able to sign in with a password. That includes:
- turning on Require single sign-on for these domains for a domain that covers every administrator, with no break-glass administrator;
- removing, demoting, deactivating or unmarking the last break-glass administrator.
The page warns you when no administrator can sign in with a password.
Warning: Store the break-glass administrator's password and two-factor recovery codes somewhere you can reach when your identity provider is down, such as a sealed record in your own password manager that does not itself depend on that provider.
Sessions follow the settings
A session remembers how it signed in: a password with or without two-factor, or single sign-on through a particular provider. Every refresh (at least every 15 minutes while the app is open) checks that this way in is still allowed, by the same rules as signing in. So when you:
- require two-factor, password sessions it now covers that did not use a code end, including your own, and those people set it up at their next sign-in;
- require single sign-on for a domain, password sessions in that domain end, except a break-glass administrator's session that used two-factor;
- change a provider's allowed domains, turn it off or delete it, the sessions it no longer allows end;
- turn off a user, all their sessions end, and their API tokens, MCP connections and OAuth approvals end for good.
Passkey sign-ins follow the same rules as password sign-ins.
Nothing else is signed out, and signing in again works as usual.
Email for sign-in
Password reset links, "set your password" emails, two-factor notices, and the customer portal's sign-in links and invitations are all sent by email. On a self-hosted install, set up SMTP before relying on them: until then nothing is sent. See Installing self-hosted.
Was this page helpful?
Thanks for the feedback.