CIS AWS Foundations v1.2 1.10: Ensure IAM password policy prevents password reuse

To meet cis aws foundations v1.2 1.10: ensure iam password policy prevents password reuse requirement, set an AWS account-level IAM password policy that remembers prior passwords so users cannot cycle back to old credentials. Then prove it stays enforced by monitoring AWS Security Hub findings and retaining evidence of policy values, change control, and periodic verification.

Key takeaways:

• Configure IAM password policy Password reuse prevention (password history) at the account level for IAM users.
• Operationalize the control with ownership, a check cadence, and exception handling tied to break-glass access.
• Retain auditable evidence: current policy output, change approvals, and ongoing monitoring results (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table).

CIS AWS Foundations v1.2 control 1.10 is narrow but high-yield in audits: it asks whether your AWS account enforces a password history requirement so IAM users cannot reuse old passwords. The operational goal is straightforward—reduce the chance that compromised or weak passwords reappear after a reset—but auditors usually fail teams for one of two reasons: (1) the IAM password policy is not set consistently across accounts, or (2) the team cannot show durable operation (who owns it, how it is monitored, and what evidence proves it).

This page gives you requirement-level implementation guidance you can execute quickly: define the control owner, configure the IAM password policy once per AWS account, monitor continuously through AWS Security Hub’s CIS mapping, and retain an evidence bundle that stands up in a SOC 2 audit, customer diligence, or internal risk review (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table).

Scope note: this requirement applies to IAM users who authenticate with passwords. If your workforce access is federated (SSO/IdP) and you have near-zero IAM users, you still need a decision and documented rationale because the benchmark checks the AWS account configuration, not your intent.

Regulatory text

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

Operator meaning:
You must configure each in-scope AWS account so the IAM account password policy includes password reuse prevention (a password history value). Then you must be able to demonstrate the setting is present, controlled through change management, and checked on an ongoing basis using the CIS mapping in AWS Security Hub (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table).

Plain-English interpretation (what the requirement is asking)

• Your AWS account has a single IAM password policy that applies to IAM users who sign in with a password.
• “Prevent password reuse” means the account tracks a history of previous passwords and blocks users from setting a new password that matches one of those remembered passwords.
• Passing the requirement means:
  1. the password history setting is enabled (not default/blank), and
  2. you can show it’s enforced across the accounts you claim are in scope, consistently, over time (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table).

Who it applies to (entity and operational context)

Applies to:

• Any organization operating workloads in AWS that uses CIS AWS Foundations Benchmark v1.2 as a baseline or is evaluated via AWS Security Hub CIS checks (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table).

Most relevant for:

• AWS Organizations with multiple accounts, where drift is common.
• Environments with IAM users (human or service) that still authenticate with a console password.
• Regulated environments where auditors expect clear identity controls and demonstrable enforcement.

Edge cases you still must handle:

• Federated workforce (SSO) with no IAM users: the benchmark check can still flag the account if the policy is unset. Decide whether to set the policy anyway (common) or document why the account cannot reasonably have IAM users and how you prevent their creation.
• Break-glass users: these often remain IAM users by design. They still need a password history policy unless you fully replace the access pattern.

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

Step 1: Create a “control card” (owner, scope, cadence, exceptions)

Treat this as an auditable control, not a one-time setting. Create a one-page control card with:

• Control objective: IAM password policy prevents password reuse for IAM users.
• Owner: Cloud security or IAM platform owner; name a role, not a person.
• Systems in scope: list AWS accounts (or “all accounts in AWS Organizations except …”).
• Trigger events: new account creation, account baseline updates, IAM policy drift finding.
• Cadence: continuous monitoring via Security Hub plus periodic evidence capture.
• Exceptions: break-glass handling and any legacy accounts with documented remediation plan.

This aligns with the operational expectation embedded in CIS adoption and Security Hub mapping workflows (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table).

Step 2: Set the IAM password policy to enforce password history

In each AWS account, configure the account-level IAM password policy with password reuse prevention enabled. Your implementation options:

• AWS Console: IAM → Account settings → Password policy → set “Prevent password reuse” (password history count).
• AWS CLI / IaC: enforce via automation so new and existing accounts converge on the standard.

Operator checklist (what to confirm after setting it):

• The password policy exists (not “no policy set”).
• Password reuse prevention is enabled (history value is set).
• The setting is consistent across accounts.

This is the core of cis aws foundations v1.2 1.10: ensure iam password policy prevents password reuse requirement (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table).

Step 3: Centralize drift detection with AWS Security Hub (CIS mapping)

Enable AWS Security Hub and the CIS AWS Foundations benchmark checks in each account or centrally via delegated administrator, then monitor the mapped control for this requirement (AWS Security Hub CIS AWS Foundations mapping table).

Operational guidance that works in real programs:

• Route Security Hub findings to a ticketing system (Jira/ServiceNow) with an assignment rule to the control owner.
• Define severity and SLA internally (don’t invent regulator SLAs). Track to closure with evidence.
• Document how you handle suppressed findings and what approval is required to suppress.

Step 4: Implement account provisioning guardrails

Password policy settings can drift during account creation, migrations, or “temporary” admin work. Add guardrails:

• Add a baseline step in your account vending / provisioning process to set IAM password policy immediately.
• Add a periodic configuration conformance job (or rely on continuous Security Hub findings) that alerts on any account missing password reuse prevention (AWS Security Hub CIS AWS Foundations mapping table).

Step 5: Define and retain the minimum evidence bundle (make audits easy)

Auditors want “show me,” not “trust me.” See Evidence section below for what to retain each cycle.

Required evidence and artifacts to retain

Retain evidence that proves: (1) the policy is configured, (2) changes are controlled, and (3) monitoring is active.

