A session is one signed-in browser or app. This page explains how long sessions live, how you and your administrators end them, what happens after failed sign-ins, how unusual sign-ins are flagged, and how trusted devices skip the second factor.
How long a session lasts
| Rule | Effect |
|---|---|
| Inactivity | A session that is not used for a while ends; you sign in again. |
| Absolute lifetime | Every session ends after a maximum lifetime, even when used, and longer when you tick “remember me” at sign-in. |
| Sessions per person | At most 10 live sessions per person in one organisation. Signing in on one more ends the oldest. |
| One session per browser | Signing in again in the same browser replaces that browser’s session. |
Access tokens are short-lived and renewed in the background. If a renewal token is ever used twice, all of that person’s sessions end, because it means a token was copied.
End sessions
| Who | How |
|---|---|
| You | My Profile > Security > Active Sessions: Sign out on one session (“The device using this session is signed out at once. If it is the one you are using now, you are signed out too.”) or Sign out all other sessions (“Every other device signed in to your account is signed out at once. The session you are using now stays.”). |
| An administrator | Members > member > Sign out: the member is signed out of this organisation on every device. “They can sign in again; to keep them out, suspend them.” |
| Automatically | A role change, suspension or removal ends the member’s sessions in the organisation at once. A suspended organisation’s sessions all end. |
Each entry in Active Sessions shows the Device, IP address, Location, Started, Last active and Expires.
Lockout after failed sign-ins
| Setting | Where | Default |
|---|---|---|
| Lock an account after (failed sign-ins) | Settings > Authentication & SSO | 5. “1 to 5. The built-in limit is 5; a lower number locks sooner.” |
| Lock duration | Set by the platform | 15 minutes by default |
A locked account sees “This account is locked after too many failed sign-ins. Try again later or reset your password.” The lock is checked before the password, so a locked account gives no hint whether a password was right. A CAPTCHA can be asked for after a few failures where a CAPTCHA provider is installed. Every lock writes auth.account_locked to the audit log and fires the auth.account_locked webhook.
Wrong second-factor codes are limited too: “Too many wrong codes. Verification codes are paused for n minutes.”
Security locks
Hermetry’s operators can put a security lock on an account. It ends every session and refuses every sign-in method until it is lifted: “This account is locked for security reasons. Every sign-in method is blocked until it is unlocked. Contact support.” The person is told by e-mail.
Unusual sign-ins
Every sign-in is compared with the person’s previous one. Hermetry flags impossible travel, a new country, an anonymising network (proxy, VPN or Tor), a new address and a new browser or operating system. Each unusual sign-in writes one auth.login_anomaly audit row, with a severity from low (a new address or device) to high (impossible travel or Tor), and fires the security.login_anomaly webhook. The AI firewall uses the same signals.
Trusted devices
When you choose to trust a browser at sign-in, it skips the second factor for a while: 30 days by default (the platform sets the value, at most 30). The browser still needs the password.
My Profile > Security lists your Trusted devices with Trusted since, Last seen and Trusted until. Revoke one, or Revoke all: “The next sign-in on every trusted device asks for your sign-in code again. Nobody is signed out.”
Revoke trusted devices when a laptop is lost or shared.
IP access lists
An Owner can restrict which addresses may open the organisation: Settings > Sign-in Policy > IP access lists.
| Field | Meaning |
|---|---|
| Allowed addresses (empty allows every address) | IPv4 or IPv6 addresses and CIDR blocks, separated by commas, spaces or new lines. When set, every other address is refused. |
| Blocked addresses | Addresses that are always refused. |
“A list that would refuse your own address is not saved.” A refused request gets 403 (TENANT_IP_NOT_ALLOWED), with the same answer for both lists. The lists apply to members’ requests in the organisation. Signing in itself and requests with API keys are not checked by them; API keys have their own allowed networks (see API key hardening).
Registration
Settings > Authentication & SSO > Registration & Verification:
| Setting | Meaning |
|---|---|
| Allow Public Registration | “When off, only admins can create new accounts.” Invitations still work. |
| Require Email Verification | “Users must verify their email before accessing the platform.” |
For an IoT organisation, keep public registration off and invite people.