/okta-inspector-expert

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:

1. **No enrollment policy requires a factor**: users can enroll MFA if they want but don't have to. This fails SOC 2 immediately. 2. **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.