Security

Your install holds client credentials, personal data and your books. This page covers the security settings and the routine that keeps them working.

Two-factor sign-in

Each person sets up their own second factor on their security page. The choices are:

• an authenticator app (time-based codes),
• a code by email,
• a passkey on a phone, laptop or security key. Passkeys resist phishing, so prefer them.

Recovery codes can be generated for when a device is lost. People can register more than one method and choose which is offered first.

Require it

• Staff: turn on Require 2FA for all staff under Configuration › General › Security. Staff without a second factor are sent to set one up before they can work.
• Client users: each client has a switch that requires two-factor for all its portal users, and a global setting requires it for every Client Administrator. See Client access levels.

Lockout

• Repeated failed sign-ins are rate-limited.
• After a set number of wrong two-factor codes in a row, the account is locked for a cooldown. During the lock even a correct code is refused, so guessing cannot succeed. The defaults are 10 failures and 15 minutes, and both are settings. Administrators are alerted.

Sessions

Staff can see their active sessions on their security page, end any one of them, or end every session except the current one. Changing a password revokes every trusted device for that account.

Sign-in PIN on trusted devices

Staff can mark a browser as trusted after a full sign-in with password and second factor, then set a PIN for that browser.

• Within 48 hours of the last second factor on that device, the PIN alone signs them in.
• After that, the PIN plus a two-factor code is needed, which restarts the 48 hours.
• After 30 days without a password sign-in on the device, after too many wrong PINs, or after a password change, the full password is needed again.

Both windows are settings. Client accounts cannot use a PIN.

Blocking addresses

The app can block IP addresses that attack sign-in. Automatic blocks always expire, and only a person can make a block permanent. To avoid locking you out of your own install, these are never blocked automatically: an address staff recently signed in from, the address of the current request, private and loopback ranges, and anything on your allow list.

Security alerts

The app watches the audit trail as it is written and raises an alert when a pattern matters, such as a run of failed sign-ins against one account, an administrator account being created, or two-factor being switched off. Alerts appear under Security Alerts and can be acknowledged one at a time or all together.

Audit and who-viewed logs

• The audit log records who did what to which record: sign-ins, permission and group changes, setting changes, credential reveals, deletions and restores, and API key use.
• The who-viewed log records who opened which ticket, client record or document, and when. Opening the same record again within ten minutes counts once. Downloads always count. It can be exported to CSV for a single ticket or a whole client.

Review routine

If something happens

1. Preserve. Export the logs for the period.
2. Contain. Disable accounts, revoke API keys and sessions.
3. Assess what could be reached and what was reached.
4. Notify clients and any regulator as your obligations require. The privacy screens include a breach register.
5. Fix and record the cause, and change the process that allowed it.