| name | okta-inspector-expert |
| description | Expertise in evaluating Okta configurations for compliance — policies, MFA, session management, admin accounts, lifecycle. Maps to FedRAMP/NIST/SOC2/PCI identity controls. |
okta-inspector expert
You are the interpretation layer between Okta configuration and compliance frameworks.
Checks this connector runs (v0.1.0)
Policies:
| SCF | Check | Source endpoint | Severity |
|---|
| IAC-06 | Password policy: length ≥14, complexity, age ≤90d, history ≥24 | /api/v1/policies?type=PASSWORD | high |
| IAC-01.2 | At least one active MFA enrollment policy requires a factor | /api/v1/policies?type=MFA_ENROLL | high |
| IAC-15 | Sign-on session lifetime ≤ 720 min (12h) | /api/v1/policies/{id}/rules | medium |
| IAC-15.1 | Sign-on session idle ≤ 15 min | same | medium |
Users:
| SCF | Check | Severity |
|---|
| IAC-15.1 | No active users inactive > N days (default 90) | medium |
Admin factors:
| SCF | Check | Severity |
|---|
| IAC-07.1 | ≤5 super admins | medium |
| IAC-01.2 | Every super admin has ≥1 active MFA factor | critical |
| IAC-01.3 | Every super admin has ≥2 active MFA factors (backup) | high |
Framework mappings (auto-expanded by gap-assessment)
- IAC-01.2 (MFA) → SOC 2 CC6.1, CC6.2 · NIST 800-53 IA-02(01), IA-02(02) · FedRAMP IA-02(01) · PCI 8.4, 8.5 · CIS 6.3, 6.5
- IAC-06 (password policy) → SOC 2 CC6.1 · NIST 800-53 IA-05 · PCI 8.3 · CIS 5.2
- IAC-15 (session mgmt) → SOC 2 CC6.1 · NIST 800-53 AC-11, AC-12 · PCI 8.1.8
- IAC-15.1 (lifecycle) → SOC 2 CC6.2, CC6.3 · NIST 800-53 AC-02(03) · PCI 8.1.4
Interpreting output
Password policy fails (IAC-06)
Okta's default policy is lenient (minLength=8, no age, no history). Almost every org needs a custom policy assigned to the Everyone group with tighter settings. FedRAMP Moderate baseline is minLength=14, complexity on, age=60d, history=24. The fix is usually straightforward but requires admin access to Okta.
MFA enforcement fails (IAC-01.2)
Two distinct failures under this control:
- No enrollment policy requires a factor: users can enroll MFA if they want but don't have to. This fails SOC 2 immediately.
- Admin without MFA: a super-admin user who hasn't enrolled any factor is an active critical finding. These tokens should be revoked until the admin enrolls.
Session timeouts (IAC-15, IAC-15.1)
FedRAMP requires session termination after inactivity. Okta's default max is 2 hours which passes; the idle timeout is the stricter check — default is often 1 hour or unlimited, fails the 15-minute FedRAMP baseline. For SOC 2, 30 minutes is usually acceptable — but the connector flags anything over 15m conservatively. Adjust with --inactive-threshold-days if your target framework is more lenient.
Inactive users (IAC-15.1)
FedRAMP is notoriously strict here — 35 days is the cutoff for Moderate. SOC 2 doesn't have a hard number but most auditors expect ≤90. The default threshold is 90; pass --inactive-threshold-days=35 for FedRAMP.
"Never logged in" users: separate signal. If an account was activated more than N days ago and has never logged in, it's either (a) a dormant service account, (b) a forgotten former-employee ghost, or (c) a future new-hire provisioned early. Any of those warrant review.
Super admin count (IAC-07.1)
Okta has built-in admin roles: Super Admin, Org Admin, App Admin, Group Admin, Help Desk Admin, Read-Only Admin, etc. The connector specifically counts Super Admins because that's the "root" of the org. 5 is a guideline — some very large orgs need more, some small shops should have 2. FedRAMP and SOC 2 don't mandate a number, but auditors look for "reasonable scope." Pair with the group memberships evaluation (future work) for a complete picture.
Limits (v0.1.0)
Not covered yet:
- Factor types evaluated (is the admin using SMS instead of WebAuthn? SMS-only MFA is a FedRAMP red flag)
- Okta Identity Engine (OIE) policy features: authenticators, phishing-resistant constraints
- Password hashing algorithm (bcrypt vs older)
- API token inventory and age (how many tokens exist, how old, what scope)
- ThreatInsight / suspicious login analytics
- App assignments (which apps are assigned to which groups / users — orphan apps)
- Log retention (System Log is 90 days by default; Log Streaming adds BYO-SIEM)
- Lifecycle integration with HRIS — whether offboarding is triggered from an authoritative HR system
When a user asks about these, say "v0.2 roadmap" and point at Okta's built-in reports (Admin → Reports) as complementary.
Common pitfalls
- Okta Classic vs Identity Engine (OIE): some API responses differ. The connector targets OIE (the current default). If the user is on Classic,
--inactive-threshold-days still works but some policy settings are named differently; expect more inconclusive results.
- Rate limits: Okta's per-API-token rate limits are tight (roughly 600 req/minute for the read endpoints). Large orgs with many admins + factors can hit these; the connector wraps to one retry on 429.
- Admin roles are hierarchical: a user with Super Admin and Org Admin counts once. Don't over-count based on role assignments.
- Factor-less admins via service accounts: some orgs have "service" super-admin accounts used only for API calls. These fail the MFA check. The right fix is usually to replace them with an API-service-principal or scoped API tokens rather than a super-admin user.
