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

To meet cis aws foundations v1.2 1.5: ensure iam password policy requires at least one uppercase letter requirement, you must configure the AWS account-level IAM password policy so every IAM user password includes at least one uppercase character (A–Z), then prove it stays enforced through monitoring and evidence retention (CIS AWS Foundations Benchmark; AWS Security Hub CIS AWS Foundations mapping table).

Key takeaways:

• This is an account-level IAM setting; it applies to IAM users who sign in with a password (not access keys).
• Auditors expect both configuration evidence and operational evidence (monitoring, exceptions, remediation tickets).
• Use AWS Security Hub’s CIS mapping control IAM.11 to continuously detect drift (AWS Security Hub CIS AWS Foundations mapping table).

This requirement is narrow but frequently scrutinized because it sits at the “front door” of AWS console access: the IAM password policy. CIS AWS Foundations v1.2 control 1.5 requires that the password policy includes a complexity rule for uppercase letters. Practically, that means you set (and keep set) the “Require at least one uppercase letter” flag in each AWS account where IAM users exist (CIS AWS Foundations Benchmark).

For a Compliance Officer, CCO, or GRC lead, the work is less about debating password theory and more about operationalizing a repeatable control: define ownership, implement the setting across accounts, verify it continuously, and retain evidence that stands up in an audit or customer due diligence. The most common failure mode is “one-and-done” setup with no drift detection, or inconsistent configuration across multiple AWS accounts. AWS Security Hub provides a mapped control (IAM.11) that can be used as your continuous control health check and a clean evidence source (AWS Security Hub CIS AWS Foundations mapping table).

Regulatory text

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

What the operator must do: Configure the AWS IAM account password policy so it requires at least one uppercase letter for IAM user passwords, and operate the control so it remains enforced over time. In AWS Security Hub, this expectation is represented under the CIS AWS Foundations mapping (IAM.11) and should be used to validate compliance and detect drift (AWS Security Hub CIS AWS Foundations mapping table).

Plain-English interpretation

If your organization allows people to sign in to AWS using IAM usernames and passwords, those passwords must include at least one uppercase character. This is a baseline complexity rule meant to reduce the chance that weak passwords are accepted.

This requirement does not mean every identity in AWS must use a password. Many mature environments avoid IAM users and rely on federation/SSO. But if IAM user passwords exist, the account-level password policy must enforce uppercase.

Who it applies to

In-scope entities

• Any organization operating workloads in AWS and aligning to the CIS AWS Foundations Benchmark v1.2 (CIS AWS Foundations Benchmark).
• Any AWS account where IAM users can authenticate to the AWS Management Console with a password.

In-scope systems and access paths

• AWS account-level IAM password policy (one policy per account).
• IAM users with console access (password-based sign-in).

Commonly out of scope (but confirm)

• API access via access keys (not governed by password policy).
• Federated identities using an external IdP where AWS IAM password policy is irrelevant to the IdP’s password rules. Even then, verify there are no leftover IAM users with console passwords.

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

Step 1: Assign control ownership and operating model

1. Assign a technical owner (usually Cloud Security or IAM platform owner) and a compliance owner (GRC).
2. Define trigger events:
   • New AWS account creation.
   • Landing zone changes.
   • Identity model changes (SSO rollout, IAM user deprecation).
3. Define how you will detect drift and how quickly you will remediate it (your internal standard).

This aligns with the practical expectation that you can show ownership, cadence, and evidence for ongoing operation (CIS AWS Foundations Benchmark).

Step 2: Inventory accounts and determine where IAM user passwords exist

1. List all AWS accounts in scope (Organizations, account registry, CMDB, or equivalent).
2. Confirm whether each account has:
   • IAM users with console access, or
   • A policy decision that IAM users are prohibited (SSO-only).
3. Record the decision per account. Auditors will ask why the control is “not applicable” in some places; your inventory is the basis for that answer.

Step 3: Implement the IAM password policy uppercase requirement

You can implement via console, CLI, or infrastructure-as-code. The key is that the account-level policy includes “require at least one uppercase letter.”

Operational approach (recommended):

1. Standardize your password policy settings in a single baseline document (even a one-page standard) owned by Cloud Security.
2. Apply the policy consistently across all in-scope accounts.
3. Where possible, manage it through automation (landing zone guardrails, account bootstrap, or scripted enforcement) so new accounts inherit the setting.

Implementation note: This requirement is specifically about uppercase. In practice, most teams set a complete password policy baseline (length, lower/upper, number, symbol, rotation). Keep the evidence and narrative anchored to the uppercase requirement to satisfy CIS 1.5, but document the full baseline to avoid piecemeal governance (CIS AWS Foundations Benchmark).

Step 4: Verify using AWS Security Hub (mapped CIS control)

1. Enable AWS Security Hub in each account (or centrally with delegated admin), consistent with your operating model.
2. Enable the CIS AWS Foundations standard in Security Hub.
3. Track the specific check mapped to this requirement (IAM.11) as your control health signal (AWS Security Hub CIS AWS Foundations mapping table).
4. Define how findings are handled:
   • Auto-ticket creation (preferred).
   • Manual triage and assignment.
   • Verified remediation and closure notes.

Step 5: Handle exceptions without breaking auditability

Some environments prohibit IAM user console passwords entirely. That can be stronger than password complexity, but you still need to prove it.

• If you claim “N/A because no IAM users have console passwords,” retain evidence of:
  • The policy decision (standard or architecture decision record).
  • Periodic checks showing no IAM users have console access, plus Security Hub status supporting your posture.

If exceptions exist (legacy admin user, break-glass), treat them explicitly:

• Identify the account/user, business justification, compensating controls, and expiration date.
• Ensure the password policy still enforces uppercase even for break-glass users. Exceptions should be rare and time-bound.

Required evidence and artifacts to retain

Maintain an “evidence bundle” that an auditor can follow without tribal knowledge:

Configuration evidence ¹

• Screenshot or exported output showing IAM password policy settings with uppercase requirement enabled.
• CLI output (or equivalent) that captures the password policy state at a point in time.
• Infrastructure-as-code snippet or configuration standard showing the intended state.

Operational evidence (ongoing)

• AWS Security Hub findings and compliance status for the mapped CIS control (IAM.11) (AWS Security Hub CIS AWS Foundations mapping table).
• Tickets or change records for any remediation of drift, including:
  • Date opened, owner, remediation action, and closure verification.
• Exception register entries (if any), with approval and periodic review notes.

Governance artifacts

• A short “control card” or runbook: objective, scope, owners, cadence, escalation path, exception rules. This directly addresses the common audit gap of unclear ownership and unverifiable operation (CIS AWS Foundations Benchmark).

Common exam/audit questions and hangups

1. “Show me this is configured in every account.”
   Expect sampling across accounts. Have a consistent export method and a central evidence folder.
2. “How do you know it stayed enabled?”
   Point to Security Hub monitoring and your ticket workflow for findings (AWS Security Hub CIS AWS Foundations mapping table).
3. “Is this applicable if you use SSO?”
   Answer per account. If IAM console passwords are disabled by policy, show your evidence that no IAM users have console passwords and that your identity architecture enforces SSO.
4. “Who owns this control?”
   Provide named owners and an operating cadence in your runbook (CIS AWS Foundations Benchmark).

Frequent implementation mistakes and how to avoid them

• Mistake: Setting the policy in one “main” account and assuming it propagates.
  Avoidance: IAM password policy is per account. Apply via automation across all accounts.
• Mistake: Relying on a written policy with no technical enforcement.
  Avoidance: Audits want system configuration plus monitoring evidence. Use Security Hub as continuous validation (AWS Security Hub CIS AWS Foundations mapping table).
• Mistake: Treating “SSO is enabled” as proof that IAM passwords don’t exist.
  Avoidance: Prove there are no IAM users with console access, and document any break-glass accounts.
• Mistake: Evidence that can’t be re-performed.
  Avoidance: Use repeatable commands, consistent screenshots, and a standard evidence template.

Enforcement context and risk implications

No public enforcement cases were provided for this specific CIS AWS Foundations requirement in the supplied source catalog. Treat it as a benchmark and customer diligence expectation, where noncompliance increases the likelihood of weak password acceptance for console-capable IAM users (CIS AWS Foundations Benchmark). For regulated environments, this often shows up as a control deficiency during audits or third-party assessments, even when not tied to a specific regulator penalty.

Practical 30/60/90-day execution plan

First 30 days (establish and implement)

• Name control owners and publish a one-page runbook for CIS 1.5 (CIS AWS Foundations Benchmark).
• Inventory AWS accounts and identify where IAM user console passwords exist.
• Implement the uppercase requirement in the IAM password policy for all in-scope accounts.
• Enable/confirm Security Hub CIS checks and validate the mapped control status (AWS Security Hub CIS AWS Foundations mapping table).

Days 31–60 (operationalize and evidence)

• Create an evidence bundle template and store baseline exports for each account (CIS AWS Foundations Benchmark).
• Wire Security Hub findings to ticketing and define SLA targets internally (no external numeric claims needed).
• Document exception handling for break-glass or legacy accounts.

Days 61–90 (stabilize and prevent drift)

• Run a control health review using Security Hub results and closed tickets as proof of operation (AWS Security Hub CIS AWS Foundations mapping table).
• Add guardrails for new accounts so the password policy baseline is set during account bootstrap.
• Prepare an audit-ready packet: runbook, inventory, baseline evidence, Security Hub reports, and remediation history (CIS AWS Foundations Benchmark).

Tooling note (Daydream)

If you manage multiple CIS requirements, Daydream typically fits as the place to store the control card, required evidence bundle, and recurring control health checks so this control is provable on demand, not rebuilt during audit week.

Frequently Asked Questions

Does this apply if we don’t allow IAM users at all?

If IAM users cannot sign in with passwords, the practical risk is reduced, but you still need evidence for your “not applicable” claim per account. Keep an account-level inventory and proof that no IAM users have console access.

Is this requirement satisfied if our IdP enforces strong passwords?

Not automatically. CIS 1.5 is about the AWS IAM password policy; it is only irrelevant where no IAM console passwords exist. If IAM users with console access remain, set the IAM policy uppercase requirement.

What’s the fastest way to prove compliance to an auditor?

Provide the IAM password policy configuration evidence for sampled accounts plus the AWS Security Hub CIS mapped control status (IAM.11) as ongoing monitoring evidence (AWS Security Hub CIS AWS Foundations mapping table).

Can we meet this with a compensating control instead of uppercase complexity?

CIS is a benchmark; auditors usually expect the explicit setting unless you can justify non-applicability (no IAM passwords) or document an exception with compensating controls and approvals. Keep the exception time-bound and review it.

How do we handle break-glass users?

Keep them rare, documented, and monitored. The uppercase requirement should still be enforced by the account password policy, and access should be controlled through your privileged access process.

What evidence should we retain if we manage configuration through infrastructure-as-code?

Retain the code snippet or module settings that enforce the uppercase requirement, plus an execution record (change ticket or pipeline run) and Security Hub compliance status showing the deployed state (AWS Security Hub CIS AWS Foundations mapping table).

Footnotes

1. AWS account