Summary and recommendation
OpenText ArcSight 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.
OpenText ArcSight ESM manages users through a hybrid permission model combining role-based access control (RBAC) and Access Control Lists (ACLs).
Roles govern what actions a user can perform system-wide;
ACLs control access to specific resources such as dashboards, channels, and rule groups.
User management is performed via the ArcSight Console (thick Java client) or the web-based ArcSight Command Center, depending on deployment version.
Three primary user types exist: Administrator, Analyst, and Custom Role.
Administrators hold full system access;
Analysts are scoped to investigation and case management functions as permitted by their group and ACL assignments;
Custom Roles are administrator-defined and cannot exceed the permissions of the assigning administrator.
All users must belong to at least one User Group.
Roles and ACLs are applied at the group level, meaning every app resource dashboards, channels, rule groups
is access-controlled through group membership, and a user with no group assignment has no effective access.
Quick facts
| Admin console path | ArcSight Console > Administration > User Management (for ArcSight ESM); ArcSight Command Center > Administration > User Management |
| SCIM available | Yes |
| SCIM tier required | Enterprise |
| SSO prerequisite | No |
User types and roles
| Role | Permissions | Cannot do | Plan required | Seat cost | Watch out for |
|---|---|---|---|---|---|
| Administrator | Full system access: manage users, groups, roles, system configuration, connectors, and all ESM resources. | The default 'admin' account cannot be deleted and should be secured immediately after installation. | |||
| Analyst | Access to dashboards, active channels, cases, and reports as granted by role and ACL assignments. Can investigate events and manage cases. | Cannot modify system configuration or manage other users unless explicitly granted administrative permissions. | Access to specific resources (channels, reports, rules) is controlled by Access Control Lists (ACLs) in addition to role assignment. | ||
| Custom Role (user-defined) | Configurable subset of permissions assigned by an administrator; can include read, write, execute, and manage rights on specific resource groups. | Cannot exceed the permissions of the assigning administrator. | Custom roles must be explicitly assigned to user groups; permissions are inherited through group membership. |
Permission model
- Model type: hybrid
- Description: ArcSight ESM uses a combination of role-based access control (RBAC) and Access Control Lists (ACLs). Roles define what actions a user can perform system-wide; ACLs control access to specific resources (e.g., individual dashboards, channels, rule groups). Users are assigned to User Groups, and roles and ACLs are applied at the group level.
- Custom roles: Yes
- Custom roles plan: Not documented
- Granularity: Resource-level granularity via ACLs; role-level granularity for system functions. Permissions can be set per resource group (read, write, execute, manage).
How to add users
- Log in to the ArcSight Console or ArcSight Command Center as an administrator.
- Navigate to Administration > User Management.
- Right-click the appropriate User Group or select 'New User'.
- Enter required user details: username, password, full name, and email address.
- Assign the user to one or more User Groups (which carry role and ACL assignments).
- Configure authentication type (internal or external/LDAP).
- Save the user record.
Required fields: Username, Password (for internal authentication), User Group assignment
Watch out for:
- Users must be placed in at least one User Group to inherit roles and resource permissions; a user with no group assignment has no effective access.
- If LDAP/external authentication is configured, the password field may be managed externally and the internal password is not used.
- Usernames are case-sensitive in ArcSight ESM.
- The ArcSight Console (thick client) and ArcSight Command Center (web UI) both support user management but may have slightly different navigation paths depending on version.
| Bulk option | Availability | Notes |
|---|---|---|
| CSV import | Unknown | Not documented |
| Domain whitelisting | No | Automatic domain-based user add |
| IdP provisioning | Yes | Not documented |
How to remove or deactivate users
- Can delete users: Yes
- Delete/deactivate behavior: This app exposes delete operations in its API documentation, but the admin-console path may present removal as deactivation, archiving, or deletion depending on tenant configuration. Confirm whether the UI action is reversible before treating removal as recoverable.
- Log in to the ArcSight Console or Command Center as an administrator.
- Navigate to Administration > User Management.
- Locate the user account in the user tree.
- Right-click the user and select 'Edit User', then disable the account or uncheck the 'Enabled' flag, and save; or right-click and select 'Delete' to permanently remove the account.
| Data impact | Behavior |
|---|---|
| Owned records | Resources (rules, reports, dashboards, cases) created by the deleted user remain in the system but may lose their owner association. Official documentation does not specify automatic reassignment. |
| Shared content | Shared resources remain accessible to other users who have ACL-based access; deletion of the owning user does not automatically remove shared content. |
| Integrations | Not documented |
| License freed | Removing or disabling a user account frees the associated named user license for reassignment, per standard ArcSight licensing practice. |
Watch out for:
- The default 'admin' account cannot be deleted.
- Deleting a user is permanent; there is no documented restore/undelete function for deleted user accounts.
- Cases and resources owned by a deleted user may become orphaned; administrators should reassign ownership before deletion.
- Disabling a user (rather than deleting) preserves audit trail and ownership associations.
License and seat management
| Seat type | Includes | Cost |
|---|---|---|
| Named User License | Access for a single named individual to ArcSight ESM Console and/or Command Center. | Included in overall ArcSight platform licensing; individual seat pricing not publicly listed. |
| EPS-based Platform License | Overall platform capacity measured in Events Per Second (EPS); user seat counts may be bundled or separately licensed depending on contract. | Custom pricing; publicly referenced at approximately $600K+ for 10,000 EPS. |
- Where to check usage: ArcSight Console > Administration > License Management (or via the ArcSight Management Center for multi-tier deployments)
- How to identify unused seats: Administrators can review last-login timestamps in Administration > User Management to identify inactive accounts. No automated unused-seat report is documented in publicly available official docs.
- Billing notes: ArcSight licensing is enterprise/contract-based with no self-serve pricing. License counts and seat entitlements are defined in the customer contract. Changes to seat counts require engagement with OpenText sales or account management.
The cost of manual management
ArcSight licensing is enterprise-contract-based with no self-serve pricing tier. Publicly referenced pricing runs approximately $600K+ for 10,000 EPS; individual seat counts and entitlements are defined per contract and require engagement with OpenText sales to modify.
Administrators can review last-login timestamps under Administration > User Management to identify inactive accounts, but no automated unused-seat report is documented in official public documentation. License usage is visible under Administration > License Management, or via the ArcSight Management Center for multi-tier deployments.
Because seat changes require a contract amendment, proactive access reviews carry real cost implications - inactive accounts left unreviewed represent both a licensing and a compliance exposure.
What IT admins are saying
Community evidence is not specific enough to quote or summarize yet for this app.
The decision
Manual user management in ArcSight is viable for small, stable teams but becomes operationally costly at scale. The dual-interface requirement (Console + Command Center), granular ACL model, and absence of automated inactive-account reporting all increase the administrative burden as headcount grows.
In a security stack where every app carries access risk, unreviewed accounts in a SIEM represent an outsized exposure.
For organizations running ArcSight on the Enterprise tier, SCIM provisioning via the ArcSight Platform is the recommended path for lifecycle automation. Manual processes are best reserved for edge cases - role adjustments, one-off access grants, or environments where the ArcSight Platform SCIM endpoint is not available such as standalone ESM on-premises deployments.
Before deleting any user, administrators should reassign ownership of cases and resources; deletion is permanent and there is no documented restore function. Disabling a user rather than deleting preserves the audit trail and ownership associations, which is the safer default for departing users.
Bottom line
ArcSight ESM's hybrid RBAC-plus-ACL model gives security teams precise control over every app and resource in the SIEM environment, but that granularity comes with real administrative overhead.
The dual-interface requirement, manual ACL configuration, and contract-gated seat changes mean that teams without automated provisioning will spend disproportionate time on access hygiene. Organizations on the Enterprise tier should prioritize SCIM integration to reduce manual toil;
those on standalone ESM deployments should establish a regular access review cadence using last-login data and enforce a deactivate-before-delete policy to protect audit trail integrity.
Automate OpenText ArcSight 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.
