Jc security audit
Run a JumpCloud security audit — admins without MFA, users without MFA, suspended-not-locked accounts, IP list hygiene, plus auth-failure trends from Directory Insights, using the jc CLIFrom its SKILL.md
npx -y skills add TheJumpCloud/jc-cli --skill jc-security-auditAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 5 stars5 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
SKILL.md
3.7 KB, as published. Nobody here has run it
JumpCloud Security Audit
Run a focused security audit across a JumpCloud organization. The bulk
of the checks ride on jc audit (the built-in cross-resource audit
registry); we layer Directory Insights queries on top for the runtime
attack signal (failed authentications) that jc audit doesn't model.
Prerequisites
jcinstalled and authenticated (jc auth status)- Insights access requires Directory Insights enabled on the org
Step 1 — Run the built-in security audit
jc audit --category security --category identity --output json
This returns structured findings: each one has check_id, severity
(info/low/medium/high/critical), resource_ref (e.g. admin:foo@bar),
remediation_hint, and detail. Group by severity and surface the
critical ones first.
Categories included:
- security — admins without MFA, active users without MFA, suspended-but-not-locked users, IP lists with no entries
- identity — admins created in the last 14 days (sanity check for post-compromise persistence)
Step 2 — Layer in auth-failure signal (Directory Insights)
jc audit is a control-state audit; it doesn't see live traffic.
Combine with Insights to spot active attacks:
# Failed SSO authentications in the last 24 hours
jc insights query --service sso --last 24h --event-type sso_auth_failed -o json
# Volume comparison: total auth events vs failures
jc insights count --service all --last 24h
jc insights count --service sso --last 24h --event-type sso_auth_failed
Flag:
- Repeated failures from the same
initiated_by.email→ possible brute force - Failures from unfamiliar
client_ipranges → possible credential theft - Failure clusters at unusual times (off-hours, weekends)
Step 3 — Report
Produce a layered report:
- Findings from
jc audit— table withseverity | check_id | resource_ref | detail | remediation_hint. Order CRITICAL → HIGH → MEDIUM → LOW → INFO. - Auth-failure signal — counts, top offending IPs, top targeted users from the Insights data.
- Recommended actions — for each finding, the exact
jccommand fromremediation_hint.
Example report shape
JumpCloud Security Audit — ORG — DATE
Control-state findings (jc audit):
| Severity | Check | Resource | Action |
|----------|------------------------|--------------------------|--------|
| CRITICAL | admins-without-mfa | admin:[email protected] | Enable MFA in Admin Portal |
| HIGH | users-without-mfa | user:bob | jc auth-policies create … |
| MEDIUM | suspended-not-locked | user:carol | jc users lock carol |
| LOW | iplists-empty | iplist:OfficeNAT | jc iplists update OfficeNAT --ips … |
Runtime signal (Directory Insights, last 24h):
- Total auth events: 1,247
- Failed SSO auths: 18 (1.4%)
- Top offending IP: 185.220.101.42 (12 failures, all targeting [email protected])
- Recommendation: jc auth-policies create — block this IP range
Why this layout
The pre-2026.06 version of this skill scripted ~10 individual jc
queries inline. jc audit consolidates 8 of those into a single
structured fetch with severity tagging, so the skill now:
- Spends most of its token budget on interpretation rather than re-deriving findings from raw data
- Gets new checks automatically when the audit registry grows
- Produces consistent severity language with
jc-compliance-checkand CI gates (jc audit --exit-code --threshold high)