CIS AWS Foundations v1.2 1.11: Ensure IAM password policy expires passwords within 90 days or less

CIS AWS Foundations v1.2 control 1.11 focuses on a narrow but audit-visible control: IAM password expiration. In AWS, this is controlled through the IAM account password policy, which applies to IAM users who sign in with a password. Your job as a compliance owner is to (1) decide whether IAM users are still allowed, (2) set the maximum password age to meet the benchmark requirement, and (3) operationalize monitoring so the setting does not drift.

This requirement often shows up during SOC 2 readiness, customer security reviews, and internal cloud governance because it’s easy to test: AWS Security Hub can surface it as a failed CIS check mapped to a specific control. ¹

Operationally, you’ll move fastest if you treat this as a “control card” problem: clear ownership, a defined check cadence, and a minimum evidence bundle that you can hand to an auditor without rebuilding it under deadline. ²

Regulatory text

Excerpt (as provided): “Implement CIS AWS Foundations Benchmark v1.2 requirement 1.11 as mapped in AWS Security Hub.” ³

What the operator must do: Configure the IAM account password policy so that passwords expire within 90 days or less, and run an ongoing check (for example through AWS Security Hub’s CIS mapping) to confirm the configuration remains in place across all in-scope AWS accounts. ³

Plain-English interpretation (what “compliant” means)

You are compliant when:

1. Every in-scope AWS account has an IAM account password policy configured.
2. The policy sets maximum password age to a value that does not exceed the benchmark threshold.
3. You can show the setting is enforced consistently over time (not just “we set it once”). ³

Scope note that matters in practice: this control affects IAM users who authenticate with passwords. It does not directly rotate access keys, does not force rotation of federated identities, and does not address MFA by itself. Those are separate controls, but auditors will expect your story across them to be consistent.

Who it applies to

Entity scope

• Any organization operating workloads in AWS and claiming alignment with the CIS AWS Foundations Benchmark. ²

Operational scope

• Security, IAM/platform engineering, and cloud governance teams who control account baselines.
• Environments where IAM users are still present (including break-glass users, legacy automation users, or shared admin accounts).

Typical in-scope assets

• All AWS accounts in your AWS Organizations tree that are subject to your compliance boundary.
• Any standalone AWS accounts used for production, regulated workloads, or shared services.

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

Step 1: Decide your identity strategy (fast compliance decision)

Make a clear decision and document it:

• Preferred: Workforce identity via federation/SSO, with minimal IAM users (break-glass only).
• If IAM users remain: You must enforce the password expiration policy across all accounts.

This is not a CIS requirement by itself, but it prevents messy exceptions later. Your evidence package should explain why IAM users exist and which ones are approved.

Step 2: Set the IAM account password policy ²

Do this in every in-scope AWS account:

1. Open IAM → Account settings → Password policy.
2. Enable a custom policy if not already enabled.
3. Set Maximum password age to 90 days or fewer. ²
4. Save changes.
5. Record the change ticket or change request ID in your GRC system.

Command-line or infrastructure-as-code is usually better than click-ops for multi-account environments because you can prove repeatability. If you set the policy manually, plan to replace it with scripted enforcement.

Step 3: Centralize detection with AWS Security Hub (and map to the CIS check)

1. Enable AWS Security Hub in the relevant region(s) and accounts, then enable CIS AWS Foundations checks.
2. Confirm the mapped control for this requirement is reporting as expected (Security Hub mapping). ¹
3. Triage any failures as either:
   • True misconfiguration (fix it), or
   • Out-of-scope account (document and formally exclude), or
   • Exception (document with compensating controls and an expiry date).

Step 4: Build drift management (how you keep it compliant)

You need two operational motions:

A. Prevent drift (preferred)

• Enforce the password policy through an account baseline mechanism (for example, your landing zone process).
• Restrict who can change the account password policy via IAM permissions and change control.

B. Detect and remediate drift (required for credible operation)

• Create an alert on the Security Hub finding for the password-policy check.
• Route alerts to the team that owns IAM baselines.
• Track remediation to closure with a ticket, owner, and due date. ²

Step 5: Define exception rules that auditors accept

Common valid exceptions include:

• Accounts with no IAM users (still set the policy anyway; it avoids future surprises).
• Strictly isolated sandbox accounts (only if your compliance boundary explicitly excludes them).

For each exception, keep:

• business justification,
• risk acceptance approver,
• compensating controls (for example enforced SSO-only access),
• review cadence and an end date.

Step 6: Put the requirement into an operator-friendly “control card”

Keep it short and executable:

• Objective: “All in-scope AWS accounts enforce IAM password expiration at or below the benchmark threshold.”
• Owner: named role/team.
• Trigger events: new AWS account creation, landing zone updates, Security Hub failure.
• Steps: how to set policy + where to validate.
• Evidence: defined bundle (next section). ²

Required evidence and artifacts to retain

Retain evidence that proves both configuration and operation:

Configuration evidence (point-in-time)

