CIS AWS Foundations v1.2 1.3: Unused IAM user credentials should be removed

Remove or disable IAM user credentials (passwords, access keys, and related login profiles) that are no longer used, and prove you do this on a repeatable cadence. For CIS AWS Foundations v1.2 1.3, operationalize this by defining “unused,” monitoring credential age and last-used signals, remediating quickly, and retaining evidence from AWS Security Hub findings and IAM reports. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Key takeaways:

• Treat “credentials” as both console passwords and programmatic access keys; clean up both.
• Operationalize with an owner, an “unused” definition, an exception path, and a recurring review cycle you can evidence.
• Use AWS Security Hub’s CIS mapping (IAM.8) as your audit-friendly control surface and reporting feed. (AWS Security Hub CIS AWS Foundations mapping table)

CIS AWS Foundations v1.2 1.3 targets a common control failure: IAM users accumulate credentials that no one actively uses, but attackers can still exploit. This requirement is simple to state and easy to miss operationally because “unused” is not the same as “no longer needed,” and AWS has multiple credential types with different signals (password last used, access key last used, key age, and user activity patterns).

As a Compliance Officer, CCO, or GRC lead, your job is to turn the benchmark statement into a control that runs without heroics: you need a clear scope (which accounts and IAM users are covered), a decision rule for what gets removed and when, a workflow for exceptions (service accounts, break-glass users, third-party integrations), and an evidence bundle that stands up in audits and customer diligence.

This page gives you requirement-level guidance you can hand to Cloud Security or IAM operations, while keeping the governance pieces (ownership, cadence, evidence, and tracking) tight enough to pass an exam. Primary references are the CIS benchmark and AWS’s Security Hub mapping for CIS checks. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Requirement: CIS AWS Foundations v1.2 1.3 — unused IAM user credentials removed

Target keyword: cis aws foundations v1.2 1.3: unused iam user credentials should be removed requirement

Plain-English interpretation

You must prevent dormant IAM user credentials from lingering in your AWS environment. In practice, that means:

• If an IAM user’s console password hasn’t been used in an acceptable period ¹, disable or remove the login profile.
• If an IAM user’s access keys haven’t been used in an acceptable period, deactivate and delete those keys.
• If an IAM user is no longer needed, remove the user after validating dependencies.

Your “acceptable period” needs to be defined by your organization (policy) and implemented consistently (control operation). CIS gives the requirement goal; you supply the operational thresholds, exception handling, and proof. (CIS AWS Foundations Benchmark)

Regulatory text

