CIS AWS Foundations v1.2 1.16: IAM users should not have IAM policies attached

To meet the cis aws foundations v1.2 1.16: iam users should not have iam policies attached requirement, remove all identity-based policies attached directly to IAM users and grant permissions through IAM groups or IAM roles instead. Operationalize it by inventorying user-attached policies, migrating permissions to groups/roles with least privilege, and continuously monitoring with AWS Security Hub’s CIS mapping (IAM.2). ¹

Key takeaways:

• No IAM user should have a policy attached directly; use groups/roles for permissions. ²
• Treat exceptions as a control failure; solve with role assumption, break-glass design, and automation guardrails.
• Evidence matters: keep user-policy inventory, change tickets, and Security Hub/CLI outputs showing ongoing compliance. ³

This requirement exists to stop “permission sprawl” at the individual identity level. User-attached policies tend to accumulate over time, are harder to review, and make it easy to grant one-off exceptions that never get removed. CIS AWS Foundations v1.2 control 1.16 pushes you toward a cleaner, auditable model: permissions flow from a small number of well-governed constructs (groups and roles) instead of being embedded on unique user identities. ²

For a Compliance Officer, CCO, or GRC lead, the fastest way to operationalize this control is to translate it into three enforceable expectations: (1) an IAM standard that forbids user-attached policies, (2) a technical mechanism to detect and alert on violations, and (3) a remediation workflow that migrates users to group- or role-based access without breaking production. AWS Security Hub maps this benchmark expectation and can be used as your continuous signal for audits and internal assurance. ³

This page gives requirement-level implementation guidance you can hand to Cloud/IAM owners and then audit against.

Regulatory text

Requirement (excerpt): “Implement CIS AWS Foundations Benchmark v1.2 requirement 1.16 as mapped in AWS Security Hub.” ¹

Operator interpretation: You must implement the CIS benchmark requirement that IAM users should not have IAM policies attached and you must be able to show how you monitor and validate it using AWS Security Hub’s CIS mapping (control IAM.2). ¹

What an auditor expects you to prove:

• A defined standard: “No policies attached directly to IAM users.”
• A technical check that flags violations (Security Hub and/or scripted checks).
• Remediation records showing you remove user-attached policies and replace them with groups/roles.
• Ongoing verification artifacts, not a one-time cleanup. ³

Plain-English interpretation (what the requirement means)

• Prohibited: Attaching IAM policies (AWS managed or customer managed) directly to an IAM user.
• Allowed (and preferred):
  • Put permissions in IAM groups and make users members of the right group(s).
  • Use IAM roles (including cross-account roles) and have users assume roles for privileged tasks.
  • Use temporary elevation patterns (role-based, time-bound) instead of permanently attaching a policy to a user.

The control is about reducing the number of “unique snowflake” permission sets that are difficult to review, certify, and revoke.

Who it applies to

Entities

• Any organization operating AWS accounts and claiming alignment to the CIS AWS Foundations Benchmark v1.2. ²

Operational context (where it matters most)

• Human IAM users used for console/CLI access (including break-glass users).
• Legacy environments that still rely on IAM users instead of federation/SSO.
• Multi-account AWS Organizations where teams create exceptions in project accounts and forget to remove them.
• Third-party access patterns where external consultants receive IAM users; this control pushes you to role assumption and scoped access rather than bespoke user policies.

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

Step 1: Set the control owner and write the standard

1. Assign an IAM control owner (Cloud Security or IAM Platform).
2. Publish an IAM standard that states:
   • “IAM users must not have policies attached directly.”
   • “Permissions must be granted via groups or roles.”
   • “Exceptions require security approval and time-bound compensating controls,” but design your program assuming exceptions are rare and short-lived. ²

Deliverable: an IAM policy/standard page in your GRC repository, plus an internal exception process.

Step 2: Inventory all IAM users and detect user-attached policies

Run an account-by-account inventory:

• List IAM users.
• For each user, retrieve:
  • Attached managed policies (list-attached-user-policies)
  • Inline policies (list-user-policies)

