Skip to main content

Users and Groups

The Users page (Dashboard > Users) is the directory of every employee Surface Security knows about, together with their enrollment state and a per-user security profile. The Groups page (Dashboard > Groups) organizes those users into groups — synced from your identity provider or created by hand — so you can scope security policies to teams instead of individuals.

Together they answer two everyday questions: who is covered by Surface Security, and what does each person's credential hygiene actually look like?

Screenshot

[SCREENSHOT PLACEHOLDER: Users page showing the user table with search box, the All / Pending / Enrolled / Stale status filter chips, and the Sync Users, Bulk Import, and Add User buttons in the header]

How users get into the system​

There are three ways a user record is created. They can be combined freely — a directory-synced user and a self-enrolled user look the same once they exist.

MethodHow it worksBest for
Directory syncUsers and groups are provisioned automatically from Microsoft Entra ID or Okta (SCIM push), Active Directory (LDAP pull), or Google Workspace. Configured under Settings > Directory Sync.Most organizations — keeps the roster current without manual work
Manual entryAdd User creates a single user (email, display name, department, job title). Bulk Import accepts a CSV file with the columns email,display_name,department,job_title.Small teams, pilots, contractors outside the directory
Extension enrollmentWhen an employee enrolls their browser extension (for example through an SSO magic link), a user record is created automatically from their verified identity if one does not already exist.Zero-touch rollouts where the extension arrives before the roster

For directory sync setup, see the Directory Sync guide. For extension rollout options, see Extension Deployment.

A user record on its own is just an entry in the roster. Security telemetry starts flowing once that user's browser extension enrolls — which is why every user carries an enrollment status.

Using the Users page​

The table shows one row per user with these columns:

  • User — avatar, display name, and email. Click through to the user detail page.
  • Department — from the directory or manual entry.
  • Status — the account state: active, inactive, or suspended.
  • Last Seen — the most recent activity from any of the user's enrolled devices.
  • Role — Admin or User (whether the person can sign in to this dashboard).
  • Status (enrollment) — one of four badges:
    • Pending enrollment — the user exists but no browser extension has enrolled yet.
    • Enrolled — at least one active extension is reporting for this user.
    • Stale — the user's devices have stopped checking in.
    • Revoked — the user's device access has been revoked.

Above the table:

  • Search users by name or email... filters the roster.
  • The All / Pending / Enrolled / Stale filter chips narrow the list by enrollment state — the fastest way to find everyone who still needs the extension installed.
  • Sync Users triggers an immediate directory sync when a directory source is configured. If none is configured yet, the button reads Setup Directory Sync and links to the settings page.
  • Row checkboxes enable Delete Selected for bulk cleanup. Deletion is permanent and confirmed with a dialog.

The user detail page​

Clicking a user opens User Details, the per-user security profile. Besides the profile card (name, email, account status, admin badge) and the Edit User / Delete User actions, the page has five sections:

Personal Information and Account Information — email, department, job title, an external directory ID when the user came from directory sync, creation date, and Last Seen.

Groups — every group the user belongs to, with an Edit Groups dialog to change memberships directly. Clicking a group chip jumps to that group's page.

Credential Security — the core risk view for the user:

  • Four stat cards: Credentials (distinct username-plus-password fingerprints observed), Pwned (credentials found in known breach data), Reused (the same password used across multiple sites), and Auth Endpoints (distinct login services used).
  • A Credentials table listing each username, its status badges — Pwned (with an approximate breach-count bucket) and Reused (with a reuse count) — the primary login endpoint, total uses, and last use. Expanding a row breaks usage down per endpoint.
  • Recent Credential Reuse Attempts — individual incidents where a corporate credential was entered on an unauthorized site, showing the source site, the target site, the action taken (for example warned or blocked), and when.

Remember that Surface Security never sees passwords — these signals are computed from one-way fingerprints generated on the endpoint.

Authentication Endpoints — every login service this user authenticates to, with columns for Origin, MFA (Enabled / Disabled / Pending), MFA Type (for example passkey or TOTP), IDP (the identity provider detected), Last Login, and Logins (count). This is where you spot a user signing in to an important service without MFA. Rows click through to the endpoint's own detail page.

AI Activity — a timeline of the user's interactions with generative AI applications, including the domain, the app, the content type involved, and any policy action taken.

Screenshot

[SCREENSHOT PLACEHOLDER: User detail page scrolled to the Credential Security section, showing the four stat cards and a credentials table with one Pwned badge and one Reused badge visible]

Using the Groups page​

Dashboard > Groups lists every group with its Name, Source, Members count, Policies count, and creation date. The Source badge distinguishes Manual groups (created in the dashboard) from directory-synced groups (badged with the source name, for example your Entra ID connection).

  • Add Group creates a manual group (name, display name, description).
  • Sync Now appears when a directory source is configured and pulls the latest groups and memberships on demand.
  • Edit and Delete act on individual groups. Deleting a group removes its members from the group, and any policies scoped only to that group stop applying to them.

Group detail​

Clicking a group opens its detail page (reached under Users > Groups), which shows:

  • Members — the current member list with Add Members (search users by name or email) and per-row Remove actions.
  • Policies — the security policies scoped to this group, with their priority and enabled state. Policies are assigned from the Policies page, not here; this section is the read-only view of what applies.

Directory-synced groups can be edited like manual ones, but the next sync from your identity provider is the source of truth for memberships — make membership changes in the directory for synced groups.

Screenshot

[SCREENSHOT PLACEHOLDER: Group detail page showing the Members table and the Policies section with two policies scoped to the group]

Worked example: chasing down a risky user​

Your alerts page shows repeated password-reuse alerts for the same person. Here is the triage flow:

  1. Open Dashboard > Users and search for the user by name.
  2. On their detail page, check Credential Security. The stat cards show 2 reused credentials and 1 pwned credential.
  3. Expand the pwned credential's row. The breakdown shows the same username and password fingerprint used on your corporate SSO and on two personal sites — and the breach-count bucket indicates the password appears widely in breach data.
  4. Check Authentication Endpoints: the corporate IdP row shows MFA Disabled.
  5. Action: force a password reset through your IdP, require MFA enrollment, and check Recent Credential Reuse Attempts to confirm whether the reuse was warned or blocked at the time.
  6. Optionally, add the user's department group to a stricter policy from the Policies page so warnings become blocks for that team.

This whole investigation happens on one page — no log spelunking required.

Troubleshooting​

A user shows "Pending enrollment" even though they installed the extension. The extension enrolls under the identity the user authenticated with. If they signed in with a different email address than the one on the roster, a second user record may have been created. Search for their name to find both, and standardize on the directory email.

Sync Users did not remove someone who left the company. Deprovisioning behavior depends on the directory source and its settings. Check the source's configuration under Settings > Directory Sync, or remove the user manually. Also revoke their devices from the Devices page.

A group's policy is not applying to a member. Confirm the user actually appears in the group's Members list (sync timing can lag), and remember that when several policies apply, the most restrictive action wins — check the Policies page for overlapping scopes.

Deleted users' history. Deleting a user removes the roster entry. Do this only after offboarding is complete; prefer setting the account status to inactive or suspended if you need to keep the profile visible.