Regulatory excerpt (as provided): “Implement CIS AWS Foundations Benchmark v1.2 requirement 1.3 as mapped in AWS Security Hub.” (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

What the operator must do: Implement the CIS check for unused IAM user credentials using the AWS Security Hub CIS mapping (mapped control: IAM.8), then remediate findings by removing or disabling unused IAM credentials and retaining evidence that the process runs and findings are closed. (AWS Security Hub CIS AWS Foundations mapping table)

Who it applies to

Entity scope

• Any organization operating AWS accounts that adopts or is assessed against CIS AWS Foundations Benchmark v1.2, including organizations using AWS Security Hub for CIS-aligned security posture reporting. (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table)

Operational scope (what systems/teams)

• Cloud/IAM operations: IAM user lifecycle, access key management, password/login profile management.
• Security operations: Security Hub monitoring, ticketing, remediation tracking, exception review.
• GRC/compliance: Control definition, cadence, evidence retention, audit responses.

In-scope assets

• IAM users across all in-scope AWS accounts (including shared services and production accounts).
• Credentials attached to IAM users: access keys and console login profiles.
• Reporting source: Security Hub CIS mapping for the relevant control (IAM.8). (AWS Security Hub CIS AWS Foundations mapping table)

What you actually need to do (step-by-step)

Step 1: Define the control boundaries (write the “control card”)

Create a one-page control card your teams can execute:

• Objective: Remove/disable unused IAM user credentials.
• Owner: Named role (example: Head of Cloud Security) plus an operational delegate (example: IAM Operations Lead).
• Cadence: Set a review cadence that matches your risk tolerance and audit expectations; document it in policy and the control card.
• Triggers: New IAM user created, integration retired, employee offboarding, third-party access removed, Security Hub finding opens.
• Exceptions: Break-glass users, incident response accounts, regulated retention requirements for logs (not for credentials), and accounts requiring temporary inactivity.

This directly addresses a common audit failure: nobody can show who owns the requirement, how often it runs, or what evidence proves it ran. (CIS AWS Foundations Benchmark)

Step 2: Define “unused” in a way AWS can measure

Write a definition that maps to AWS data fields and reports:

• Console password unused: “Password last used is older than our threshold” or “No password last used value exists because no console sign-in occurred.”
• Access key unused: “Access key last used is older than our threshold” (from IAM Access Advisor / access key last used info).

Keep the definition consistent across accounts. If you need different thresholds by environment (prod vs. dev), document that as an explicit exception rule, not a quiet practice.

Step 3: Establish authoritative inventory and signals

Your implementation should pull from AWS-native sources:

• AWS Security Hub findings for the CIS mapping control (IAM.8) as your compliance reporting feed. (AWS Security Hub CIS AWS Foundations mapping table)
• IAM credential report (for password and key age fields).
• Access key last used data ¹ and IAM Access Advisor signals for service access patterns.

Your goal is a single “list of candidates” each cycle: users and credentials flagged as unused, with the signal and timestamp that justified action.

Step 4: Run the remediation workflow (close findings, reduce blast radius)

For each unused credential, follow a consistent decision tree:

1. Is the IAM user still required?

• If no: remove the IAM user after confirming there are no dependencies (group membership, policies, access keys, MFA devices, roles assumed via that user).
• If yes: proceed to credential-level actions.

2. Console access present?

• If the IAM user has a login profile and it’s unused: disable console access by deleting the login profile and requiring re-provisioning through your standard request path.

3. Access keys present?

• If a key is unused: first set the key to Inactive (to reduce risk while you validate impact), then delete it after a short validation window defined by your process.
• If a key is unknown/owner unclear: treat it as high-risk operational debt. Open a ticket for owner identification and set an escalation deadline.

4. Regenerate only when justified If an application still needs programmatic access, rotate credentials through an approved mechanism and assign ownership. Avoid recreating keys as a reflex; that recreates the same unused-key problem later.

Step 5: Exception handling that auditors accept

You will have edge cases. Make them explicit:

• Break-glass accounts: Keep them tightly controlled, monitored, and separately reviewed. Document why they may appear “unused” by design and what compensating controls apply (restricted access, approvals, strong MFA, logging).
• Third-party access: If a third party uses IAM user credentials (not recommended in many architectures), record the business justification, owner, and review cadence. Ensure offboarding removes credentials promptly.
• Seasonal or infrequent admins: Document the role and why inactivity is expected; require re-authorization before re-enabling access.

Exceptions must be time-bounded and reviewed, not permanent carve-outs. Track them like risk acceptances with an owner and re-approval schedule.

Step 6: Continuous monitoring and closure

Operationalize “done” as:

• Security Hub shows the relevant CIS finding resolved for the affected resource, or the finding is otherwise closed with documented rationale. (AWS Security Hub CIS AWS Foundations mapping table)
• Your ticketing system shows the remediation action, approver (if required), and closure evidence.

If you use Daydream for GRC execution, map this requirement to an owner, set the recurring check schedule, and attach the evidence bundle each cycle so audit response is pull-not-panic.

Required evidence and artifacts to retain

Keep evidence lightweight but complete. Minimum recommended bundle per execution cycle:

Evidence item	What it proves	Where it comes from
Security Hub screenshot/export for IAM.8 findings	Control detection and status over time	AWS Security Hub (CIS mapping) (AWS Security Hub CIS AWS Foundations mapping table)
IAM credential report export	Who had passwords/keys and their age-related attributes at point-in-time	AWS IAM
Access key “last used” details per remediated key	Objective “unused” signal used for decision	AWS IAM
Remediation tickets (opened/closed)	Operational execution, dates, approver, actions taken	Ticketing system
Exception register entries (if any)	Governance for approved deviations	GRC system (or controlled register)
Control card / runbook	Defined owner, cadence, steps, and decision rules	GRC repository

Retention period should follow your broader security/compliance evidence retention standard; keep it consistent across CIS controls.

Common exam/audit questions and hangups

1. “Define unused.” Auditors will ask for your threshold and the AWS fields you rely on to measure it.
2. “Show me the last run.” Expect requests for the last completed review cycle, including what was flagged and what was removed.
3. “Are you covering all accounts?” Prove scope: which AWS accounts are enrolled in Security Hub and included in the CIS mapping reporting. (AWS Security Hub CIS AWS Foundations mapping table)
4. “How do you prevent recurrence?” They will look for a recurring cadence, automation, and owner accountability, not a one-time cleanup.
5. “How do you handle exceptions?” They will test whether exceptions are documented, approved, and periodically reviewed.

Frequent implementation mistakes (and how to avoid them)

Mistake 1: Only deleting IAM users, not credentials

Teams sometimes focus on deprovisioning users while leaving access keys attached to still-required users. Fix: run credential-level checks even for active users, and track keys separately from identities.

Mistake 2: Treating Security Hub as “reporting only”

If Security Hub findings are not tied to tickets and closure SLAs, the control becomes a dashboard. Fix: require every new IAM.8 finding to create a remediation task with an owner and due date. (AWS Security Hub CIS AWS Foundations mapping table)

Mistake 3: No owner for “mystery keys”

Keys without a clear app owner are common after reorganizations. Fix: enforce ownership metadata at creation (request workflow), and escalate orphaned keys for rapid deactivation.

Mistake 4: Permanent exceptions for break-glass

A break-glass account often looks unused and gets exempted forever. Fix: allow the account but require compensating controls and separate periodic review with evidence.

Mistake 5: Evidence gaps

A team may remediate correctly but fail to retain proof. Fix: define an evidence bundle and a storage location, then make evidence attachment part of ticket closure.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific CIS requirement. Practically, the risk is straightforward: unused credentials expand the attack surface, increase the chance of credential compromise going undetected, and weaken your ability to demonstrate access governance during audits and customer security reviews. CIS benchmarks are commonly used as contractual or assurance baselines even when they are not laws; failing them creates assurance friction and can delay deals or audit sign-off. (CIS AWS Foundations Benchmark)

Practical 30/60/90-day execution plan

Use this as an operator’s rollout plan. Adjust sequencing to match your change management constraints.

First 30 days (stabilize and prove you can run it once)

• Assign control owner and backup; publish the control card/runbook.
• Confirm account scope: which AWS accounts feed Security Hub and CIS findings. (AWS Security Hub CIS AWS Foundations mapping table)
• Define “unused” thresholds and exception categories; get sign-off from Security leadership and GRC.
• Run an initial discovery: export Security Hub IAM.8 findings and IAM credential report; open remediation tickets for highest-risk items first. (AWS Security Hub CIS AWS Foundations mapping table)

By 60 days (make it repeatable)

• Implement recurring review cadence and ticket automation from Security Hub findings.
• Standardize remediation workflow: deactivate then delete access keys after validation, disable console login profiles where unused.
• Stand up an exception register with approval workflow and periodic review reminders.
• Start evidence packaging: store exports, tickets, and approvals in a dedicated audit folder or GRC system record.

By 90 days (make it durable)

• Add preventive guardrails: require ownership metadata for IAM users and keys, enforce request-based key issuance, and define offboarding triggers (employee and third party).
• Create a monthly control health report: open findings, aging, exceptions, and closure confirmation.
• Run a tabletop audit: have someone outside the team request evidence for the last cycle and verify you can respond quickly with complete artifacts.

Frequently Asked Questions

Does this requirement apply to IAM roles or only IAM users?

The CIS AWS Foundations v1.2 1.3 wording targets unused IAM user credentials, which are tied to IAM users (console passwords and access keys). Roles don’t have long-term credentials in the same way, but you should still govern role trust and session policies separately. (CIS AWS Foundations Benchmark)

What counts as “credentials” for this control?

Treat IAM user credentials as both console authentication (login profile/password) and programmatic authentication (access keys). Your control should identify and remove or disable both types when unused. (CIS AWS Foundations Benchmark)

Can we just disable access keys instead of deleting them?

Disabling (setting to inactive) is a strong immediate containment step and is often safer operationally. Your runbook should still define when you delete disabled keys to prevent long-term dormant secrets from accumulating.

How do we operationalize this across multiple AWS accounts?

Use AWS Security Hub as the central reporting plane for the CIS mapped control (IAM.8), then route findings into a centralized ticket queue with account and resource context. This gives you consistent evidence and a single control view. (AWS Security Hub CIS AWS Foundations mapping table)

What about break-glass or emergency users that are supposed to be unused?

Allow them only under a documented exception with compensating controls and a separate review cadence. Auditors typically accept “unused by design” only when approvals and periodic checks are clearly recorded.

What evidence is usually enough for an audit?

Auditors typically want (1) the Security Hub finding history or export for IAM.8, (2) proof of the underlying IAM signals (credential report / last-used), and (3) tickets showing removal/disable actions and exception approvals when applicable. (AWS Security Hub CIS AWS Foundations mapping table)

Footnotes

1. CIS AWS Foundations Benchmark