Practical evidence approach (auditor-friendly):

• Export results to a dated CSV/JSON per account.
• Keep the command output and the script in source control.
• If you already run AWS Security Hub, capture the CIS finding mapped to this control (IAM.2) as the “continuous monitoring” view. ³

Step 3: Classify each policy attachment (so remediation doesn’t break operations)

For each user with a direct attachment, classify:

• Business function: what workload or admin need the permission supports.
• Privilege level: read-only, write, admin, or “unknown.”
• Target scope: which services/resources it touches.
• Replacement path: group membership vs role assumption.

Decision matrix (use this in tickets):

If the user needs…	Replace with…	Notes
Same permissions as a team	IAM group	Align to job role (e.g., “BillingReadOnly”)
Privileged/admin access	IAM role	Use role assumption with MFA and logging
Rare break-glass access	Dedicated break-glass role/user design	Keep minimal standing access; document runbook
Third-party access	Role + external ID / scoped trust	Avoid long-lived IAM user permissions

Step 4: Migrate permissions from users to groups/roles

1. Create or identify the correct IAM group(s) for the user’s function.
2. Attach the required policies to the group (not the user).
3. Add the user to the group.
4. If the permission set is truly privileged or environment-specific, implement a role:
   • User assumes role for elevated actions.
   • Keep the user’s baseline permissions minimal.
5. Validate access:
   • Confirm required console/CLI actions work.
   • Confirm no unexpected admin access.

Then remove user-attached policies:

• Detach managed policies from the user.
• Delete inline user policies.

Change control tip: Do this via a tracked ticket with before/after snapshots of attached policies.

Step 5: Put guardrails in place (prevent regression)

You need at least one preventive or detective guardrail:

• Detective: AWS Security Hub CIS mapping enabled and routed to your SIEM/ticketing, with an SLA for remediation. ³
• Preventive (recommended):
  • IAM permissions boundaries or SCP guardrails that block iam:AttachUserPolicy / iam:PutUserPolicy except for a tightly controlled admin role.
  • Infrastructure-as-code checks (policy-as-code) that fail builds if user policies are defined.

Make the guardrail measurable: a control test that can be re-run and produces consistent evidence.

Step 6: Operationalize periodic verification

Define an operating cadence:

• Continuous: Security Hub findings monitored and triaged.
• Periodic: a scripted IAM inventory to validate “zero user-attached policies” across all accounts, retained as evidence. ³

Required evidence and artifacts to retain

Keep artifacts that prove both design and operation:

Design artifacts

• IAM standard/procedure forbidding user-attached policies.
• Reference architecture for role-based admin and break-glass access.
• Exception workflow and criteria.

Operating artifacts (most important for audits)

• Dated inventory export showing:
  • IAM users
  • Attached managed policies per user
  • Inline policies per user
• Remediation tickets:
  • Link to affected user(s)
  • Before/after policy state
  • Approval and testing notes
• AWS Security Hub evidence:
  • Screenshot/export of CIS benchmark status for the mapped control (IAM.2)
  • Alert routing configuration and ticket history for any findings. ³

Retention approach

• Store exports and screenshots in a controlled evidence repository with immutable logging (or equivalent). Keep them searchable by account and date.

Common exam/audit questions and hangups

1. “Show me that no users have direct policy attachments today.”
   Have a current inventory export plus Security Hub status. ³

2. “How do you prevent a cloud admin from re-attaching a user policy next week?”
   Expect follow-ups on guardrails: SCP restrictions, privileged role constraints, and monitoring.

3. “What about break-glass users?”
   Auditors usually accept break-glass patterns when they are tightly controlled, logged, and reviewed. The hangup is when break-glass users accumulate permanent broad user-attached policies.

4. “How do you handle third-party access?”
   Strong answer: role assumption with scoped trust, time-bound access, and documented approvals, instead of bespoke IAM user policies.

Frequent implementation mistakes (and how to avoid them)

