CIS AWS Foundations v1.2 1.6: Ensure IAM password policy requires at least one lowercase letter

To meet CIS AWS Foundations v1.2 1.6, you must configure your AWS account’s IAM password policy so any IAM user password includes at least one lowercase letter, then prove the policy stays in force over time through monitoring and evidence capture. Implement it once, automate detection, and document ownership, exceptions, and remediation.

Key takeaways:

• Set the account-level IAM password policy to require lowercase characters and confirm it applies across the account.
• Monitor continuously (AWS Security Hub control mapping) and route failures into tracked remediation. ¹
• Retain a tight evidence bundle: policy configuration output, timestamps, change history, and periodic control checks. ²

This requirement is narrow but operationally meaningful: it is one of the baseline identity hardening checks that auditors and customer security teams expect to see implemented cleanly across AWS accounts. “Lowercase letter required” sounds trivial until you run into multi-account sprawl, legacy IAM users, conflicting internal standards, or teams that rely on SSO and assume password policy is irrelevant. Your job is to make the requirement true, keep it true, and be able to show it quickly.

CIS AWS Foundations v1.2 1.6 is implemented as an AWS account setting (the IAM account password policy). It does not govern federated identities directly, and it does not replace MFA or strong session controls, but it closes an avoidable gap for any environment that still has IAM users with console passwords. AWS Security Hub maps this requirement to a specific control, which gives you a repeatable way to monitor and report status. ¹

This page focuses on requirement-level execution: exact configuration steps, how to operationalize ownership and evidence, what auditors ask, and the common ways teams accidentally fail despite “having SSO.”

Requirement: cis aws foundations v1.2 1.6: ensure iam password policy requires at least one lowercase letter requirement

Plain-English interpretation

You must enforce a rule in AWS IAM that prevents users from setting an IAM console password unless it contains at least one lowercase letter (a–z). This is an account-level password policy that applies to IAM users in that AWS account who authenticate with a password.

What “good” looks like:

• The IAM account password policy has “Require at least one lowercase letter” enabled.
• You can produce evidence (configuration output + monitoring results) on demand.
• There is a defined owner and a defined process for exceptions and remediation. ²

Who this applies to (entity and operational context)

Applies to:

• Any organization operating AWS accounts where IAM users can have console passwords.
• Environments using AWS Organizations with multiple accounts, because the setting is per-account and must be managed consistently.

Operational contexts where this matters most:

• Legacy IAM users still exist for break-glass access, admins, or third-party support.
• Multiple teams create IAM users outside a central identity program.
• Regulated workloads where customer diligence expects CIS alignment evidence.

What it does not cover:

• Federated SSO password complexity enforced by an external IdP. This CIS item still expects the AWS IAM password policy to be set, because auditors test the AWS account configuration, not just the IdP narrative. ²

Regulatory text

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

Operator interpretation: Configure the AWS IAM account password policy so it requires at least one lowercase letter, then monitor that configuration using the AWS Security Hub CIS mapping (the mapped control is the mechanism AWS provides to check and report). ¹

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

Step 1: Assign control ownership and define the runbook

1. Name an owner: typically Cloud Security or IAM Platform Engineering.
2. Set the control objective: “IAM password policy requires at least one lowercase character in every AWS account where IAM users can sign in.”
3. Define trigger events: new AWS account creation, changes to IAM password policy, Security Hub control failure, break-glass user creation.
4. Define exception rules: rare; usually “no exceptions,” because the control is low-friction and broadly compatible. If you allow exceptions, document compensating controls and approval authority. ²

Practical tip: put this into a one-page “control card” so it’s runnable by someone who did not design it.

Step 2: Implement the IAM password policy in each in-scope AWS account

You can configure via AWS Console, CLI, or infrastructure-as-code. Pick one standard path and require it.

Console path (single account):

• IAM → Account settings → Password policy → enable “Require at least one lowercase letter.”

CLI path (auditable and scriptable):

• Run aws iam update-account-password-policy --require-lowercase-characters
• Confirm with aws iam get-account-password-policy

IaC/automation expectation: In practice, GRC teams want a deterministic deployment path. If engineering manages org-wide baselines, require that this setting be enforced by the same baseline mechanism used for other IAM account settings.

Step 3: Turn on and map monitoring through AWS Security Hub

1. Enable AWS Security Hub where you manage security posture.
2. Enable the CIS AWS Foundations benchmark checks.
3. Track the mapped control for this requirement (mapped in AWS Security Hub). ¹

Operational goal: Security Hub should be your continuous signal that the setting remains enabled, not a one-time screenshot exercise.

Step 4: Add drift detection and change control

You need a way to catch and explain:

• Who changed the password policy.
• When it changed.
• Whether it was reverted quickly.

Minimum approach:

• Require that IAM password policy changes go through standard change management (ticket + approval).
• Review Security Hub findings and open remediation work items for any failed control.
• Validate closure by re-checking the policy output (get-account-password-policy) and the Security Hub control status. ³

