---
name: jumpcloud-user-lifecycle
description: Onboard, modify, secure, and offboard JumpCloud users — create accounts, send activation, reset passwords and MFA, unlock accounts, grant and revoke group-based access, and run a complete offboarding. Use when the user mentions onboarding, offboarding, a new hire, a departure, a termination, suspending or deleting a user, or resetting someone's password or MFA.
license: MIT
compatibility: Requires the JumpCloud MCP server (https://mcp.jumpcloud.com/v1) connected with an admin account or API key.
metadata:
  author: jumpcloud
  version: "1.1.0"
---

# User lifecycle in JumpCloud

Access in JumpCloud flows through **groups**, not through the user record. Creating a user
gives them an identity and nothing else; membership in a user group is what grants SSO
applications, device login, and policies. Every task below is really a question about which
groups a person belongs to.

Read the safety tiers in the `jumpcloud-admin` skill before any write.

## Resolve the person first

Never act on a name. Turn it into exactly one user ID and echo the identity back:

```
users_list         → filter by email or name
search_api_execute → "find users named Alice Chen"   (when the spelling is uncertain)
user_get           → confirm the record you matched
```

If two records match, present both with enough detail to distinguish them (email,
created date, activation state) and ask which one. Guessing here is how the wrong
person gets deactivated.

## Onboarding

1. `user_create` with the identity fields the org uses. Departmental attributes matter —
   dynamic groups often key off them, so a missing `department` silently means missing
   access on day one.
2. Add group memberships with `manage_user_group_membership`. Copy from a peer rather than
   inventing a set: read `user_group_membership` for someone already in the role, diff it
   against the new hire, and confirm the list before applying.
3. `user_send_activation_email` so they set their own password.
4. If they have a machine, `bind_user_to_device` grants local login.
5. Verify: re-read `user_group_membership` and report the resulting access, not just
   "created successfully".

## Credential and access recovery

| Situation | Tool | Notes |
|---|---|---|
| Forgot password, self-service is fine | `user_send_reset_password_email` | Least privileged path. Prefer it. |
| Password must change at next login | `user_force_password_reset` | Does not itself set a password. |
| Locked out from failed attempts | `user_unlock` | Check `di_events_get` first — repeated lockouts can be an attack, not a typo. |
| Lost their MFA device | `user_reset_mfa` | Clears factors so they re-enroll. Confirm identity out of band before doing this; it is a well-known social-engineering target. |
| Needs MFA enrolled | `user_add_mfa` | |
| MFA requirement being dropped | `user_remove_mfa_requirement` | Weakens security posture. State that plainly and get explicit confirmation. |

## Offboarding

The order matters. Cut access before touching anything else, and prefer reversible steps
until the departure is final.

1. **Suspend.** `user_suspend` immediately cuts authentication everywhere and is fully
   reversible. This is the whole emergency response — do it first, investigate after.
2. **Capture the evidence.** Before you unwind anything, record the current state:
   `user_group_membership` for their access, `devices_list` filtered to them for their
   machines, `di_events_get` for recent activity. Once memberships are removed, the record
   of what they had is gone.
3. **Secure the devices.** `device_lock` for a routine departure. `device_erase` only for a
   lost machine or a hostile exit, only with explicit confirmation, and only after
   confirming nothing irreplaceable is local-only.
4. **Revoke access.** `manage_user_group_membership` to remove them from each group;
   `unbind_user_from_device` to drop local login.
5. **Reclaim licenses.** `saas_application_accounts_list` finds their SaaS accounts;
   `saas_licenses_list` shows what is being paid for. This is usually where the money is.
6. **Delete only when asked.** `user_delete` is permanent and destroys the audit linkage.
   Many organizations keep suspended accounts for a retention period. Do not delete as
   cleanup — ask.

For a departure that is already final and confirmed, you can run steps 1–5 without pausing
between each. Still confirm before step 3's destructive variants and before step 6, always.

## Bulk changes

When a request covers many users — a department reorg, a contractor batch, a policy
rollout — resolve the full set first with `search_api_execute`, present it as a named list,
and get confirmation on the set before the first write. Then apply changes one user at a
time and report per-user results including failures. A partial bulk operation that reports
itself as a success is worse than one that fails loudly.

## Reporting back

State what changed, for whom, and what it means:

> Suspended Alice Chen (alice@example.com). Removed from 4 groups, which revoked Salesforce,
> Slack, and AWS SSO. Her MacBook Pro (JC-0421) is locked. Two Figma licenses are now
> reclaimable. Her account is suspended, not deleted — say the word if you want it removed.