Signing in

How to get into the admin console, and what decides what you see once you are in.

Where to sign in

The admin login form asks for three things: which tenant you're signing into, your username, and your password (plus a captcha challenge if one is configured). Kiwire maps the tenant you typed to that tenant's own database, named after the tenant. If that database doesn't exist, login fails with the same generic "invalid username or password" message a wrong password would give — Kiwire deliberately doesn't say whether the tenant or the credentials were the problem.

The login form also offers a "remembered accounts" picker, built from a browser-side cookie of tenants and usernames you've signed into before. It lets you jump straight back into an account with one click, but it only skips the MFA challenge — never the password — and only when that exact account was actively used within the last few hours (a platform setting, six hours by default). MFA on the account itself is never disabled by this; it's the same kind of convenience as a browser remembering a device, not a change to the account's security settings.

Tenant and sub-tenant

Signing in resolves your role by joining your admin record to that tenant's own roles table, so what you can do is entirely a property of the tenant you logged into — the same username in two tenants is two separate accounts with two separate roles, and an admin account only exists in the tenant it was created in. An admin who has been allowed into more than one tenant switches between them from the Tenants page rather than by signing in again.

A tenant licensed for the Subtenants module can carve itself into sub-tenants: named partitions of its users, vouchers and quota. Each sub-tenant has its own admin accounts and its own, smaller role set, restricted to that one partition, and they are managed from the tenant's Subtenant pages (see the menu tour) rather than from System › Administrators.

Multi-factor authentication

MFA is TOTP-based — a six-digit code from an authenticator app. The first time an admin logs in without MFA configured, they're logged in but immediately redirected to mandatory enrolment: a QR code is generated from a freshly issued secret, labelled with the host, tenant and username so it's identifiable in the authenticator app, and MFA isn't actually turned on until the admin confirms it by entering one valid code back. Until that happens, the session is flagged as not MFA-verified.

Once MFA is enabled, a normal login doesn't complete straight away. After the password check succeeds, Kiwire deliberately logs the admin back out and holds a pending-MFA marker in the session instead — the account isn't trusted as authenticated until the six-digit code is verified separately. Only once that code checks out does Kiwire re-establish the login, regenerate the session, and mark it MFA-verified. Disabling MFA requires re-entering the current password, and doing so immediately raises a security alert — turning MFA off is treated as a meaningful weakening of the account's security, not a routine settings change. Two admin-side controls sit outside the login flow itself: the tenant-wide "administrators must use MFA" switch is labelled "2-Factors Authentication" on System › Settings › General, and the per-admin Reset MFA action — which sends someone back through enrolment — lives on the Administrators page.

Session rules

Three checks run on every authenticated admin request, and none of them has a settings page — the numbers below are fixed, not tenant options.

• One active session per admin. Every request re-reads the admin's active flag and current session ID from the database. Signing in from a second browser or device replaces the current session ID, so the first session is ended on its very next request with a "signed in from another device" message; deactivating an admin logs them out on their next request the same way, without waiting for the session to expire.
• Idle timeout. The time of each request is stamped in the session; if 30 minutes (fixed) pass with no request, the next one is refused and the admin lands back on the login form.
• Password rotation. An admin whose password is 90 days old (fixed) — or who has never changed it since the account was created — is redirected to the change-password page on every request until they set a new one.

There is no admin page that lists live sessions, no force-logout button, and no per-tenant setting for the idle timeout or the password age — they are fixed rules. The three checks each implement an ISO 27001 control (A.9.4.2, A.9.2.6, A.11.2.8 and A.9.4.3).

Why your menu differs from a colleague's

Every item in the admin sidebar is checked server-side against the signed-in admin's own permissions before it's shown — an item the admin's role isn't allowed to use simply isn't rendered, it isn't just hidden or disabled. What permissions a role can hold is itself shaped by the tenant's licence: the licence key lists which modules the tenant has paid for, and that gets synced into the tenant's actual permission set, with anything outside the licensed modules removed. So two admins in the same tenant can see different menus because they hold different roles, and the same role can see different menus in two different tenants if those tenants are on different licences. In short, the menu shows only what your role and your tenant's licence allow.