Summary and recommendation
SentinelOne user management can be run manually, but complexity usually increases with role models, licensing gates, and offboarding dependencies. This guide gives the exact mechanics and where automation has the biggest impact.
SentinelOne's Singularity platform manages console users through Settings > Users at `https://<your-tenant>.sentinelone.net/settings/users`.
Access control follows a hierarchical scope model - Global, Account, Site, and Group - layered on top of role-based permissions.
Every app in your stack that touches endpoint security data will interact with this model, so getting scope assignments right at onboarding prevents access gaps later.
Five built-in roles cover most use cases: Admin, Viewer, IT Operations, SOC, and Custom.
Admins at Account scope can manage all Sites beneath them;
Admins scoped to a single Site cannot.
Custom roles with granular per-feature read/write/execute permissions are available on Singularity Complete or higher - confirm the exact tier with SentinelOne sales before planning a rollout.
Quick facts
| Admin console path | Settings > Users |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | Yes |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Admin | Full access to all console features including policy management, user management, threat response, and account configuration. | Cannot exceed scope of their assigned Site/Account unless granted higher-level access. | Admin role at Account scope can manage all Sites under that account; Admin at Site scope is limited to that Site only. | ||
| Viewer | Read-only access to dashboards, alerts, and reports. Cannot take threat response actions or modify policies. | Cannot remediate threats, modify configurations, or manage users. | Viewer users still consume a named user seat. | ||
| IT Operations | Can manage endpoints, run remote scripts, and perform threat response actions. Cannot manage users or account-level settings. | Cannot create or modify user accounts or change account-level policies. | |||
| SOC | Focused on threat detection and response: can view and respond to threats, run investigations. Limited configuration access. | Cannot manage users, endpoints enrollment, or account-level settings. | |||
| Custom Role | Granular permissions configured by an Admin; can combine read/write/execute permissions across specific feature areas. | Cannot exceed the permissions of the Admin who created the role. | Singularity Complete or higher (exact tier not confirmed in public docs; feature availability varies by contract) | Custom roles are scoped to the Account or Site level at creation time; scope cannot be changed after assignment. |
Permission model
- Model type: hybrid
- Description: SentinelOne uses a hierarchical scope model (Global > Account > Site > Group) combined with role-based access control. Built-in roles (Admin, Viewer, IT Operations, SOC, etc.) are available at all tiers. Custom roles with granular permission sets are available on higher tiers. Each user is assigned a role plus a scope level, and their effective permissions are the intersection of role permissions and scope.
- Custom roles: Yes
- Custom roles plan: Singularity Complete or higher (exact tier not publicly confirmed; verify with SentinelOne sales)
- Granularity: Per-feature read/write/execute permissions assignable at Global, Account, Site, or Group scope.
How to add users
- Log in to the Singularity management console as an Admin.
- Navigate to Settings > Users.
- Click 'New User' or 'Invite User'.
- Enter the user's email address, first name, and last name.
- Select the user's Role from the dropdown.
- Select the Scope (Account or Site) the user should have access to.
- Optionally set two-factor authentication requirements.
- Click 'Save' or 'Send Invitation'. The user receives an email invitation to set their password.
Required fields: Email address, First name, Last name, Role, Scope (Account or Site)
Watch out for:
- The inviting Admin can only grant roles up to their own permission level; they cannot create users with higher privileges than themselves.
- Users must accept the email invitation before they can log in; pending invitations can be resent from the Users list.
- If SSO is enforced on the tenant, locally-created users may be blocked from password-based login depending on SSO enforcement settings.
- Two-factor authentication enforcement is a tenant-level or user-level setting and may be mandatory depending on account policy.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | SCIM provisioning requires Singularity Enterprise tier and an SSO prerequisite; SAML-based JIT provisioning may be available on lower tiers depending on contract. |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: SentinelOne supports both deactivating (revoking access while retaining the user record) and deleting user accounts from the console. Deletion removes the user record permanently. Official documentation describes a 'Revoke' or 'Delete' action available from the Users list for Admin-level users.
- Navigate to Settings > Users.
- Locate the user in the list.
- Click the action menu (three dots or right-click) next to the user.
- Select 'Revoke Access' to deactivate, or 'Delete' to permanently remove the user.
- Confirm the action in the dialog prompt.
| Data impact | Behavior |
|---|---|
| Owned records | Threat events, alerts, and audit log entries created by the user are retained and remain associated with the user's name/ID in historical records. |
| Shared content | Custom rules, exclusions, or policies created by the user remain in place and are not automatically removed when the user is deleted. |
| Integrations | API tokens issued to the user are invalidated upon deletion; any integrations using those tokens will stop functioning. |
| License freed | Removing or revoking a user frees the named-user seat, making it available for reassignment. Seat count changes may take effect at next billing cycle depending on contract terms. |
Watch out for:
- Deleting a user is irreversible; the user record cannot be restored after deletion.
- API tokens associated with a deleted user are immediately invalidated; dependent integrations must be reconfigured with a new token.
- An Admin cannot delete their own account; another Admin must perform the deletion.
- If the user is the sole Admin on an Account or Site, deletion may be blocked until another Admin is assigned.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Endpoint License | Per-endpoint protection license covering the selected Singularity tier (Core, Control, Complete, Commercial, or Enterprise). Console user seats are not separately licensed per user in the standard model; user accounts are included with the endpoint subscription. | $45–$229.99/endpoint/year depending on tier; Enterprise is custom-priced. |
- Where to check usage: Settings > Licenses (or Account > License Usage depending on console version); shows total licensed endpoints, consumed seats, and expiration dates.
- How to identify unused seats: Navigate to Settings > Users and filter by 'Last Login' date to identify users who have not logged in recently. No automated unused-seat report is documented in official public docs.
- Billing notes: SentinelOne licenses are sold per endpoint per year, not per console user. Console user accounts (admin/viewer/etc.) are not individually metered in the standard licensing model. SCIM/SSO features require Enterprise tier. Pricing is typically negotiated annually through SentinelOne sales or channel partners.
The cost of manual management
Console user accounts are not individually metered - licensing is per endpoint per year, ranging from $69/endpoint (Singularity Core) to $179.99/endpoint (Singularity Complete) and custom pricing at Enterprise. Typical annual spend runs $30K–$110K depending on fleet size and tier.
The real cost of manual user management is operational. Bulk CSV import is not supported, so every new hire requires individual console steps: navigate to Settings > Users, click New User, fill required fields (email, first name, last name, role, scope), and wait for the user to accept an email invitation before access is live.
Pending invitations do not expire automatically and accumulate in the Users list, requiring periodic manual cleanup.
Viewer users still consume a named seat even though they cannot take any action on threats. Auditing for unused accounts means manually filtering the Users list by Last Login - no automated unused-seat report is documented in official public sources.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Manual management in SentinelOne is workable for small, stable teams but degrades quickly at scale. The absence of bulk import, combined with invitation-based onboarding and no automated seat auditing, means every app added to your environment multiplies the per-user overhead.
SCIM provisioning via Okta is the documented path to automated lifecycle management, but it requires Singularity Enterprise tier and a fully configured SAML SSO setup as a prerequisite - both of which represent meaningful procurement and configuration investment. If your organization is not yet on Enterprise, manual management is the only option.
For teams already on Enterprise with Okta, SCIM eliminates the invitation flow and keeps deprovisioning consistent. For everyone else, the manual process is functional but requires discipline around invitation cleanup, scope assignment, and offboarding sequencing.
Bottom line
SentinelOne's console user management is role-based and scope-layered, which gives precise control but demands careful setup - especially across multi-site deployments. Manual onboarding works for small teams;
the lack of bulk import and automated seat auditing makes it operationally expensive at scale. SCIM via Okta solves the lifecycle problem cleanly, but only if you're on Singularity Enterprise with SSO already live.
Every app that depends on SentinelOne access will feel the friction of manual management until that automation is in place.
Automate SentinelOne workflows without one-off scripts
Stitchflow builds and maintains end-to-end IT automation across your SaaS stack, including apps without APIs. Built for exactly how your company works, with human approvals where they matter.
