Staff

Platform → Staff is the accounts that can use this console, and the roles they hold.

MFA enabled: no means the account cannot sign in

MFA is mandatory for staff, so that column is not a preference — it is whether the account works. A new hire who has not enrolled yet is pending and unusable, which is the normal first state and is said in words rather than as an unchecked box.

See Signing in.

Roles shown are the effective ones

Lapsed grants are excluded, so a row showing no roles means that account can reach one page of this console. That is the same state the dashboard’s “your account has no roles yet” panel is written for, and the two agree.

Two tabs, because people and roles are edited by different people

Tab	How often
Users	Granting somebody the compliance role is routine and happens weekly.
Roles	Changing what the compliance role means is rare, affects everybody holding it at once, and deserves a change note.

Two tabs rather than one screen, so the second is never reached by accident while doing the first.

A staff account

Fact	Notes
Status	—
MFA	Whether the account can sign in at all.
Last signed in	—
Created	—
Must change password	—
Networks	Any network restriction on the account.
Roles	Effective roles, or No roles.
Super admin	Flagged where it applies.

Your own account is labelled this is your own account, because several of the actions below behave differently on it.

Setting a status

“Takes effect immediately. Anything other than active or pending signs them out of every session.”

Field	Notes
Status	“Suspended is reversible and is the right choice while something is being investigated. Terminated says they have left.”
Reason	“Recorded in the audit log, and read by whoever reviews account changes.”

A panel warns when the change will sign them out of every session.

Suspend while you investigate. Terminate when the facts are settled — it is the status that says the relationship ended, and an audit trail reads very differently when somebody was terminated on the day of an incident versus suspended during it.

Granting a role

“Takes effect immediately. You cannot grant a permission you do not hold yourself.”

Field	Notes
Role	—
Expires	“After this the grant row remains and confers nothing.”
Reason	“Why this account needs this role.”

Use an expiry for temporary access

Cover for leave, a contractor, an incident response — all of them should expire on their own. Audit → Grants lists what is about to lapse, and a lapsed grant already confers nothing.

Access granted “for now” with no expiry is access nobody ever removes.

The “you cannot grant what you do not hold” rule is the containment on this page: it means no account can escalate itself or anybody else beyond its own reach.

Revoking a role

“Takes effect immediately. Any permission this role carried that no other role gives them is gone.”

Field	Notes
Reason	“Why this access is being withdrawn.”

Read that first sentence carefully: somebody holding two overlapping roles keeps whatever the other one gives them. If you are removing access after an incident, check the remaining roles rather than assuming.

Rebinding somebody’s authenticator

Rebind authenticator on their row: “Lets them enrol a new authenticator. Use when a device has been lost or replaced.”

This one is dual controlled. It raises an approval request and changes nothing by itself. The person being rebound can never approve it, so nobody can clear their own authenticator.

Field	Notes
Your authenticator code	“Proves you are still the person who signed in. A recovery code is not accepted here.”
Reason	“Read by the approver before they decide, and by whoever investigates later. Say how you know the device is genuinely gone.”

Once approved, their authenticator and recovery codes are removed and every session they hold is ended, so they enrol a new authenticator at their next sign-in. A panel states what it does not do: “This does not change their password”. If they have also lost that, reissue it as well.

When the only other active account is theirs, a request could never be decided. The form then shows “Nobody else can decide this” with Authorise it myself. Ticked, the rebind happens at once and is recorded as self-authorised. Once a third active account exists, a colleague has to decide it in Approvals instead. From the API: self_authorise: true on DELETE /v1/users/{id}/mfa, which is refused with 403 whenever a colleague could decide it.

This is the most socially engineerable action on the console

A phone call from “a colleague locked out before a meeting” is exactly what this request looks like from the inside. That is why it needs two people, a step-up code from the requester, and a reason that says how you know the device is gone.

Verify the person through a channel you already trust. Not the one the request arrived on.

Creating an account

Field	Notes
First name / Last name	—
Email	“Their username, and where security notices go.”
Phone	E.164. “For reaching them about an account problem, not for MFA.”
Initial password	“Generated rather than chosen. It is handed over out of band and changed at first sign-in, so it is a delivery mechanism rather than a password.”
Allowed networks	CIDRs, one per line or comma-separated.
Roles	Can be granted at creation or afterwards.
Authorised by	The second operator this is recorded against. The change is held until they approve it in Approvals.
Reason	“Read by the approver before they decide. Who this person is and what they are here to do.”

Do not send the initial password to the email it signs in with

“Give this to them in person, by phone, or through a channel that is not the email address it signs in with.” A password mailed to the account it unlocks means one compromised inbox is one compromised console account.

Allowed networks lock out the person who cannot fix it

“Getting these wrong locks the account out, and it is the account holder who discovers that” — on their first sign-in, usually from the office you did not list. Confirm the ranges with whoever runs the network before you save, not after.

The account arrives unable to sign in until the person enrols an authenticator. That is expected — tell them to expect it.

Reissuing somebody’s password

The initial password is shown once. This console sends no email, so if it is lost before it reaches the person it belongs to, there is nothing in their inbox to fall back on — reissue it from their row in the staff list.

Field	Notes
New password	Generated, not chosen. Copy it before you submit; it is shown once more and never again.
Authorised by	The second operator this is recorded against. The password is reissued when they approve it in Approvals; until then the dialog says “Sent for approval — nothing has changed yet”. The person whose password it is is never listed. While no active account exists other than yours and theirs, you may name yourself: it is reissued at once and recorded as self-authorised.
Reason	Which case this is: the first one was lost, they are locked out, they have forgotten it.

It does three things and no more: sets the password, forces them to change it at their next sign-in, and signs them out of every session. It does not activate a pending account and does not enrol an authenticator, so the confirmation names whatever is still in the way.

On an account that has signed in before, this is a takeover

An account that has signed in has a password its holder chose and knows. Replacing it ends every session they hold and means you know a working credential for their account — recorded in the audit log against your name. That is legitimate for somebody locked out or somebody who has left. It is not the case this exists for, and the form says so before you submit.

Same rule as the first password: not to the email it signs in with

Hand it over in person, by phone, or through a channel that is not the address the account signs in with.

Roles

A role is “a named set of permissions that can be granted to staff accounts.”

Field	Notes
Code	“Permanent. Other code refers to roles by this, so choose carefully.”
Name	—
Description	What this role is for.
Permissions	The set it carries.
Reason	“Why this role’s reach is changing.”

A system role’s permissions cannot be changed. The panel says so where it applies; those roles are part of the platform’s own definition.

Editing a role changes everybody who holds it, at once

Adding a money permission to a role held by twelve people grants it to twelve people, immediately, with no further approval. Check who holds a role before you widen it — and prefer creating a narrower new role over widening a popular one.

Reviewing access

Quarterly, and after anybody leaves:

1. Users — anybody with no roles who should have some, or roles they no longer need?
2. Anybody terminated who still holds grants?
3. Audit → Grants — what is about to lapse, and should it be renewed?
4. Audit → Refused — clusters that mean a role is missing something, or an account is probing.
5. Roles — does each role still carry only what its name implies?