• Screenshot or export showing current IAM account password policy settings per account.
• Output from an API/CLI query that shows maximum password age (preferred for repeatability).
• A dated change record (ticket/change request) showing who approved the configuration.

Operational evidence (over time)

• AWS Security Hub snapshot/export showing the CIS check status for the mapped control. ¹
• Alerting rule configuration and an example alert (if triggered).
• Remediation tickets demonstrating closure for any noncompliance. ²

Governance evidence

• Control card/runbook with owner, cadence, and exception process. ²
• Exception register entries where applicable.

Retention location: put these artifacts in a system your auditors can access without engineering assistance (GRC tool, evidence repository, or a controlled folder with immutable logs).

Common exam/audit questions and hangups

What auditors ask

• “Show me the password policy for each AWS account in scope.”
• “How do you know it hasn’t changed since you set it?”
• “Do you have IAM users? Which ones, and why?”
• “What happens when the Security Hub control fails?”

Hangups

• Multi-account coverage gaps: teams configure one account and forget the rest.
• Evidence gaps: teams can show current settings but not change history or monitoring.
• Exception sprawl: “temporary” exceptions that never expire.

Frequent implementation mistakes (and how to avoid them)

1. Setting it once in the console and calling it done.
   Fix: tie the requirement to Security Hub status checks and a remediation workflow. ¹

2. Assuming SSO means the control is irrelevant.
   Fix: confirm whether any IAM users still exist (break-glass counts). If IAM users exist, enforce the policy.

3. Not defining ownership.
   Fix: name an accountable owner and document it in the control card. ²

4. Treating evidence as an afterthought.
   Fix: define an evidence bundle and store it on a recurring cadence (for example aligned to your control testing cycle). ²

Enforcement context and risk implications

No specific public enforcement cases were provided for this CIS control in the supplied source catalog, so you should treat this primarily as a benchmark and customer assurance requirement, not a standalone legal mandate.

Risk-wise, password expiration policies are usually evaluated as part of broader identity governance. If an attacker obtains a long-lived password for an IAM user, the time window for misuse is longer when expiration is weak. Your stronger story is: minimize IAM users, enforce MFA and monitoring, and keep password policy aligned to CIS as a baseline. ²

Practical execution plan (30/60/90)

Use phases rather than calendar promises. Tie each phase to deliverables that create audit-ready proof.

First 30 days (stabilize and set baseline)

• Inventory in-scope AWS accounts (Organizations + standalone).
• Confirm whether IAM users exist in each account and why.
• Set IAM password policy in every in-scope account to meet the requirement. ²
• Create the control card: owner, trigger events, exception rules, evidence list. ²

Days 31–60 (operationalize monitoring and remediation)

• Enable/confirm AWS Security Hub CIS mapping coverage for the environment and validate the mapped check status. ¹
• Route findings to a ticketing queue with SLAs your org can meet.
• Build an exception register and require approval plus review dates.

Days 61–90 (prove sustained operation)

• Run a recurring control health check and store the evidence bundle in the agreed repository. ²
• Test a drift scenario (controlled change) and confirm alerting + remediation works end-to-end.
• Report status to governance (passed accounts, exceptions, open remediations).

Where Daydream fits naturally: If you struggle to keep ownership, evidence bundles, and recurring health checks consistent across accounts, Daydream can act as the system of record for the control card, evidence collection checklist, and remediation tracking, so the audit package is assembled as you operate rather than rebuilt during an audit.

Frequently Asked Questions

Does this control apply if we only use AWS IAM Identity Center (SSO) and have no IAM users?

The password policy setting targets IAM user passwords. Many teams still set it across accounts anyway because it’s low effort and prevents future drift if an IAM user gets created later. Keep evidence that IAM users are not used (or are break-glass only).

Is setting “Maximum password age” enough to pass the CIS check?

For this specific requirement, the key test is that the maximum password age meets the benchmark threshold. Your audit pass still depends on showing the setting across all in-scope accounts and ongoing verification via your monitoring approach. ³

How do we operationalize this in a multi-account AWS Organizations setup?

Treat it as an account baseline requirement: apply the policy to every account at creation time, then continuously check compliance centrally (for example, with AWS Security Hub findings). Track any failures to closure with tickets and retained evidence. ⁴

What evidence do auditors usually accept for this control?

Provide configuration output showing the current password policy per account, plus Security Hub status showing the control pass/fail history or snapshots. Add change records and remediation tickets for any failures. ⁴

Can we create an exception because password expiration is inconvenient for engineers?

You can document exceptions, but auditors expect a real risk decision: named approver, compensating controls, and a defined review/expiry. If engineers use SSO, the better fix is reducing IAM users rather than weakening the account password policy.

What’s the most common reason this control fails in Security Hub?

Drift or partial rollout: one or more accounts never had the policy set, or a change removed it. Centralized detection plus a baseline enforcement process eliminates most repeat failures. ¹

Footnotes

1. AWS Security Hub CIS AWS Foundations mapping table

2. CIS AWS Foundations Benchmark

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

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