Skip to main content

More Info:

Credentials for users inactive for 90+ days should be disabled. Dormant accounts with active credentials are prime targets for attackers since suspicious activity may go unnoticed.

Risk Level

Medium

Address

Compliance, Security

Compliance Standards

  • APRA CPS 234 (Australia)
  • BSI C5 (Germany)
  • Brazil LGPD
  • CCPA / CPRA (California)
  • CIS AWS
  • CIS Critical Security Controls v8
  • CMMC 2.0
  • CSA Cloud Controls Matrix v4
  • Cloudanix Best Practice
  • DPDPA
  • Digital Operational Resilience Act (EU)
  • Essential 8
  • GDPR
  • HIPAA
  • ISO/IEC 27017
  • ISO/IEC 27018
  • ISO/IEC 27701
  • KSA PDPL
  • MAS Technology Risk Management (Singapore)
  • MITRE ATT&CK (Cloud)
  • NIS2 Directive
  • NIST
  • NIST SP 800-171
  • NYDFS 23 NYCRR 500
  • SOC2
  • SWIFT Customer Security Controls Framework
  • Sarbanes-Oxley IT General Controls
  • UK NCSC Cyber Assessment Framework

Triage and Remediation

Remediation

Using Console

Below are the exact console steps to remediate the “OCI IAM Unused User Credentials Should Be Disabled” finding, assuming it comes from IAM Monitoring / Security Advisor / Cloud Guard.

1. Identify the affected user and credential type

  1. Sign in to the OCI Console.
  2. Open the Navigation MenuIdentity & SecurityIdentityUsers.
  3. Locate the user flagged by IAM Monitoring:
    • Use the Search box if needed.
  4. Click the user name to open the User Details page.
You now need to disable each type of unused credential for that user.

2. Disable unused Console password (local user)

Applies only to local OCI users (not IdP‑federated).
  1. On the user’s page, in the Resources panel, click Auth Tokens / Customer Secret Keys / API Keys / Console Access (names may vary slightly by tenancy / console version).
  2. For console password, either:
    • Disable the user (hard stop for console login), or
    • Remove/clear the local password (if shown as a dedicated option).
  3. To fully block console access for that user, under User Details:
    • Set User Status to Inactive (or use Disable action from the user list).
This ensures the user cannot log into the OCI console.

3. Revoke unused API keys

  1. Still on the user’s details page, in Resources, click API Keys.
  2. Review the keys; for each unused key (as indicated by IAM Monitoring finding / last used metadata):
    • Click the Actions (⋮) menu next to the key.
    • Click Delete and confirm.
This prevents CLI/SDK access using that key.

4. Revoke unused Auth Tokens

  1. In Resources, click Auth Tokens.
  2. For each token identified as unused:
    • Click Revoke (or Delete) from the Actions (⋮) menu.
    • Confirm the revocation.
This blocks access using auth tokens (e.g., for certain tools or services).

5. Revoke unused SMTP credentials (if any)

  1. In Resources, click SMTP Credentials (or Email Delivery Credentials).
  2. For each credential set flagged as unused:
    • Click Revoke or Delete in the Actions (⋮) menu.
    • Confirm.
This stops email sending with those credentials.

6. Revoke unused Customer Secret Keys (Object Storage/Signing keys)

  1. In Resources, click Customer Secret Keys.
  2. For each key found unused:
    • Click Revoke or Delete from the Actions (⋮) menu.
    • Confirm.
This blocks signed object storage / S3‑compatible access from those keys.

7. (Optional) Fully disable or delete dormant users

If all credentials are unused and the user is no longer needed:
  1. Go back to Identity & SecurityIdentityUsers.
  2. Find the user.
  3. From the Actions (⋮) menu on the right:
    • Choose Disable to deactivate the user, or
    • Delete if you’re sure the identity is no longer required.

8. Re-check the IAM Monitoring finding

  1. Go to Identity & SecuritySecurity Center / Cloud Guard / Security Advisor (depending on your setup).
  2. Locate the original “Unused User Credentials Should Be Disabled” problem.
  3. Mark it as Resolved or wait for the next evaluation cycle to confirm the status is Closed, depending on the service behavior.

