IBM QRadar User Management Guide

• Model type: hybrid
• Description: QRadar uses a two-layer model: (1) User Roles define which functional capabilities (tabs, actions) a user can access; (2) Security Profiles define which data (networks, log sources, domains) a user can see. Both a role and a security profile must be assigned to every user. Built-in roles exist (Admin, All) and administrators can create custom roles with granular capability checkboxes.
• Custom roles: Yes
• Custom roles plan: Not documented
• Granularity: Per-capability checkboxes within roles (e.g., Offenses: Assign, Close, Protect; Log Activity: View, Export; Reports: Create, Distribute). Security profiles add data-level restrictions by network, log source, and domain.

1. Log in to QRadar as an Admin user.
2. Click the Admin tab in the top navigation.
3. In the System Configuration section, click User Management.
4. Click Add User.
5. Enter the required fields: Username, Password, First Name, Last Name, Email.
6. Select a User Role from the dropdown.
7. Select a Security Profile from the dropdown.
8. Optionally set the user's locale and timezone.
9. Click OK to save the user.
10. Click Deploy Changes on the Admin tab if prompted to apply the configuration.

Required fields: Username, Password, First Name, Last Name, Email, User Role, Security Profile

Watch out for:

• Both a User Role and a Security Profile are mandatory; a user without a security profile cannot log in.
• Usernames are case-sensitive and must be unique.
• If LDAP authentication is configured, the password field may be managed externally, but the user record must still exist in QRadar.
• Changes to user accounts may require clicking 'Deploy Changes' on the Admin tab to take effect.
• The Admin tab is only visible to users with the Admin role; non-admin users cannot manage other 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.

1. Log in to QRadar as an Admin user.
2. Click the Admin tab.
3. Click User Management.
4. Select the user account to remove.
5. Click Delete.
6. Confirm the deletion in the dialog.
7. Click Deploy Changes if prompted.

Watch out for:

• The built-in 'admin' account cannot be deleted.
• API tokens (Authorized Services) are managed separately and are not automatically revoked when a user is deleted; these must be manually removed.
• If the user was the only member of a custom security profile or role, those objects remain but are unassigned.
• For LDAP-authenticated users, disabling the account in the LDAP directory prevents login but the QRadar user record may persist until manually deleted.

• Where to check usage: Admin tab > System and License Management > License Pool Manager
• How to identify unused seats: QRadar does not provide a native 'inactive user' report. Administrators can review the audit log (Admin > Audit Log) to identify users with no recent login activity.
• Billing notes: QRadar licensing is capacity-based (EPS/FPM/MVS), not per named user. Adding or removing user accounts does not directly affect license costs. License keys are managed under Admin > System and License Management.

QRadar licensing is capacity-based - priced on Events Per Second (EPS) or Managed Virtual Servers (MVS) - not on named user seats. Adding or removing user accounts has no direct effect on license costs. A free Community Edition exists, capped at 50 EPS and a single-host deployment.

The operational cost of manual user management is procedural, not financial. Every app that needs a new analyst requires an admin to resolve the correct role ID and security profile before the account can be created - there is no bulk CSV import path in the UI.

Inactive account identification requires manual audit log review, since QRadar provides no native last-login report in the User Management interface.

Community evidence is not specific enough to quote or summarize yet for this app.

Manual management is viable for teams with stable, low-volume user rosters and an admin who understands the role-plus-security-profile pairing. The UI is functional but unforgiving: every app added to the environment means a new user record, a role lookup, a profile lookup, and a deploy step - each done individually.

For environments with frequent onboarding, offboarding, or role changes, the manual path accumulates toil quickly. The lack of a last-login report means inactive account hygiene depends entirely on audit log discipline. Teams managing more than a handful of analysts should evaluate the REST API path or an identity governance layer to reduce per-user overhead.

Bottom line

IBM QRadar's manual user management is precise but procedurally demanding. The two-layer model (roles + security profiles) gives fine-grained control over both functional access and data visibility, but every user provisioning action requires both layers to be correctly configured before access works.

There is no bulk import, no native inactive-user report, and LDAP integration does not eliminate manual role assignment inside QRadar.

Teams that manage every app in their environment through a consistent provisioning process will find the manual path workable at small scale, but the per-user overhead compounds quickly as headcount or role complexity grows.