Summary and recommendation
Cyberhaven 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.
Cyberhaven is an enterprise data security platform sold under custom contracts.
It does not offer native SCIM provisioning, and no publicly documented self-service user management workflow exists.
When every app in your environment needs a consistent provisioning story, Cyberhaven's console-only model stands out as a manual gap that requires direct vendor involvement to close.
Quick facts
| Admin console path | Administration / Settings > Users and Roles (exact labels vary by tenant) |
| SCIM available | No |
| SCIM tier required | N/A |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Administrator | Can manage tenant settings, policies, integrations, and portal user access. | Cannot change the underlying corporate identities outside the Cyberhaven tenant. | Detailed built-in role names are not fully documented in public sources. | ||
| Analyst / Operator | Can work with policies, incidents, and investigative workflows exposed to their role. | May not be able to manage tenant configuration or other users. | Exact privileges can vary by module and tenant configuration. |
Permission model
- Model type: role-based
- Description: Cyberhaven appears to use role-based access within the admin console, but the detailed permission matrix is not publicly documented in full.
- Custom roles: Unknown
- Custom roles plan: Not documented
- Granularity: Expect separation between tenant administration and operational workflows, with exact scopes configured in the tenant.
How to add users
- Log in to Cyberhaven as an administrator.
- Open the administration or settings area and navigate to users.
- Choose the add or invite user action.
- Enter the user's work email and assign the appropriate role.
- Save the user and complete any SSO or activation steps required by the tenant.
Required fields: Work email address, Role
Watch out for:
- Public docs do not fully document the invite workflow, so exact labels may vary.
- If SSO is enabled, upstream IdP assignment may still be required.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Unknown | Not documented |
| Domain whitelisting | Unknown | Automatic domain-based user add |
| IdP provisioning | Unknown | Not documented |
How to remove or deactivate users
- Can delete users: Unknown
- Delete/deactivate behavior: Public documentation does not clearly state whether Cyberhaven users are disabled, deleted, or both. Treat lifecycle behavior as tenant-specific unless confirmed in-product.
- Open the Cyberhaven users area as an administrator.
- Locate the user to offboard.
- Disable, revoke, or remove the account using the controls available in that tenant.
- Review any integrations, policies, or tokens associated with the departing admin.
| Data impact | Behavior |
|---|---|
| Owned records | Policies, incidents, and tenant data remain in the workspace; public docs do not describe user-owned object semantics in detail. |
| Shared content | Shared dashboards and policy configurations remain tenant assets unless separately changed. |
| Integrations | Review API keys, service accounts, and integration ownership separately during admin offboarding. |
| License freed | Seat reuse behavior is contract-dependent and not publicly documented in detail. |
Watch out for:
- Offboarding should include integration and token review, not just interactive access removal.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Named tenant user | Administrative or analyst access to the Cyberhaven tenant. |
- Where to check usage: Administration / Settings > Users and Roles
- How to identify unused seats: Review the user list and any visible activity metadata in the tenant. No public unused-seat report was verified.
- Billing notes: Cyberhaven is sold as an enterprise product with custom pricing. Public seat-level billing details are not documented.
The cost of manual management
Because Cyberhaven lacks native SCIM or a public provisioning API, onboarding and offboarding require direct console intervention, which compounds access review overhead at scale. Seat-level billing details are not publicly documented, making it difficult to audit unused licenses without vendor involvement. Teams with frequent user changes will absorb that operational cost continuously.
The decision
When every app in your stack is evaluated for automated lifecycle management, Cyberhaven's current feature set introduces a manual gap that carries real access-risk exposure. Teams managing a large or frequently changing user base should raise SCIM roadmap status directly with their Cyberhaven account team before committing to a provisioning workflow.
Pricing is enterprise-only with custom contracts; no self-serve tier exists to test provisioning behavior independently.
Bottom line
Cyberhaven is a capable enterprise data security tool, but its user lifecycle management story is largely undocumented and appears to be console-only with no confirmed SCIM or public API support.
Organizations with strict joiner-mover-leaver requirements should treat manual provisioning as the current baseline and proactively engage Cyberhaven's team to understand what programmatic options, if any, are available under their contract.
Automate Cyberhaven 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.