If you share which credential type (API key, auth token, console password, etc.) the IAM Monitoring alert is about, I can give a one‑page, credential‑specific version of the steps.
Below is a concise, CLI-focused way to identify and disable unused IAM user credentials in OCI, suitable for wiring into monitoring/remediation.Assumptions:
  • You already know your compartment OCID (for listing users).
  • “Unused” means “user not seen in Audit logs in X days” (e.g., 90).
  • You want to disable the user account and/or delete access keys/tokens.

1. Set variables


2. Get all IAM users in the compartment


3. Function to check if a user has activity in the last N days

This uses the Audit service to see if any events were generated by this user.

4. Disable unused users and remove their programmatic credentials

Warning: This will disable users and remove keys/tokens. Test first with echo-only.

5. (Optional) Only disable credentials, not the user

If your policy says “disable credentials but keep user active”:
  • Keep user --state as ACTIVE.
  • Only delete API keys / Auth Tokens / SMTP credentials (steps 4.1–4.3).
  • Optionally, force a console password reset:

6. Integrate with Monitoring / Scheduled Remediation

  • Put this logic in a script (e.g., disable-unused-iam-users.sh).
  • Run from:
    • An OCI Compute instance with a dynamic group + policy to manage IAM, or
    • Cloud Shell on a schedule via an external scheduler (e.g., Jenkins, GitHub Actions).
  • Ensure IAM policy (in root compartment or relevant one) permits:
This gives you a full CLI-based remediation loop for “OCI IAM Unused User Credentials Should Be Disabled.”
Below is one practical way to do this with Python + OCI SDK:
  • Detect IAM users with no activity for N days (via Audit service)
  • For those users:
    • Deactivate their API keys
    • Delete their auth tokens
    • Optionally disable the user account (lifecycle_state = INACTIVE)
You can then run this as a scheduled job (OCI Functions, OCI DevOps, cron on a compute instance, etc.).

1. Prerequisites

  1. Install the OCI Python SDK:
  2. Configure your OCI CLI/SDK config (e.g. ~/.oci/config):
  3. The principal (user or instance principal) running the script needs IAM policies like:
    If you want to set users to INACTIVE:

2. Logic Overview

  1. List all IAM users.
  2. For each user:
    • Query Audit events for that user in the last N days.
    • If no events in that period, consider credentials “unused.”
  3. For such users:
    • List API keys and deactivate/delete them.
    • List auth tokens and delete them.
    • (Optional) set user lifecycle_state to INACTIVE.
You can tune:
  • INACTIVITY_DAYS (e.g., 90).
  • Whether you disable specific credentials or entire user.

3. Example Python Script


4. How to Use / Adapt

  1. Edit the config section at top:
    • PROFILE, INACTIVITY_DAYS, DRY_RUN, DISABLE_USER.
  2. Run once in DRY_RUN = True to verify behavior.
  3. When satisfied:
    • Set DRY_RUN = False.
    • Optionally DISABLE_USER = True if you want to fully disable users.
  4. Schedule the script (e.g., cron, OCI Functions, or OCI DevOps job) to enforce “unused credentials disabled” continuously.
If you tell me:
  • whether you’re using Identity Domains, and
  • whether you want to only disable API keys/tokens or also console passwords,
I can adjust the script specifically for that setup.
Terraform cannot disable or rotate OCI IAM user credentials based on “unused for 90+ days” because that condition depends on runtime activity (last-used timestamps), which the provider does not expose as arguments.You can:
  • Use Cloud Guard or custom scripts (SDK/CLI) to detect users/API keys not used in 90+ days, and
  • Manually or programmatically disable those credentials via Console/CLI/SDK (e.g., deactivate API keys, disable the user).
This behavior (conditional on inactivity duration) cannot be expressed or enforced directly in oci_identity_user or related Terraform resources, so terraform plan will show no relevant configurable argument for “inactive for 90 days” or similar.