Adding operators and managing access

Operator accounts are created by invitation rather than self-registration. An administrator issues an invite against an email address; the recipient sets their own password on acceptance. This means no administrator ever knows an operator password, and the audit trail records who granted access to whom.

Issue invitations against individual named addresses. Shared operator accounts — a single "support@" login used by a team — break every downstream guarantee the platform offers. Remote terminal sessions are bound to the operator identity, credential vault reveals are recorded against it, and the audit log attributes actions to it. A shared account turns all of that into "someone on the support team did this", which is worth very little during an incident review and less during an audit.

Scope operators to the clients they actually work on. The client/site structure is not only an organisational convenience; it is the boundary that reporting, dashboards and exports respect. An operator who covers three accounts does not need visibility across forty.

When someone leaves, revoke the account rather than changing its password. Revocation preserves the historical audit trail intact while ending access; recycling the account to a new joiner permanently muddies attribution for everything that account did previously.

Review the operator list on a schedule you actually keep. Quarterly is realistic for most teams. The review that matters is not "does this person still work here" — HR will tell you that — but "does this person still need this level of access", which nobody will tell you unless you ask.