• Mistake: Only detaching managed policies but forgetting inline policies.
  Fix: inventory both AttachedUserPolicies and UserPolicyNames and require both to be empty before closure.

• Mistake: Replacing user policies with a single broad group (permission bloat).
  Fix: create role-based groups aligned to job functions; keep groups smaller and reviewable.

• Mistake: “Temporary” exceptions that become permanent.
  Fix: require expiry on exceptions, plus a monthly review of any IAM.2 findings. ³

• Mistake: Treating service accounts like human users.
  Fix: where possible, move workloads to roles (instance profiles, task roles, IRSA). If IAM users exist for legacy reasons, keep them under tight governance and avoid user-attached policies.

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific CIS requirement, so you should treat it as a baseline control expectation rather than a directly “case-cited” obligation.

Practically, this control reduces:

• Unauthorized privilege accumulation (harder access reviews, more drift).
• Lateral movement blast radius if an IAM user credential is compromised.
• Audit friction, because auditors can review a smaller set of group/role policies rather than user-by-user exceptions.

From a governance standpoint, it also supports clearer access certification: “Who is in AdminRole?” is easier to evidence than “Which users have one-off policies attached?”

A practical 30/60/90-day execution plan

Days 0–30: Baseline and stop the bleeding

• Assign control owner and publish the “no user-attached policies” standard. ²
• Enable/confirm AWS Security Hub CIS mapping and ensure the IAM.2 signal routes to tickets. ³
• Run the first full inventory across in-scope accounts; identify all violating users.
• Freeze new violations by restricting who can attach user policies (temporary admin-only until SCPs/policy-as-code are in place).

Days 31–60: Remediate and normalize access patterns

• Prioritize removals for privileged users first.
• Migrate common permission sets into IAM groups aligned to functions.
• Implement role assumption for privileged and cross-account actions.
• Close remediation tickets with before/after evidence exports and access validation notes.

Days 61–90: Institutionalize controls and evidence

• Implement preventive guardrails (SCP controls and/or CI checks) to block direct attachments except for controlled break-glass paths.
• Create a recurring evidence pack:
  • Monthly inventory export
  • Security Hub IAM.2 status export
  • Exception log review record (even if “none”). ³
• Run an internal audit tabletop: pick one account, prove end-to-end compliance in under an hour using your evidence pack.

Where Daydream fits naturally If you’re managing many AWS accounts, this control becomes evidence-heavy fast. Daydream can track the requirement, map it to your AWS control owners, schedule recurring evidence pulls (inventory + Security Hub outputs), and keep remediation tickets and exports attached to the control record for audit readiness. ³

Frequently Asked Questions

Does this mean we can’t use IAM users at all?

No. The requirement targets policies attached directly to users. You can still have IAM users, but their permissions should come from groups and roles, not user-attached policies. ²

Are inline user policies also prohibited?

Yes in practice, because they are policies attached directly to the user. Your inventory and remediation should remove both inline and managed policy attachments from IAM users. ²

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

Provide a current export proving zero user-attached policies plus the AWS Security Hub CIS mapped control status (IAM.2) showing continuous monitoring. ³

How should we handle break-glass access without attaching a policy to a user?

Put emergency permissions in a break-glass role and require controlled assumption (strong auth, approvals, logging). Keep the break-glass user’s direct permissions minimal and avoid user-attached policies.

Our third party requires an IAM user for automation. What do we do?

Prefer roles and temporary credentials. If an IAM user is unavoidable, keep the user permissionless by default and grant access through group membership tied to a narrowly scoped policy, with strict rotation and monitoring.

What if we need user-specific permissions that don’t fit any group?

Treat that as a signal to design a new group or role that represents a real function. If it’s truly unique, document the business justification and use a role-based pattern rather than a user-attached policy.

Related compliance topics

• 03.01.18: Access Control for Mobile Devices
• 03.01.19: Withdrawn
• 03.01.20: Use of External Systems
• 03.01.21: Withdrawn
• 03.01.22: Publicly Accessible Content

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