Summary and recommendation
Tanium 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.
Tanium user management lives at Administration > Permissions > Users inside the Tanium Console.
Access is governed by a hybrid RBAC model: effective permissions are the intersection of assigned roles and assigned computer groups, so neither alone is sufficient.
This applies to every app user type - Administrator, Operator, Read Only, and Custom roles all require both dimensions to be configured before access is meaningful.
Quick facts
| Admin console path | Administration > Permissions > Users |
| Admin console URL | Official docs |
| SCIM available | Yes |
| SCIM tier required | Tanium Cloud |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Administrator | Full access to all Tanium Console features, modules, user management, system configuration, and all computer groups. | Tanium recommends limiting the number of Administrator accounts; the built-in 'tanium' service account should not be used for day-to-day administration. | |||
| Operator (Persona Role) | Can run questions, deploy actions, and use assigned Tanium modules within assigned computer groups. | Cannot manage users, modify system configuration, or access computer groups outside their assignment. | Effective permissions are the intersection of assigned roles AND assigned computer groups; a role alone does not grant access without a matching computer group assignment. | ||
| Read Only (Persona Role) | Can view results, dashboards, and reports within assigned modules and computer groups. Cannot execute actions or questions. | Cannot deploy actions, run questions, or modify any configuration. | |||
| Custom Role | Granular permissions defined by administrator across modules, features, and computer groups. | Permissions are limited to what the creating administrator explicitly grants. | Custom roles must be paired with computer group assignments to be effective. |
Permission model
- Model type: hybrid
- Description: Tanium uses a role-based access control (RBAC) model combining predefined persona roles (e.g., Administrator, Operator, Read Only) with custom roles. Permissions are further scoped by computer group assignments and module-level feature flags. Effective access = role permissions ∩ computer group scope.
- Custom roles: Yes
- Custom roles plan: Not documented
- Granularity: Module-level, feature-level within modules, and computer group scope. Roles can be configured with read, write, and execute permissions per Tanium module feature.
How to add users
- Log in to the Tanium Console as an Administrator.
- Navigate to Administration > Permissions > Users.
- Click 'New User'.
- Enter the required user details (username, display name, password for local accounts).
- Assign one or more roles to the user.
- Assign one or more computer groups to scope the user's access.
- Optionally assign the user to a persona role.
- Click 'Save' to create the user.
Required fields: Username, Password (for local accounts), At least one role assignment, At least one computer group assignment
Watch out for:
- Users created without a computer group assignment will have no effective access even if roles are assigned.
- For LDAP/AD-synced users, the password field is managed by the directory; local password is not set.
- SAML-authenticated users are provisioned on first login if SAML is configured; they still require role and computer group assignment in Tanium before or after first login.
- Tanium does not natively support SCIM auto-provisioning of role/computer group assignments; those must be configured manually or via LDAP group mapping.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | No | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Tanium Cloud (Enterprise); LDAP/AD sync available on-premises; SAML available on both deployment types |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: Tanium Console allows administrators to delete local user accounts from Administration > Permissions > Users. LDAP-synced users can be disabled by removing them from the synced directory group or by deleting them directly in the Tanium Console. There is no documented 'deactivate/suspend' state separate from deletion for local accounts.
- Navigate to Administration > Permissions > Users.
- Locate the user account.
- Select the user and click 'Delete' (for local accounts), or remove the user from the LDAP group that grants Tanium access (for directory-synced accounts).
| Data impact | Behavior |
|---|---|
| Owned records | Saved questions, actions, and content created by the deleted user remain in the system and are not automatically removed. |
| Shared content | Shared dashboards and content created by the user persist and remain accessible to other users with appropriate permissions. |
| Integrations | Not documented |
| License freed | Tanium licensing is endpoint-based (per managed endpoint), not per named user seat; deleting a user does not directly free a license unit. |
Watch out for:
- Tanium licensing is priced per endpoint, not per user; removing users does not reduce endpoint license consumption.
- Deleting an LDAP-synced user in the Tanium Console does not remove them from the directory; they may be re-provisioned on next LDAP sync if still present in the synced group.
- There is no documented account lock-out or suspension state for local users; the primary options are deletion or role/group removal to revoke access.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Endpoint License | Access to Tanium platform and modules for a managed endpoint device. User accounts are not individually licensed. | Custom pricing, approximately $20+ per endpoint per year (varies by module bundle and contract). |
- Where to check usage: Administration > Licensing (within Tanium Console) shows endpoint counts and module entitlements.
- How to identify unused seats: Tanium does not provide a native 'inactive user' report in the console. Endpoint activity and last-seen data are available via Tanium Interact queries against the managed endpoint fleet, not user login activity.
- Billing notes: Tanium is sold as an endpoint platform license, not a per-user SaaS seat model. The number of Tanium Console user accounts does not directly affect billing. Module access is governed by which modules are licensed in the contract.
The cost of manual management
Tanium is licensed per endpoint, not per user seat, so adding or removing console accounts has no direct billing impact.
However, the absence of a native inactive-user audit report means periodic access reviews require manual effort - administrators must run Tanium Interact queries against the endpoint fleet to surface activity data, since user login timestamps are not surfaced in a dedicated console report.
For SAML-provisioned users, role and computer group assignments must still be completed manually inside Tanium after first login, which adds overhead to every IdP-driven onboarding workflow.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Manual management is viable for small, stable teams where computer group scoping is straightforward and access reviews are infrequent. It becomes operationally expensive as headcount grows, because every new user requires role assignment, computer group assignment, and - for SAML users - a post-login configuration step.
Teams with compliance obligations around access reviews face additional manual effort given the lack of a native inactive-user report. Organizations running Tanium Cloud (Enterprise) should evaluate SCIM provisioning to reduce per-user setup overhead, with the caveat that SCIM group mappings cover computer groups but not role assignments.
Bottom line
Tanium's RBAC model is precise but requires two correctly configured dimensions - roles and computer groups - for every app user before access takes effect.
The per-endpoint licensing model means user account hygiene is a security and compliance concern rather than a cost one, but the absence of native inactive-user reporting makes that hygiene harder to maintain at scale.
Teams that invest in mapping their IdP groups to Tanium computer groups via SCIM will reduce provisioning friction, but role assignment remains a manual step that no current native integration fully automates.
Automate Tanium 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.