Step 5: Handle edge cases (SSO-only, no IAM users, break-glass)

Common real-world conditions:

• SSO-only environment: You still set the IAM password policy. If no IAM users have console passwords, the control remains a baseline guardrail.
• Break-glass IAM users: These users often do have a console password. Ensure the password meets the policy and that the account policy remains compliant. Align break-glass procedures with the policy so the next emergency reset doesn’t create a finding.

Required evidence and artifacts to retain

Store evidence in a system your audit team can retrieve quickly (GRC tool, ticketing system, or evidence repository). Keep it consistent per account.

Minimum evidence bundle ²:

• Configuration proof: Output of aws iam get-account-password-policy showing lowercase required (or an equivalent console export/screenshot with timestamp).
• Monitoring proof: Security Hub control status / finding details for the mapped CIS check. ¹
• Ownership/runbook: Control card with owner, scope, frequency/cadence of checks, remediation workflow, and exception process. ²
• Change history: Tickets/approvals for any policy changes, plus post-change validation evidence.
• Remediation records: Findings logged, assigned, remediated, and validated closed.

If you use Daydream as your evidence system, treat this control like a repeatable evidence packet: one “golden” runbook, recurring evidence pulls (policy output + Security Hub status), and tracked remediation to closure.

Common exam/audit questions and hangups

Auditors, customer assessors, and internal audit teams tend to ask:

• “Show me the IAM password policy for this account and prove lowercase is required.”
• “Is this enforced across all AWS accounts or only production?”
• “How do you detect drift and how fast do you respond?”
• “If you use SSO, why do you still have IAM users, and are they controlled?”
• “Where is the evidence stored, and who signs off?” ²

Hangup: teams answer “we use Okta/Azure AD” and provide IdP password policy. That may be true, but it does not satisfy an AWS IAM configuration check by itself.

Frequent implementation mistakes and how to avoid them

1. Setting it in one account and assuming it propagates.
   Fix: treat password policy as a per-account baseline item and verify every in-scope account.

2. Relying on screenshots without durable proof.
   Fix: capture CLI output (or structured config export) and store it alongside Security Hub status. ¹

3. No owner, no cadence, no tickets.
   Fix: publish a control card and require all failures to produce a tracked remediation item with validation. ²

4. Exceptions by habit (“this legacy user can’t comply”).
   Fix: if an application breaks due to password complexity, the deeper issue is likely an embedded credential practice. Force a remediation plan rather than carving out exceptions.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific CIS item, so don’t position it as a direct regulator-driven penalty trigger. Treat it as a baseline security control that affects:

• Account takeover likelihood for IAM users with console access, especially where passwords are weak or reused.
• Audit outcomes for CIS-aligned programs, because this is a straightforward configuration check and failures read as basic hygiene gaps. ²

Practical 30/60/90-day execution plan

First 30 days (get compliant fast)

• Inventory AWS accounts in scope for CIS AWS Foundations reporting.
• For each account, set IAM password policy to require lowercase.
• Enable Security Hub CIS checks and confirm the mapped control reports correctly. ¹
• Create the control card and define the evidence bundle location. ²

By 60 days (make it repeatable)

• Standardize enforcement via automation/IaC or an account baseline process.
• Build a simple operational loop: Security Hub finding → ticket → fix → validate closure.
• Document exception handling (ideally “no exceptions”) and break-glass alignment.

By 90 days (make it durable)

• Add periodic control health reporting for leadership and audit readiness.
• Validate multi-account coverage (new accounts, acquired environments, sandboxes).
• Run a tabletop: simulate a drift event (policy changed), confirm detection, response, and evidence capture end-to-end. ²

Frequently Asked Questions

If we only use SSO and have no IAM users, do we still need this?

Yes, set the IAM password policy anyway because CIS checks validate AWS account configuration, and environments often end up with at least one break-glass IAM user. It’s a low-effort baseline guardrail. ²

Does this requirement mean passwords must be all lowercase?

No. It requires at least one lowercase character. Users can still use uppercase, numbers, and symbols based on your broader password policy.

Is this configured per user or per AWS account?

It is configured per AWS account as the IAM account password policy. You must enforce it consistently across all in-scope accounts.

What evidence is strongest for auditors: a screenshot or CLI output?

CLI output from get-account-password-policy is more durable and easier to reproduce, and pairing it with Security Hub control status strengthens the story. ¹

What’s the fastest way to detect drift?

Use AWS Security Hub’s CIS mapping to flag noncompliance, then route the finding into your ticketing workflow for remediation and closure validation. ¹

Can we approve an exception for a legacy team that can’t meet the password policy?

You can, but treat it as a short-lived, documented risk acceptance with compensating controls and a remediation plan; otherwise auditors will interpret it as a control design gap. ²

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