Minimum evidence bundle (recommended):

1. Current IAM password policy output for each in-scope account (console screenshot or CLI output showing password reuse prevention setting).
2. Security Hub CIS finding status for the mapped control (pass/fail state plus timestamp) (AWS Security Hub CIS AWS Foundations mapping table).
3. Change control records for policy changes (ticket, approval, implementation notes, and validation).
4. Account scope list (source of truth for in-scope AWS accounts) and the date it was exported.
5. Exception register entries, if any, with business justification, compensating controls, approver, and expiry date.
6. Control card / runbook showing owner, triggers, and steps (CIS AWS Foundations Benchmark).

Evidence retention duration depends on your audit/regulatory context; set a standard in your GRC retention schedule and apply it consistently.

Common exam/audit questions and hangups

Auditors and customer assessors tend to ask variations of:

• “Is password history enforced for all IAM users in all AWS accounts?”
• “How do you prevent drift after account creation?”
• “Show me the current password policy configuration and when it last changed.”
• “If you suppress Security Hub findings, who approves and why?” (AWS Security Hub CIS AWS Foundations mapping table)
• “Do you still allow IAM users for daily access, and if so, how do you govern them?”

Hangups that cause findings:

• You can show one account is configured, but not all.
• The policy is set manually and can’t be proven stable.
• You rely on federated identity and assume the control is irrelevant, but you have no documented position and the benchmark check still flags the account (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table).

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	How to avoid it
Setting password history in a “main” account only	CIS/Security Hub evaluate per account	Apply via org-wide automation and verify across all accounts (AWS Security Hub CIS AWS Foundations mapping table).
No owner or operating cadence	You can’t prove control operation	Publish a control card, assign an accountable role, and run recurring health checks (CIS AWS Foundations Benchmark).
Suppressing findings without governance	Creates “paper compliance” risk	Require documented justification and approval; review suppressions periodically.
Treating break-glass accounts as exempt by default	These are high-risk credentials	Keep them in scope; use exceptions only with explicit compensating controls and expiry.
Evidence is screenshots with no context	Auditors can’t trace scope or timing	Include account IDs, timestamps, and the scope export used for the test.

Enforcement context and risk implications

No public enforcement cases were provided for this specific CIS requirement in the source catalog, so this guidance focuses on auditability and practical risk reduction rather than penalties. The risk logic is straightforward: password reuse makes credential compromise “sticky.” If users can rotate back to a known password, phishing reuse, credential stuffing reuse, and internal password sharing persist longer than teams expect.

For CCO/GRC leaders, the more immediate risk is control credibility: if you cannot show who owns the requirement, how often it’s checked, and what evidence proves operation, you will spend audit cycles debating process instead of closing gaps (CIS AWS Foundations Benchmark).

Practical 30/60/90-day execution plan

First 30 days (Immediate stabilization)

• Name a control owner and publish the control card (objective, scope, cadence, exceptions) (CIS AWS Foundations Benchmark).
• Inventory AWS accounts in scope; identify where IAM users exist.
• Enable Security Hub CIS checks and identify current failures for this control (AWS Security Hub CIS AWS Foundations mapping table).
• Set IAM password policy password reuse prevention in all high-priority accounts first (production, shared services, identity).

Days 31–60 (Standardize and automate)

• Roll the password policy setting across all in-scope accounts through your preferred automation path (account baseline, scripts, or platform tooling).
• Add ticket routing for Security Hub findings and define remediation workflow and suppression approvals (AWS Security Hub CIS AWS Foundations mapping table).
• Establish the evidence bundle and a single repository location (GRC system or controlled document store).

Days 61–90 (Prove sustained operation)

• Run a formal control health check: export Security Hub results, sample accounts, and confirm evidence completeness (AWS Security Hub CIS AWS Foundations mapping table).
• Review exceptions and break-glass accounts; add expiry dates and compensating controls.
• Add this control to your quarterly access/identity control reporting so it stays visible to leadership.

Tooling note: Many teams track the control card, evidence checklist, and remediation tickets in Daydream so the “proof of operation” is assembled continuously instead of at audit time. Keep it simple: owner, scope, last check, current status, open items, and linked evidence.

Frequently Asked Questions

Does this requirement apply if we use SSO and have no IAM users?

The check evaluates the AWS account’s IAM password policy configuration, not your identity strategy (AWS Security Hub CIS AWS Foundations mapping table). Set the policy anyway, or document a clear rationale and how you prevent IAM users from being created.

Is password reuse prevention the same as password expiration?

No. Password expiration forces changes on a schedule, while password reuse prevention blocks cycling back to previous passwords. CIS 1.10 is specifically about preventing reuse (CIS AWS Foundations Benchmark).

What evidence is strongest for auditors: screenshots or CLI output?

CLI output is easier to standardize across accounts and timestamps cleanly; screenshots can work if they clearly show the setting and the account context. Pair either method with Security Hub CIS status and a change ticket (AWS Security Hub CIS AWS Foundations mapping table).

How do we handle break-glass IAM users?

Keep them in scope and enforce password history unless you have a documented exception with compensating controls and an expiry date. Auditors expect tighter governance for emergency access, not looser.

We have multiple AWS accounts. How do we avoid configuration drift?

Put the password policy in your account baseline and monitor continuously via Security Hub findings routed to tickets (AWS Security Hub CIS AWS Foundations mapping table). Manual one-off configuration drifts quickly.

What mapped Security Hub control covers this requirement?

AWS Security Hub maps CIS AWS Foundations v1.2 1.10 to a specific IAM control in its CIS benchmark coverage (AWS Security Hub CIS AWS Foundations mapping table). Validate the exact control ID in your Security Hub console for your enabled standard version.