Checks

Okta API token ownership should avoid Super Admin users because API tokens inherit the admin permissions of the user that created them.

Okta API token network restrictions should prevent token use from Any IP by tying each token to known Okta Network Zones.

The Authentication Policy bound to the Okta Admin Console app must require MFA. On its top active rule, User must authenticate with must be set to Password / IdP + Another factor or Any 2 factor types (factorMode=2FA in the API).

The Authentication Policy bound to the Okta Admin Console app must restrict possession factors to phishing-resistant authenticators (FIDO2/WebAuthn, PIV/CAC, Okta FastPass with biometrics). On the top active rule, Possession factor constraints are: Phishing resistant must be checked (possession.phishingResistant=REQUIRED).

The integrated Okta Admin Console app must close idle privileged sessions. Maximum app session idle time on the Sign On tab must be 15 minutes or less.

Threshold override: okta_admin_console_idle_timeout_max_minutes.

Every active Okta application must be bound to an Authentication Policy that uses Network Zones. Each active non-default rule must map User's IP to In zone or Not in zone, and the active built-in Catch-all Rule must set Access is to Denied.

The Authentication Policy bound to the Okta Dashboard app must require MFA for end users. On its top active rule, User must authenticate with must be set to Password / IdP + Another factor or Any 2 factor types (factorMode=2FA in the API).

The Authentication Policy bound to the Okta Dashboard app must restrict possession factors to phishing-resistant authenticators. On the top active rule, Possession factor constraints are: Phishing resistant must be checked (possession.phishingResistant=REQUIRED).

The Okta Verify authenticator (okta_verify) must be present, in the ACTIVE status, and configured to require FIPS-compliant devices for enrollment (settings.compliance.fips == REQUIRED).

Missing, inactive, and active-but-non-FIPS authenticators surface as distinct FAIL findings so the operator can act on the specific gap.

Every active Okta Password Policy must reject passwords found in Okta's common-password dictionary (the Restrict use of common passwords setting).

Okta evaluates Password Policies by group assignment; a custom policy with the check disabled can govern users. The check emits one finding per active policy.

Every active Okta Password Policy must require at least one lowercase character in the user's password.

Okta evaluates Password Policies by group assignment, so a permissive custom policy that drops lowercase complexity can govern users even when the default policy is compliant. The check emits one finding per active policy so weaker custom policies do not hide behind a compliant default.

Every active Okta Password Policy must require at least one numeric character in the user's password.

Okta evaluates Password Policies by group assignment, so a permissive custom policy that drops numeric complexity can govern users even when the default policy is compliant. The check emits one finding per active policy so weaker custom policies do not hide behind a compliant default.

Every active Okta Password Policy must require at least one symbol character in the user's password.

Okta evaluates Password Policies by group assignment, so a permissive custom policy that drops symbol complexity can govern users even when the default policy is compliant. The check emits one finding per active policy so weaker custom policies do not hide behind a compliant default.

Every active Okta Password Policy must require at least one uppercase character in the user's password.

Okta evaluates Password Policies by group assignment, so a permissive custom policy that drops uppercase complexity can govern users even when the default policy is compliant. The check emits one finding per active policy so weaker custom policies do not hide behind a compliant default.

Every active Okta Password Policy must keep at least the last 5 passwords in history so users cannot immediately recycle a recently-used password.

Okta evaluates Password Policies by group assignment, so a permissive custom policy that lowers the history depth can govern users even when the default policy is compliant. The check emits one finding per active policy.

Every active Okta Password Policy must lock the account after at most 3 consecutive failed sign-in attempts.

Okta evaluates Password Policies by group assignment, so a permissive custom policy with a higher threshold (or no lockout) can govern users even when the default is compliant. The check emits one finding per active policy.

Every active Okta Password Policy must require users to change their password at least every 60 days. The check rejects both unlimited expiration (0, which Okta treats as never expires) and any value greater than 60.

Okta evaluates Password Policies by group assignment; a permissive custom policy with a longer window can govern users. The check emits one finding per active policy.

Every active Okta Password Policy must prevent users from changing their password again for at least 24 hours (1440 minutes) after the previous change.

A minimum age stops users from cycling through their entire history in one session to land back on a previously-known password. The check emits one finding per active policy.

Every active Okta Password Policy must require at least 15 characters in the user's password.

Okta evaluates Password Policies by group assignment, so a permissive custom policy with a shorter minimum length can govern users even when the default policy is compliant. The check emits one finding per active policy so weaker custom policies do not hide behind a compliant default.

The Smart Card IdP authenticator (smart_card_idp) must exist in the org and be in the ACTIVE status so certificate-based authentication is available to users and apps that require it.

The check resolves the authenticator by its built-in key. Missing and inactive authenticators surface as distinct FAIL findings.

Every Okta Smart Card (X509) Identity Provider must be ACTIVE and its certificate chain must be issued by a DOD-approved CA. The check ships default issuer-DN patterns covering DOD PKI and ECA, and matches them against the chain's issuer. Override or extend via okta_dod_approved_ca_issuer_patterns in the audit config to recognise tenant-specific DOD CAs.

Okta Network Zone blocklists should block anonymized proxy access before authentication. Enhanced Dynamic Zone anonymizer categories provide direct coverage; static IP blocklists show gateway/proxy blocking but cannot prove full anonymizer-provider coverage.

Each Okta brand's sign-in page must present the Standard Mandatory DOD Notice and Consent Banner (DTM-08-060) before granting access.

The check inspects the sign-in page HTML returned by the Okta Management API, using the customized page when present and otherwise falling back to the default sign-in page.

Aligns with DISA STIG V-273192 / OKTA-APP-000200.

Every active Okta Global Session Policy needs a Priority 1 rule that is not the built-in Default Rule, setting Okta global session cookies persist across browser sessions to Disabled.

Okta evaluates policies by group assignment, so a permissive custom policy can govern users. Aligns with DISA STIG V-273206 / OKTA-APP-001710.