Admin Users & Roles

The Admin Users page (Settings > Admin Users) is where you manage the people who operate the Surface Security console: create administrator accounts, assign roles, enforce multi-factor authentication, reset passwords, and unlock or deactivate accounts. Console administrators are separate from the employee users whose browsers you protect — admins sign in to the dashboard; users are the monitored population synced from your directory.

Access is role-based. Every admin account has exactly one role, and the role determines both which navigation each admin sees and which actions the server will accept from them. Permissions are enforced on the server, not just hidden in the interface.

Screenshot

[SCREENSHOT PLACEHOLDER: The Admin Users page showing the table with User, Role, MFA, Status, and Last Login columns, the "Require MFA for all admins" banner, and the Add Admin button]

The roles

Surface Security ships five built-in roles:

Role	Intended for	Summary
Super Admin	Platform owners	Full system access, including managing other admin accounts
Admin	Security engineers	Full access to tenant data, alerts, users, policies, and settings — everything except admin account management
Analyst	SOC analysts	View and triage alerts; read-only access to users, devices, and the attack surface
Executive	Leadership	Full data visibility with a simplified navigation focused on dashboards, alerts, and reports
Viewer	Auditors, read-only stakeholders	Read-only access to dashboards, alerts, users, and the attack surface

Permission and visibility matrix

What each role can see and do, by area of the console:

Area	Super Admin	Admin	Analyst	Executive	Viewer
Dashboard	Full	Full	View	View	View
Alerts (acknowledge / investigate / resolve)	Yes	Yes	Yes	Yes	View only
Campaigns and Events	Yes	Yes	Yes	Yes (Events)	View
Users, Groups	Manage	Manage	View	View	View
Devices	Manage	Manage	View	View	Hidden
Attack Surface (endpoints, extensions, credentials, OAuth consents)	Manage	Manage	View	View	View
Domain Scopes / Protected Domains	Manage	Manage	Hidden	Hidden	Hidden
Policies and Policy Review	Manage	Manage	Hidden	Hidden	Hidden
Reports	Full	Full	View	Full	Hidden
Settings (general, SSO, integrations)	Full	Full	Hidden	Hidden	Hidden
Audit Log	Yes	Yes	Yes	Yes	Hidden
Admin user management	Full	Hidden	Hidden	Hidden	Hidden

Notes on the navigation each role experiences:

• Executive gets a deliberately short sidebar — Dashboard, Alerts, Events, Reports — plus a collapsible Advanced Options group that exposes the read-oriented pages (AI Usage, Users, Groups, Devices, Extensions, Attack Surface, Credentials, Audit Log) without cluttering the default view.
• Analyst sees the operational pages (alerts, users, devices, attack surface, audit log) but no policy or settings pages.
• Viewer cannot be selected when creating an admin account from this page; it exists primarily as the safe default for admins provisioned automatically through SSO role mapping.
• Only Super Admins can view and manage the Admin Users page itself, assign the Super Admin role, reset other admins' passwords, and change the tenant-wide MFA requirement.

Using the page

Adding an admin

1. Click Add Admin.
2. Enter the email address and display name, and pick a role (Analyst is pre-selected; Viewer is not offered here).
3. On creation, a one-time temporary password is displayed. Share it with the new admin over a secure channel — it is shown only once.
4. The new admin must change the password on their first sign-in (their row shows a Password Reset Required badge until they do).

Screenshot

[SCREENSHOT PLACEHOLDER: The Add Admin dialog with email, display name, and role fields, followed by the temporary password modal]

Changing a role

Click the role badge on any row (other than your own) to open an inline role dropdown, pick the new role, and confirm. Admins who are not Super Admins cannot grant the Super Admin role.

Row actions

Actions appear on each row for admins with management rights (never on your own row):

• Reset Password & MFA (Super Admin only) — generates a new one-time temporary password. If the admin had MFA enrolled, it is also reset and they must re-enroll.
• Unlock User — shown when an account status is locked; restores the ability to sign in.
• Deactivate User — the account keeps its history but can no longer sign in.

Requiring MFA for all admins

Super Admins see a banner above the table with a Require MFA for all admins checkbox and a live counter of how many admins already have MFA or SSO enabled. Toggling it opens a Confirm Setting Change dialog that asks for your password before the change is applied. Once required, admins without MFA are prompted to enroll.

MFA for administrators

Each admin enrolls their own authenticator from Settings > Security:

1. Click the MFA setup action to generate a QR code.
2. Scan it with any TOTP authenticator app and enter the 6-digit code to verify.
3. Download or copy the one-time backup codes and store them safely — each code works once.

After enrollment, sign-in adds a code prompt following the password step. MFA can be disabled from the same page by confirming your password. The MFA column on the Admin Users page shows each admin's state:

• Enabled — authenticator app enrolled
• Disabled — no second factor
• SSO — the account signs in through your identity provider, so MFA is governed by the IdP rather than a local authenticator

Screenshot

[SCREENSHOT PLACEHOLDER: The Settings > Security page mid-enrollment, showing the QR code, verification code field, and the backup codes download step]

Sessions and lockout

• Session lifetime. Console sessions are valid for 24 hours. A refresh token renews the session silently while the console is in use; when refresh fails, you are signed out and returned to the login page.
• Sign-out. Logging out revokes the session on the server, not just in the browser.
• Re-authentication. Sensitive changes (such as the MFA requirement toggle) prompt for your password again even inside a valid session, and the confirmation is only valid for a few minutes.
• Failed logins. Repeated failed password attempts (five by default) lock the account, with escalating lockout durations: 5 minutes for the first lockout, 15 minutes for the second, and 1 hour thereafter. Locked accounts show a locked status and can be released early with Unlock User.
• The table's Last Login column shows each admin's most recent successful sign-in, which is useful for spotting dormant accounts to deactivate.

Worked example: onboarding a SOC analyst

Your organization hires a new analyst, Dana, who should triage alerts but never touch policies or settings.

1. A Super Admin opens Settings > Admin Users and clicks Add Admin.
2. Enters dana@example.com, display name "Dana Reyes", role Analyst, and creates the account.
3. Copies the temporary password from the modal and sends it to Dana through the corporate password manager.
4. Dana signs in, is forced to set a new password, then enrolls MFA under Settings > Security and stores her backup codes.
5. Dana's sidebar now shows Dashboard, Alerts, AI Usage, Users, the Attack Surface pages, and the Audit Log — no Policy or Settings sections. She can acknowledge, investigate, and resolve alerts, but any attempt to modify configuration is rejected by the server.

FAQ

Can an Admin create other admins? No. Admin has full control of tenant data and settings, but admin account management (create, role changes, password resets, deactivation) is reserved for Super Admins.

Why can't I pick Viewer when adding an admin? Viewer is intentionally excluded from manual account creation. Use it through SSO role mapping (or as the SSO default role) for automatically provisioned read-only access.

What happens to an admin's MFA when I reset their password? The reset also clears their MFA enrollment, and the confirmation dialog warns you about this. They sign in with the new temporary password and re-enroll.

We use SSO — do local passwords still matter? Accounts provisioned through SSO show the SSO badge and authenticate against your identity provider. Keep at least one local Super Admin with a strong password and MFA as break-glass access in case the IdP is unavailable — see Single Sign-On.