A JumpCloud organisation is both a directory and a device management plane, so one compromised admin account or API key can change who can sign in and run code as SYSTEM on every managed laptop. JumpCloud is widely used by small and mid-sized organisations as their single identity provider, LDAP and RADIUS service and device manager, which concentrates risk in a few admin accounts and integration credentials. This guide covers how to harden a JumpCloud organisation using JumpCloud's own documentation: Admin Portal roles and MFA, API keys and service accounts, the Commands feature and command triggers, conditional access policies, and Directory Insights logging. It is written for IT administrators and security engineers who own a JumpCloud tenant. For the wider pattern of protecting SaaS administrators, see the SaaS Admin Account Protection guide.
This is an independent guide from NHI Mgmt Group, based on JumpCloud's public documentation as of November 2026. It is not sponsored or reviewed by JumpCloud. Product features change, so confirm settings against JumpCloud's current documentation.
Key takeaways
- Commands are remote code execution by design. On Windows they run as NT AUTHORITY\SYSTEM, so anyone who can create, edit, trigger or run commands effectively controls the fleet.
- Personal API keys are admin credentials. Each admin key starts with
jca_, is shown once, and can be set to never expire; give integrations service accounts with narrow roles instead. - Billing admins hold the master switches. Only Administrator with Billing can manage administrators, enable API access and create service accounts, so keep that role to two or three named people.
- Admin Portal conditional access closes the gap MFA leaves. Policies can deny or require MFA for Admin Portal access by IP, location, device and operating system (Platform Prime plan).
- Logs expire after 90 days. Directory Insights keeps events for 90 days, so export them to a SIEM or S3 if you need a longer investigation window.
How identity and access work in JumpCloud
A JumpCloud organisation holds users, user groups, devices and device groups. Users authenticate to the User Portal, SSO (SAML and OIDC) applications, LDAP and RADIUS, and to managed macOS, Windows and Linux devices through the JumpCloud agent. Administrators are separate accounts that sign in to the Admin Portal. Policies, software and commands are pushed to devices through the agent, which is what makes JumpCloud a device management and remote execution platform as well as a directory.
That gives four control planes to harden:
- Admin Portal accounts: human administrators and their roles.
- API credentials: personal admin API keys and service account OAuth clients used by scripts, HR connectors, SCIM and other integrations.
- Device execution: Commands, command triggers and the agent itself.
- User access policy: MFA, conditional access policies and password settings that govern end users and admins.
The ATT&CK techniques to plan against are T1078.004 Valid Accounts: Cloud Accounts (a stolen admin login), T1098 Account Manipulation (adding an admin or changing a user's factors) and T1072 Software Deployment Tools (abusing device management to execute code across endpoints). Command governance, covered below, is the customer-side control for the last of these.
Admin roles and privileged access
JumpCloud documents nine default Admin Portal roles. Their spread of power is uneven, and two of them can run code on devices.
| Role | Scope of power (per JumpCloud) | Hardening note |
|---|---|---|
| Administrator with Billing | Highest access: users, groups, devices, authentication, directory, security settings, account, billing, administrator management, Multi-Tenant Portal and PAM including "Manage all Privileged Resources" | JumpCloud says to carefully consider who gets it; two or three named people, used only for admin and API governance |
| Administrator | Nearly all of the above except billing, administrator management, MTP and "Manage all Privileged Resources" | Day-to-day senior admin; still able to change authentication policy and push commands |
| Manager | Users, devices and groups; creates and updates PAM privileged resources and credentials | Suitable for IT operations staff; review PAM rights |
| Command Runner / Command Runner with Billing | Run (and schedule) only the commands assigned to the role | Limited by design, but every assigned command must itself be reviewed |
| Help Desk | Create and delete users, reset passwords, unlock users, set Admin/Sudo on a user's device, launch Remote Assist if enabled | Password reset and device admin rights are account takeover paths; pair with strict caller verification |
| Billing Only | Account tab and billing details, read-only elsewhere | JumpCloud recommends it for finance and accounting users |
| Read Only | View users and resources, no management or Settings | Auditors and reviewers |
| Asset Manager | Asset Management only, in the portal and API | Inventory staff |
Admin MFA and sign-in
- Global requirement: JumpCloud now requires MFA for all admins; the read-only Global MFA Requirement appears under Settings, Security, Admin Accounts. Use the Admins Without MFA Required widget to enforce it in bulk for any older accounts.
- Factor type: JumpCloud's admin MFA article describes TOTP from an authenticator app. TOTP can be phished in real time, so combine it with Admin Portal conditional access. See the Authenticator Apps and OTP Guide.
- Google sign-in exception: JumpCloud MFA does not apply to admins who sign in with Google; the Google account's own MFA applies instead, so that account becomes part of your admin boundary.
- Reset path: an Administrator with Billing can send a TOTP reset email (link valid for 24 hours); admins can also self-reset by email. Treat both as recovery channels that need monitoring, because an attacker who controls the admin mailbox controls the reset.
Integrations, API tokens and service accounts
| Credential | How it works | Risk | Recommended setting |
|---|---|---|---|
Personal admin API key (jca_) | Generated under My API Key; API access is off by default and only Billing admins can enable it; shown once | Tied to a person; expiry options include none, and organisations created before 15 July 2024 had keys with no expiry; regenerating revokes the old key and breaks dependent integrations | Enable API access only for admins who need it; set 30 to 90 day expiry; never use for unattended integrations |
| Service account for APIs | Non-human identity with an OAuth 2.0 client credentials grant to https://admin-oauth.id.jumpcloud.com/oauth2/token; bearer token (example lifetime about one hour) | Client secret is shown once and can last up to 365 days; the account has whatever role you assign | Narrowest role (Read Only or a custom role); 30 to 90 day secret lifetime; secret stored in a vault |
| Command trigger webhook | POST to /api/command/trigger/{triggerName} with an x-api-key header; runs every command saved with that trigger name | Whoever holds the key can launch those commands; top-level JSON fields become environment variables in the command | Few triggered commands, each validating its input; key held only by the calling system |
- Prefer service accounts for automation: JumpCloud describes them as non-human identities not tied to an individual admin, so integrations survive staff departures. Only Billing admins can create them, with a limit of 40 per organisation.
- Rotate without downtime: each service account supports two client secrets. Add the new secret, update the integration, then delete the old one; deleting a secret cuts access immediately.
- Know what breaks on rotation: JumpCloud lists AD Import, HRIS connectors, the PowerShell module, SCIM integrations and custom automations among integrations that depend on an API key. Inventory them before rotating, so an emergency rotation (as in July 2023) does not cause a long outage.
- Expiry warnings: key holders get daily emails from seven days before a personal key expires, and Billing admins get an email seven days before a client secret expires. Route these to a shared mailbox, not one person.
See the API Key Management Guide for vaulting and rotation patterns.
Commands and the agent
Commands live under Device Management, Commands. They run on one or more devices in parallel, can be launched manually, on a schedule, on every login or by a trigger, and return stdout, stderr and exit codes under Commands, Results. On Windows they run as NT AUTHORITY\SYSTEM. That makes the Commands feature the most dangerous capability in the tenant, and the place where the RMM Tool Security Guide lessons apply directly.
- Restrict who can author commands: limit command creation and editing to a small group of Administrators; give operators Command Runner so they run only reviewed, assigned commands.
- Review scheduled and login commands: a "Run on Every Login" command is persistence by design; keep a register of each one with an owner and purpose.
- Do not put secrets in command bodies: commands and their results are visible to admins; fetch secrets at run time from a vault instead.
- Allow-list the agent narrowly: JumpCloud recommends allow-listing the agent in endpoint protection so scheduled commands are not blocked. Allow-list the signed agent and its services, not arbitrary scripts it launches, so endpoint detection still sees malicious child processes.
Logging and detection
Directory Insights records events across services and keeps them for 90 days. It can be viewed and exported under Insights, Directory, queried through the API and the PowerShell module, and sent to an S3 bucket through JumpCloud's AWS Serverless Application for longer retention.
| Directory Insights service | What it records | Detection use |
|---|---|---|
| Directory | Admin and user sign-ins to the Admin and User Portals, admin changes in the directory | New admins, role changes, MFA or password policy changes, admin sign-ins from new locations |
| SSO and Software (SAML) | SSO connector create, update and delete; user sign-ins to applications | A new or edited SSO connector that could redirect sign-ins; unusual application access |
| Systems | Device logins, agent events such as lockout, password changes and disk encryption | Encryption disabled, repeated lockouts, new local admin activity |
| LDAP and RADIUS | LDAP binds and searches; Wi-Fi and VPN sign-ins | Directory enumeration, password spraying through RADIUS |
| MDM and Alerts | MDM command results; alert creation and status | Unexpected device wipes or profile pushes |
| Password Manager, Object Storage, AI Gateway | Vault membership and permission changes; custom software uploads; MCP server and AI client changes | New software packages pushed to devices; folder permission grants |
Metrics that show the controls work:
- Number of Administrator with Billing and Administrator accounts (target: a short, named list reviewed quarterly).
- Personal API keys enabled and their maximum age; keys with no expiry (target: zero).
- Service accounts with Administrator role (target: zero unless justified in writing).
- Commands and triggers without a named owner, and scheduled commands created in the last 30 days.
- Days of log history available outside JumpCloud (target: well beyond 90).
See the SaaS Audit Log Retention and Licensing Guide.
Hardening baseline
- Inventory: export administrators and roles, API-enabled admins, service accounts, commands (with schedules and triggers) and conditional access policies. Note who holds Administrator with Billing.
- Shrink admin power: reduce Billing admins to two or three; move finance staff to Billing Only, help desk to Help Desk and reviewers to Read Only, following JumpCloud's least privilege advice.
- Enforce admin MFA and conditional access: confirm every admin has MFA, then build an Admin Portal conditional access policy. Start with "Allow access with MFA" from a defined IP list or managed devices, and add a specific deny policy only after testing, because deny takes precedence over every other action. Keep one break-glass admin excluded and monitored. See the Break-Glass Account Guide.
- Replace personal keys: move each integration to a service account with the narrowest role, then disable API access for admins who no longer need it and set expiry on any remaining keys.
- Govern commands: review every command, remove unused ones, assign owners, and restrict authoring rights. Review triggers and the systems that hold their keys.
- User policy: require MFA for users, apply conditional access to the User Portal and SSO applications (asking users to enrol a factor first to avoid lockouts), and set password length of at least 12 characters as JumpCloud's best practices recommend.
- Export logs: connect Directory Insights to the SIEM or S3 and alert on the events in the table above.
Rollback: keep a record of each policy before changing it; if a conditional access policy locks admins out, the excluded break-glass account restores access. Small versus large: a ten-person company may have one Billing admin and one Administrator, and should lean on conditional access and logging; a Multi-Tenant Portal provider must also govern MSP admin roles and delete unused organisations, as JumpCloud's best practices note.
Common misconfigurations
- Everyone in IT is an Administrator with Billing: every one of them can create admins, enable API keys and create service accounts.
- A personal API key running HR sync: the integration breaks when the admin leaves, and the key often has no expiry. Use a service account.
- Service accounts with the Administrator role: a leaked client secret then grants near-full control, including commands.
- Unreviewed scheduled commands: a login or recurring command added by a compromised admin persists on every device in the group.
- Conditional access only for users: leaving the Admin Portal on the default access policy means a phished TOTP code works from anywhere.
- Relying on the 90-day window: supplier incidents can surface months later, so keep Directory Insights data in your own SIEM for longer.
Framework mapping
| JumpCloud control | NIST SP 800-53 Rev 5 | NIST CSF 2.0 |
|---|---|---|
| Admin roles, Billing admin limits, Command Runner | AC-6, AC-6(5), AC-5 | PR.AA-05 |
| Admin MFA and conditional access | IA-2, IA-2(1) | PR.AA-01 |
| API keys and service account secrets | IA-5, AC-2 | PR.AA-01 |
| Directory Insights export and review | AU-2, AU-6, AU-9 | PR.PS-04, DE.CM-03 |
Practitioner checklist
- Limit Administrator with Billing to two or three named people and review all admin roles quarterly.
- Confirm MFA for every admin and check that admins signing in with Google have MFA on that Google account.
- Create an Admin Portal conditional access policy requiring MFA from known networks or managed devices, with a monitored break-glass exception.
- Move integrations from personal
jca_keys to service accounts with the narrowest role and a 30 to 90 day secret lifetime. - Disable API access for admins who do not use it and remove any key with no expiry.
- Register every command, trigger and scheduled or login command with an owner; remove the rest.
- Keep secrets out of command bodies and validate any trigger input used by a command.
- Stream Directory Insights to a SIEM or S3 and alert on admin, SSO connector and policy changes.
Standards and references
- JumpCloud: Admin Portal Roles
- JumpCloud: Enable MFA for the Admin Portal
- JumpCloud: JumpCloud APIs
- JumpCloud: Service Account for APIs
- JumpCloud: Get Started: Commands
- JumpCloud: Use Command Triggers
- JumpCloud: Get Started: Conditional Access Policies
- JumpCloud: Get Started: Directory Insights
Related NHI Mgmt Group resources: Conditional Access Guide · RMM Tool Security Guide · Remote access and PAM vendors as tier-zero suppliers