Checks

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.

[DEPRECATED] EC2 Auto Scaling launch configurations are analyzed for secrets embedded in User Data, such as passwords, tokens, or API keys in bootstrapping scripts.

EC2 Auto Scaling groups use Capacity Rebalancing to act on EC2 rebalance recommendations by launching replacement Spot instances and terminating at-risk ones after they are healthy.

Assesses whether this proactive replacement behavior is enabled.

EC2 Auto Scaling groups attached to a load balancer are evaluated for ELB-based health checks that use the load balancer's target health instead of instance-only checks.

Amazon EC2 Auto Scaling groups are evaluated to determine whether their associated launch configuration assigns public IP addresses to instances (e.g., AssociatePublicIpAddress=true).

Amazon EC2 Auto Scaling launch configurations are evaluated for Instance Metadata Service settings. Instances should have the metadata endpoint enabled with http_tokens=required (enforcing IMDSv2), or have the metadata service disabled.

Allowing http_tokens=optional or omitting the version leaves legacy access enabled.

EC2 Auto Scaling groups use multiple Availability Zones within a Region, with instances distributed across more than one zone rather than confined to a single zone.

EC2 Auto Scaling groups are evaluated for using multiple instance types in each Availability Zone and spanning more than one AZ.

Groups are identified when every AZ defines at least two instance types; groups with any AZ using a single or no type, or confined to one AZ, are noted.

EC2 Auto Scaling groups use an EC2 launch template directly or via a mixed instances policy to define instance configuration and versioned settings.

API Gateway stages should have access log settings block configured to track all access to a particular stage. This should be applied to both v1 and v2 gateway stages.

Method cache encryption ensures that any sensitive data in the cache is not vulnerable to compromise in the event of interception

X-Ray tracing enables end-to-end debugging and analysis of all API Gateway HTTP requests.

API Gateway methods should generally be protected by authorization or api key. OPTION verb calls can be used without authorization