CrowdStrike User Management Guide

• Model type: hybrid
• Description: CrowdStrike Falcon uses a role-based access control (RBAC) model with a set of built-in roles and, on Enterprise tiers, the ability to create custom roles by combining granular permission categories. Permissions cover functional areas such as Detections, Hosts, Policies, Threat Intelligence, Reports, and User Management. Multi-tenant environments managed via Falcon Flight Control add an additional layer of CID-level scoping.
• Custom roles: Yes
• Custom roles plan: Enterprise ($184.99/device/year)
• Granularity: Permission categories (e.g., Detections Read, Detections Write, Hosts Read, Hosts Write, Policy Management, User Management, Real Time Response). Each category can be granted independently when building a custom role.

1. Log in to the Falcon console at https://falcon.crowdstrike.com as a Falcon Administrator.
2. Navigate to Support & Resources → User Management, or go directly to https://falcon.crowdstrike.com/user-management/users.
3. Click 'Invite User' (or 'Add User' depending on console version).
4. Enter the user's email address, first name, and last name.
5. Select one or more roles to assign to the user.
6. Click 'Send Invitation'. The user receives an email with a link to set their password and activate their account.
7. If SSO/SCIM is configured, user provisioning may be handled automatically by the IdP instead of this manual flow.

Required fields: Email address, First name, Last name, Role assignment (at least one role)

Watch out for:

• Invitation emails can land in spam; advise new users to check junk folders.
• Invitation links expire; if a user does not activate within the expiry window, the administrator must resend the invitation.
• If SCIM provisioning is active via an IdP (Okta, Entra ID, OneLogin), manually added users may conflict with or be overwritten by IdP-managed user records.
• Multi-factor authentication (MFA) enforcement is a tenant-wide setting; newly added users will be required to enroll in MFA if it is enforced.
• Users added manually do not automatically inherit SSO; SSO must be configured separately at the tenant level.

• Can delete users: Yes
• Delete/deactivate behavior: CrowdStrike Falcon supports both deactivation (disabling access while retaining the user record) and deletion (permanently removing the user account). Deactivation is the recommended approach when the user's audit trail or historical activity needs to be preserved. Deletion removes the user record but historical log entries attributed to that user (e.g., audit logs) are retained in the platform audit trail.

1. Log in to the Falcon console as a Falcon Administrator.
2. Navigate to Support & Resources → User Management → Users.
3. Locate the target user using the search or filter.
4. Click the user's name to open their profile.
5. Select 'Deactivate User' (or toggle the user status to Inactive).
6. Confirm the action. The user's session is immediately invalidated and they cannot log in.

Watch out for:

• API OAuth2 clients created by a user are not tied to that user's account lifecycle; they must be manually reviewed and deleted separately under Support & Resources → API Clients & Keys.
• If SCIM is active, deprovisioning should be performed in the IdP; manually deactivating in Falcon while the IdP still has the user active may result in the account being re-provisioned on the next sync.
• There is no bulk deactivation UI; each user must be deactivated individually through the console unless SCIM deprovisioning is used.
• Deleting the sole Falcon Administrator account is blocked by the platform to prevent lockout.

• Where to check usage: Falcon Console → Support & Resources → Subscriptions (or Billing) - shows active endpoint count against licensed seat count. User count visible under User Management.
• How to identify unused seats: Review last login timestamps under Support & Resources → User Management → Users. Filter or sort by 'Last Login' to identify accounts with no recent activity. For endpoints, review sensor health and last-seen data under Hosts → Host Management.
• Billing notes: CrowdStrike licensing is primarily per-endpoint (device), not per-user. Adding or removing console users does not directly affect the invoice. Billing is annual. Volume discounts apply at thresholds of approximately 500, 1,000, and 5,000+ endpoints. A 30-day refund policy applies to direct purchases. Enterprise agreements are negotiated directly with CrowdStrike sales.

There is no bulk CSV import in Falcon, so large onboarding events require either one-by-one console work or a SCIM-connected IdP. SCIM provisioning is gated behind the Enterprise tier, meaning organizations on Falcon Pro have no automated lifecycle option and must manage every user manually through the console.

API OAuth2 clients created by departing users are decoupled from their account lifecycle and require a separate manual audit under Support & Resources → API Clients & Keys - a step that is easy to miss during offboarding.

Practitioners consistently flag three friction points with Falcon's user management. First, SSO setup requires vendor coordination and is not fully self-service for all IdP configurations.

Second, invitation link expiry is not prominently surfaced in the UI, which generates support tickets when new users cannot activate their accounts.

Third, the absence of a bulk deactivation UI means offboarding a cohort of users must be done individually through the console unless SCIM deprovisioning is active.

Custom roles being Enterprise-only is a recurring complaint from Pro-tier customers who need more granularity than the built-in roles provide.

Common complaints:

• SSO setup requires vendor coordination and is not fully self-service for all IdP configurations.
• No bulk user import via CSV; large user onboarding must be done via SCIM/IdP or one-by-one through the console.
• SCIM provisioning is gated behind the Enterprise tier, which is a significant cost jump for organizations that primarily need automated user lifecycle management.
• API client credentials are decoupled from user accounts, requiring a separate manual audit when offboarding users who created API integrations.
• Custom roles are only available on Enterprise, leaving Pro-tier customers limited to built-in roles with no granularity.
• Invitation link expiry is not prominently communicated, leading to support tickets when new users cannot activate their accounts.
• No native bulk deactivation tool in the UI; offboarding multiple users simultaneously requires SCIM or manual one-by-one steps.

Every app in a mature security stack eventually needs automated user lifecycle management, and Falcon is no exception - but that automation requires Enterprise tier and an active SSO configuration before SCIM can be enabled. Use manual provisioning if your team is small, turnover is low, and you are on Falcon Pro or below.

Move to IdP-driven SCIM provisioning via Okta, Entra ID, or OneLogin as soon as your organization reaches Enterprise tier. If you operate a multi-tenant environment via Falcon Flight Control, factor in CID-level scoping when designing role assignments, since custom roles are tenant-wide and cannot be scoped to a subset of endpoints without Flight Control segmentation.

Bottom line

Falcon's manual user management is functional for small, stable teams but does not scale gracefully.

The lack of bulk operations, the Enterprise-only gate on SCIM and custom roles, and the decoupled lifecycle of API credentials mean that access debt accumulates steadily in organizations relying solely on manual processes.

Teams serious about access hygiene should treat IdP-driven SCIM provisioning as a prerequisite and build a recurring audit of API client credentials into their offboarding checklist regardless of how users are provisioned.