CIS AWS Foundations v1.2 1.4: IAM users' access keys should be rotated every 90 days or less

CIS AWS Foundations v1.2 1.4 requires you to ensure every AWS IAM user access key is rotated at least every 90 days, and to be able to prove it through monitoring and evidence. Operationally, that means eliminating long-lived user keys where possible, enforcing age-based detection across all accounts, and running a documented rotation workflow with tracked exceptions. ¹

Key takeaways:

• Treat this as an IAM user access key lifecycle control: detect key age, rotate, validate, and retire old keys.
• The fastest path to compliance is reducing or eliminating IAM user keys (favor roles and temporary credentials), then controlling the remainder.
• Auditors will ask for proof the control runs on schedule and that exceptions are approved, time-bound, and tracked.

The requirement “cis aws foundations v1.2 1.4: iam users' access keys should be rotated every 90 days or less requirement” is a practical control aimed at limiting the blast radius of exposed credentials. Access keys are easy to copy, hard to notice when stolen, and often embedded in scripts or third-party tooling. Rotation forces re-authorization on a predictable cadence and shrinks the window in which a compromised key remains useful.

CIS frames this as a baseline configuration for AWS accounts, and AWS Security Hub maps it as a check you can continuously measure. ¹ For a Compliance Officer, CCO, or GRC lead, the hard part is rarely the policy statement. It’s making sure engineering teams rotate keys without breaking workloads, and that you can show an examiner a clean story: ownership, cadence, evidence, and exception handling.

This page gives requirement-level implementation guidance: who must follow it, what to do step-by-step, what evidence to keep, what auditors ask, and the failure modes that cause recurring findings.

Requirement: rotate IAM users’ access keys every 90 days or less

Plain-English interpretation: If an AWS IAM user has an active access key, that key must be replaced (“rotated”) so that no active key is older than the allowed rotation window. You must be able to demonstrate this is enforced or continuously monitored across your AWS environment. ¹

What “rotated” means in practice:

• Create a replacement key.
• Update every legitimate dependency (applications, CI/CD, third-party integrations, scripts).
• Verify production behavior with the new key.
• Deactivate and delete the old key.
• Record the rotation event and any exception approvals.

Regulatory text

The benchmark requirement is implemented via AWS Security Hub mapping and is stated as: “Implement CIS AWS Foundations Benchmark v1.2 requirement 1.4 as mapped in AWS Security Hub.” ¹

Operator interpretation of that text: You need an operational control that (1) identifies IAM users with access keys older than the rotation threshold, (2) triggers rotation, and (3) produces defensible evidence that the control runs consistently, not as a one-time cleanup. ¹

Who it applies to

Entities

• Any organization operating AWS accounts where IAM users exist and can hold programmatic access keys. ²

Operational context (where this commonly matters)

• Legacy workloads using IAM user keys in environment variables or config files.
• CI/CD systems that still authenticate with an IAM user.
• Third-party tools integrated to AWS APIs using access keys (monitoring, backup, CSPM, data pipeline tools).
• Human users who created keys “temporarily” and never removed them.

Scope boundaries to set explicitly

Document what is in scope (all AWS accounts in your organization, including dev/test) and what the control considers a break-glass case. CIS is about IAM users’ access keys, so treat roles and temporary credentials as separate controls, but do not let them become an untracked escape hatch.

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

Step 1: Name the control owner and define the runbook

Create a short “control card” your teams can follow:

• Objective: no active IAM user access key exceeds the rotation window.
• Owner: cloud security / IAM platform owner.
• Operators: service owners for affected workloads.
• Cadence: continuous monitoring plus a recurring review meeting.
• Exceptions: allowed only with documented justification and an expiration date.
  This is the fastest way to prevent “we have a policy” without a working process. ²

Step 2: Reduce the population of IAM user keys (the real unlock)

Before you rotate anything, cut the number of keys you must manage:

• Prefer IAM roles + temporary credentials for workloads running on AWS (instance profiles, task roles, IRSA, etc.).
• For CI/CD, move to role assumption patterns rather than static user keys.
• For third-party tools, prefer integrations that assume roles or use scoped, short-lived credentials when supported. This step reduces operational risk: fewer keys to rotate, fewer places to hunt for secrets.

Step 3: Build an authoritative inventory of IAM users and keys

Your inventory should answer:

• Which IAM users have access keys?
• How many keys per user are active?
• What is the key age?
• Who “owns” the key from a service perspective?

Operational approach:

• Use AWS Security Hub findings for the mapped control to identify noncompliant keys and track them over time. ³
• Maintain a central register (ticketing system, GRC system, or a controlled spreadsheet if you must) mapping each key-bearing IAM user to a business owner and dependent system.

Step 4: Implement a standard rotation workflow (with rollback)

Use a consistent change pattern:

1. Open a rotation ticket per IAM user key, assigned to the service owner.
2. Create a second access key for the IAM user (AWS permits two keys per user; this supports safe cutover).
3. Update secrets storage (e.g., your secrets manager or CI/CD secret store) and redeploy.
4. Validate with a health check or synthetic AWS API call.
5. Deactivate old key after validation.
6. Delete old key once stability is confirmed.
7. Close ticket with evidence (screenshots, CLI output, change record, and validation proof).

Practical tip: require service owners to confirm where the key is stored. Many “mystery keys” are embedded in old containers, AMIs, or developer dotfiles.

Step 5: Monitor continuously and enforce remediation SLAs internally

Treat Security Hub as your “control health” signal:

• New key-age findings should automatically create tickets.
• A weekly review should clear blockers and escalate stuck rotations.
• Track remediation to closure with a documented sign-off. ⁴

Step 6: Define and govern exceptions (because they will happen)

