Users

The Users page is where accounts are created and maintained. It is deliberately thin: a user in CyberGuard is an identity and a set of group memberships, nothing more. Users hold no permissions of their own — everything they can do comes from the user groups they belong to, which is what makes access reviewable.

Where to find it

Organization → Users in the sidebar.

Creating a user

Press Add user and enter the new user’s email. That is the only required field — name, groups and everything else can follow.
Open the new account with edit and set the User groups. A freshly created user has no permissions at all until you do this, and will log in to an empty workspace. If you are running a single domain, Global - Administrator is the pragmatic choice; otherwise grant the narrowest domain group that covers their job.
Let them set their own password. If the mailer is configured, the account receives an email inviting them to choose one.

If mail is not configured, or the invitation never arrives, the edit page offers a link to set a temporary password for local accounts. Use a strong one, hand it over out of band, and tell the user to change it immediately.

The fields

Field	Meaning
Email	The login identity, and where notifications go
First name / Last name	Display name across assignments and audit trails
User groups	Where every permission comes from
IdP groups	Groups synced from your identity provider, when SSO group mapping is in use
Is active	Whether the account can sign in at all
Expiry date	An automatic end date for the account; it cannot be set in the past
Exclude from forced SSO	Lets this account keep using local login when SSO is otherwise mandatory
Is a third party	Marks an external contact rather than an internal colleague
MFA enabled	Read-only indicator of whether the user has a second factor
Observation	Free-text note — why the account exists, who requested it

Exclude from forced SSO is the escape hatch that keeps you out of a lockout: if your identity provider is down and every account is SSO-only, nobody gets in. Keep at least one break-glass administrator excluded, with a strong password and MFA. Expiry date is worth using for contractors and auditors — an account that switches itself off on a known date is one fewer item on a review checklist.

Administrative actions

Deactivating rather than deleting

Clearing Is active stops the account signing in and removes every permission it could exercise, while leaving its history intact — the audits it authored, the controls it owned, the trail it left. Deleting a user is permanent and can disturb existing assignments and records, so deactivation is almost always the right move for a leaver.

Disabling a user’s MFA

If a user has lost every second factor — phone wiped, hardware key gone — and has no recovery codes left, an administrator can clear it for them. Open the user’s edit page and follow the disable their MFA link. All of that user’s authenticators are removed and they are prompted to enrol again on their next login.

The link only appears when all three of these hold: you are an administrator, the account actually has MFA enabled, and it is not your own account. To reset your own MFA, use the MFA settings on your profile instead.

Reviewing access

The list filters and searches by name, email and group, which makes a periodic access review tractable: sort by Is active, check who still holds Global - Administrator, and look for accounts with no groups at all — usually people who were created and then forgotten. For the full picture of who holds which role on which domain, use Role assignments.

User groups — the built-in groups and what each role can do.
Role assignments — the flattened view of effective access.
Domains — the scope every grant is made against.