Identity Provider Users With Old Password

Remediation

Okta Admin Console (Asset-Level)

1. Open the affected user(s) from the finding details.
2. Apply the control-specific fix:

• Inactive users: suspend/deactivate users no longer needed.
• Excess super administrators: remove unnecessary Super Admin role assignments.
• Old password risk: enforce stricter password policy and rotation settings.

1. Save changes and confirm user status/role/policy updates.

Okta API (Asset-Level)

Use an API token with least privilege:

export OKTA_ORG="https://<your-org>.okta.com"
export OKTA_TOKEN="<api-token>"

Deactivate a user:

curl -s -X POST "$OKTA_ORG/api/v1/users/<user-id>/lifecycle/deactivate" \
  -H "Authorization: SSWS $OKTA_TOKEN" \
  -H "Accept: application/json"

List a user's assigned admin roles:

curl -s "$OKTA_ORG/api/v1/users/<user-id>/roles" \
  -H "Authorization: SSWS $OKTA_TOKEN" \
  -H "Accept: application/json"

Validation

• Re-run the control and confirm findings are cleared.
• Track approved exceptions with owner and expiry date.

Service-wide remediation

Recommended when many resources are affected: fix the platform baseline first so new resources inherit the secure setting, then remediate the existing flagged resources in batches.

Okta

Use tenant-wide sign-on policies, MFA policies, admin-role governance, and identity lifecycle automation so the control is enforced centrally.

Operational rollout

1. Fix the baseline first at the account, subscription, project, cluster, or tenant scope that owns this control.
2. Remediate the currently affected resources in batches, starting with internet-exposed and production assets.
3. Re-scan and track approved exceptions with an owner and expiry date.