A workable exception process includes:

• Business justification (why roles/temporary credentials cannot be used yet).
• Compensating controls (restricted IAM policy scope, monitoring, secret storage standards).
• Approval by a named authority (cloud security lead + service owner).
• Expiration and re-review.
• A migration plan to remove the exception.
  Auditors often accept exceptions when they are scarce, time-bound, and actively managed. They reject “permanent exceptions” that become the default.

Required evidence and artifacts to retain

Keep evidence that proves both design and operation:

Design evidence

• Access key rotation policy / standard (internal).
• Control card / runbook with owner, cadence, and exception rules. ²
• Architecture decision record stating preferred auth patterns (roles over keys), if you have one.

Operating evidence

• AWS Security Hub screenshots/exports showing the control status and identified failing resources over time. ³
• Rotation tickets or change records showing:
  • date opened/closed
  • affected IAM user
  • key IDs (redacted as appropriate)
  • validation steps
• Exception register with approval and expiry.
• Meeting notes or dashboards showing recurring review and closure tracking. ²

Retention guidance (practical): Store evidence in a system with immutable history (ticketing + read-only exports). Make the retention period consistent with your broader security control evidence retention standard.

Common exam/audit questions and hangups

Auditors and customer assessors tend to ask:

• “Show me a list of IAM users with active access keys and their ages.”
• “Show me how you detect keys older than the threshold.”
• “Show me three recent rotations end-to-end, including proof the old key was disabled/deleted.”
• “How do you prevent breakage during rotation?”
• “How do you handle third-party integrations that require static keys?”
• “Who owns this control, and how do you prove it runs continuously?” ²

Hangups that create findings:

• You rotated once, but cannot show ongoing monitoring.
• You have Security Hub findings, but no ticket trail to prove remediation.
• You cannot map keys to owners, so rotations stall indefinitely.
• Exceptions exist but have no expiry.

Frequent implementation mistakes (and how to avoid them)

1. Mistake: Treating “user” keys as normal for workloads.
   Fix: mandate role-based auth for AWS-hosted workloads and require an exception for any IAM user key.

2. Mistake: Rotating by deleting the old key first.
   Fix: use the two-key approach: create new, cut over, validate, then disable/delete old.

3. Mistake: Rotating keys but not updating all dependencies.
   Fix: require a dependency checklist in the rotation ticket: CI/CD, runtime secrets, third-party connectors, developer automation.

4. Mistake: No centralized evidence.
   Fix: define a minimum evidence bundle per rotation cycle and store it in a consistent location. ²

5. Mistake: Letting exceptions become permanent.
   Fix: enforce expirations and re-approval; track a backlog item to migrate to roles.

Enforcement context and risk implications

No public enforcement cases were provided for this specific benchmark requirement in the supplied sources. Practically, the risk is credential compromise leading to unauthorized access, data exposure, or destructive actions in AWS. Rotating keys reduces the time a stolen key remains valid and forces periodic re-verification of where credentials are stored.

For many regulated environments, this control also serves as “security hygiene” evidence during customer due diligence: you can show a concrete, measurable IAM control mapped in Security Hub. ³

Practical execution plan (30/60/90-day)

Use phases rather than day-count promises; what matters is sequence and evidence.

First phase: Immediate stabilization

• Assign an owner and publish the control card/runbook. ²
• Turn on or confirm AWS Security Hub coverage for the CIS mapping and start tracking findings centrally. ³
• Identify all IAM users with access keys; tag each to a service owner.

Second phase: Remediate the riskiest keys first

• Prioritize: admin-like permissions, broad policies, keys used outside AWS, unknown owners.
• Rotate keys using the two-key workflow and close tickets with evidence.
• Start an exception register for integrations you cannot change quickly.

Third phase: Make it sustainable

• Convert key-based workloads to roles and temporary credentials where feasible.
• Automate ticket creation from Security Hub findings.
• Run recurring control health checks, track remediation to closure, and report status to governance. ²

How Daydream fits (without changing your AWS architecture)

If you struggle with repeatable evidence, Daydream can house the control card, define the minimum evidence bundle for each run, and track recurring control health checks to validated closure. That directly addresses the common audit failure mode: you did the work, but cannot prove it consistently. ²

Frequently Asked Questions

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

This specific CIS check is about IAM users’ access keys. Roles and temporary credentials are separate mechanisms, but many teams adopt roles to reduce or eliminate IAM user keys and simplify compliance. ¹

If a key is unused, do we still need to rotate it?

If the key is active, it remains a liability even if you think it is unused. Operationally, the clean approach is to confirm non-use and then deactivate/delete it rather than keep rotating a key nobody should be using.

We have third-party tools that only support access keys. What should we do?

Put those keys under strict exception governance: least-privilege IAM policy, controlled secret storage, named ownership, and a time-bound plan to move to role assumption if the third party supports it later.

How do auditors expect us to prove rotation?

Provide Security Hub outputs showing compliance status and the underlying findings, plus rotation tickets/change records that show key creation, cutover, and deactivation/deletion of the old key. ³

What’s the fastest way to reduce the operational burden of rotation?

Reduce the number of IAM user keys. Move AWS-hosted workloads and CI/CD pipelines to role-based access where feasible, and reserve IAM user keys for explicit exceptions with approvals.

How do we handle “break-glass” access?

Keep break-glass credentials rare, tightly scoped, and governed like an exception with documented access procedures and periodic validation that the account is still required. Record each use and follow your incident/change process as appropriate.

Footnotes

1. CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table

2. CIS AWS Foundations Benchmark

3. AWS Security Hub CIS AWS Foundations mapping table

4. AWS Security Hub CIS AWS Foundations mapping table; CIS AWS Foundations Benchmark