CIS AWS Foundations v1.2 1.22: IAM policies should not allow full "*" administrative privileges

CIS AWS Foundations v1.2 1.22 requires you to find and remove IAM policies that grant blanket administrator power via "Action":"*" on "Resource":"*" (or effectively equivalent) and replace them with least-privilege permissions. Operationalize it by inventorying all identity-based and resource-based policies, remediating overly broad statements, and keeping repeatable evidence through AWS Security Hub’s CIS mapping (IAM.1). ¹

Key takeaways:

• Eliminate any policy statements that allow "*" actions on "*" resources, unless you have a tightly governed break-glass exception.
• Treat this as a continuous control: prevent reintroduction with guardrails, monitoring, and a formal exception workflow.
• Keep audit-ready evidence: policy exports, remediation tickets, Security Hub findings, and periodic re-attestation. ²

The target keyword, cis aws foundations v1.2 1.22: iam policies should not allow full "*" administrative privileges requirement, is a practical access-control requirement: don’t allow “god mode” IAM permissions to exist casually in your AWS environment. CIS frames this as a baseline benchmark control, and AWS Security Hub maps it into its CIS benchmark checks so you can detect issues centrally. ¹

For a CCO, Compliance Officer, or GRC lead, the fastest path is to translate “no full * admin privileges” into three concrete outcomes: (1) you can produce an inventory of policies that can fully administer AWS, (2) you can prove that broad privileges are removed or constrained to an approved administrative role design, and (3) you can show that the control keeps working over time, not only on audit day. This page gives requirement-level implementation guidance you can hand to cloud security and IAM owners, with the exact evidence you should expect back.

Regulatory text

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

Operational meaning for you: You must ensure IAM policies in scope do not grant blanket administrative access through "Action":"*" and "Resource":"*" (or functionally equivalent broad permissions). You should use AWS Security Hub’s CIS mapping (control IAM.1) as a repeatable detection mechanism and maintain evidence that you respond to findings. ²

What an auditor will expect: A control statement, an owner, detection logic (often Security Hub plus IAM policy review), remediation workflow, and proof of ongoing operation (recurring scans and closed findings). ²

Plain-English interpretation

If any IAM user, group, or role can do anything to any AWS resource because a policy grants "*" permissions, you have created a single-step path to total account takeover after credential compromise or misuse. CIS 1.22 expects you to prevent that condition, except under narrowly controlled administrative patterns.

This does not mean “nobody can be an administrator.” It means:

• You avoid policies that grant unrestricted power by default.
• You centralize admin capability into a small number of roles with strong controls (MFA, session controls, change management).
• You can demonstrate that broad admin permissions are justified, time-bounded, and monitored when they exist as exceptions.

Who it applies to (entity and operational context)

Applies to:

• Organizations operating AWS accounts where IAM policies grant access to AWS services and resources. ³

Operational contexts in scope:

• Identity-based policies attached to IAM users, groups, and roles.
• Resource-based policies that can grant broad permissions (common for S3 bucket policies, KMS key policies, SNS/SQS, etc.).
• Federated access patterns (SSO/IdP) where roles are assumed and policy boundaries must still prevent "*":"*" power from becoming widespread.

Common “where this shows up” scenarios:

• Legacy “AdministratorAccess” style permissions attached to too many roles.
• CI/CD roles that were created quickly and granted "Action":"*" to “make the pipeline work.”
• Third-party integrations (security tools, MSPs, consultants) that were given broad roles and never reduced.

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

Step 1: Define the policy fail condition (what counts as “full * admin”)

Give engineering a precise definition to implement and test:

A policy is non-compliant if any statement results in:

• Effect: Allow
• Action: "*" (or NotAction patterns that effectively allow everything), and
• Resource: "*" (or resource patterns that effectively cover all resources)

Also treat as “effectively full admin” any policy that grants Action: "*", even if Resource is constrained, when the permitted services are account-wide control-plane services. Your internal standard should define how you treat these borderline cases so auditors see consistency.

Implementation tip: Document the exact pattern your detection uses and align it with Security Hub’s CIS mapping for repeatability. ²

Step 2: Inventory all policies and attachments (centralize the facts)

Minimum inventory outputs you want in a spreadsheet or GRC system:

• Policy name and ARN
• Policy type (AWS managed vs customer managed vs inline)
• Attached principal(s): user/group/role and the account
• Last updated date and policy version
• Business owner and technical owner
• Intended use case (human admin, workload, CI/CD, third party)

Practical approaches:

• Start with AWS Security Hub CIS results for IAM.1 to get an initial list of findings and affected resources. ²
• Expand to include inline policies and resource-based policies, because broad access sometimes hides there.

Step 3: Triage: separate legitimate admin design from accidental over-permissioning

Create three buckets:

1. Legitimate administrative roles (allowed pattern):

• Small population.
• Strong authentication.
• Clear ownership.
• Named purpose (e.g., “CloudPlatformAdmin”).
• Logged and monitored sessions.

2. Workload roles (should be least privilege):

• Any "*" is usually accidental.
• Fix via tighter actions, resource ARNs, and conditions.

3. Third-party access roles (must be contractually and technically bounded):

• Reduce permissions to the integration’s required API calls.
• Add time bounds and session controls where possible.
• Ensure offboarding is defined and tested.

Step 4: Remediate policies (replace broad statements with least privilege)

Remediation sequence that works in practice:

1. Create a replacement policy with scoped actions and resources.
2. Test in non-production (or with canary principals) to avoid outages.
3. Attach replacement alongside the old policy temporarily if your process requires proving equivalence.
4. Remove the broad policy (or remove the broad statement).
5. Re-scan Security Hub and confirm the finding is cleared or formally excepted. ²

Patterns to use:

• Scope Resource to explicit ARNs whenever the service supports it.
• Add Condition keys to constrain use (for example, restrict by principal tags or require MFA for sensitive actions). Keep the condition logic documented so auditors understand it.

Step 5: Handle necessary exceptions with a “break-glass” pattern

Some organizations keep a break-glass admin role for catastrophic recovery. If you do, make it an explicit exception, not an accident:

• Separate role with unique name and owner.
• Strong authentication requirements and restricted assumption path.
• Documented activation procedure and post-use review.
• Continuous monitoring and alerting on assumption events.

From a compliance perspective, the win is not “no exceptions exist.” The win is “exceptions are controlled, rare, and provably reviewed.”

Step 6: Put guardrails in place to prevent regression

This control fails most often by reintroduction. Add at least two of the following:

• Preventative control: policy review gate in infrastructure-as-code workflows; reject policies with "Action":"*" and "Resource":"*" unless an approved exception tag is present.
• Detective control: Security Hub continuous monitoring for CIS IAM.1. ²
• Governance control: periodic access review where policy owners attest to least privilege and exceptions are re-approved.

Where Daydream fits naturally: Use Daydream to map CIS 1.22 to your control library, track owners and exceptions, and generate an evidence packet (policy inventory, findings history, remediation tickets) without rebuilding the same artifacts each audit cycle.

Required evidence and artifacts to retain

Keep evidence that proves both design and operation:

Design artifacts

• Written control statement for CIS AWS Foundations v1.2 1.22 and scope definition. ³
• Definition of “full * administrative privileges” used by your program.
• Exception standard (criteria, approvals, time bounds, monitoring, review cadence).

Operational artifacts

• Export of IAM policies and attachments (timestamped).
• Security Hub CIS results for IAM.1 showing current status and trend over time. ²
• Change records: tickets/PRs for policy edits, approvals, and deployment logs.
• Exception register entries (if any) plus evidence of review and closure.
• Periodic verification output (recurring scan results; management sign-off that exceptions are still justified).

Common exam/audit questions and hangups

Use these as a checklist before you walk into an audit:

1. “Show me all principals with administrative privileges.”
   Have a current export plus your methodology for identifying “admin-equivalent” access.

2. “Do you allow AWS managed AdministratorAccess?”
   If yes, justify exactly where, why, and how it is controlled. If no, show the detection and enforcement mechanism.

3. “How do you ensure this stays compliant?”
   Auditors will discount one-time cleanup. Show Security Hub monitoring and your remediation/exception workflow. ²

4. “Are third-party roles included?”
   Expect scrutiny here. Show reduced scopes and offboarding controls.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails	Better approach
Only checking customer-managed policies	Inline and AWS-managed attachments can still create full admin	Inventory all policy types and attachments; reconcile to findings
Fixing by renaming “Admin” policies	Cosmetic changes don’t reduce permissions	Remove "Action":"*" / "Resource":"*" grants or isolate to break-glass
Leaving CI/CD roles with "*"	Pipelines become privilege escalation paths	Create service-specific deployment roles; scope resources to target accounts/regions
No exception workflow	Teams keep “temporary” admin forever	Formal exceptions with owner, rationale, and periodic review evidence
Clearing a Security Hub finding without root cause	The same pattern returns	Add preventative checks in IaC and policy authoring

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this requirement, so don’t treat CIS 1.22 as a law with direct statutory penalties. Treat it as a baseline security requirement that maps cleanly to audit expectations around least privilege and access governance. ³

Risk-wise, full "*" administrative privileges concentrate blast radius. Credential compromise, misrouted secrets, or an abused third-party integration can translate into account-wide control. Your control objective is to reduce both likelihood (fewer high-privilege principals) and impact (stronger constraints and monitoring on the remaining admin paths).

A practical 30/60/90-day execution plan

Days 0–30: Find and stop the bleeding

• Assign control owner (Cloud Security/IAM) and approver (Security leadership or CISO delegate).
• Turn on or validate AWS Security Hub CIS monitoring and focus on IAM.1 output. ²
• Build the policy inventory and identify all policies matching the “full * admin” pattern.
• Freeze creation of new "*":"*" policies through a temporary change gate (manual review is acceptable at this stage).
• Create an exception register for any break-glass needs.

Days 31–60: Remediate and harden

• Remediate workload and CI/CD roles first (highest exposure, easiest to justify).
• Reduce third-party roles; align scopes to contract and integration function.
• Consolidate human admin access into a small number of roles with explicit ownership and monitoring plan.
• Start monthly reporting: open findings, closed findings, exceptions.

Days 61–90: Make it durable and auditable

• Add preventative policy checks in IaC pipelines (deny or require exception tagging for "*":"*" statements).
• Formalize periodic access review and exception re-approval workflow.
• Produce an audit packet template: Security Hub screenshots/exports, inventory export, remediation tickets, and exception approvals. ²
• Optional: implement Daydream workflows to keep evidence current and generate auditor-ready exports on demand.

Frequently Asked Questions

Does this mean we can’t have any administrators in AWS?

You can have administrators, but avoid broad "Action":"*" on "Resource":"*" across many principals. Concentrate admin capability into well-governed roles and document any break-glass exception.

Are AWS managed policies like “AdministratorAccess” automatically non-compliant?

If they are attached broadly, they typically violate the intent of CIS 1.22 because they confer blanket privileges. If you keep them for a limited break-glass role, document the exception and controls around use.

Is checking AWS Security Hub enough to satisfy CIS 1.22?

Security Hub is strong evidence for detection because it maps CIS checks (IAM.1) and produces findings you can track. You still need remediation records, exception handling, and proof of ongoing operation. ²

Do inline policies count?

Yes. Inline policies can grant full "*" privileges and are commonly missed during cleanup. Include inline policies in your inventory and evidence set.

How should we handle third-party access that “needs admin” to install or troubleshoot?

Treat it as time-bounded, approved access with documented scope and offboarding. Prefer narrowly scoped roles; if temporary admin is unavoidable, use a controlled break-glass approach with post-use review evidence.

What evidence should we hand an auditor for this control?

Provide Security Hub CIS IAM.1 results, a current policy/attachment inventory, and change records showing removal or restriction of broad privileges. Include any exceptions with approvals and review notes. ²

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. AWS Security Hub CIS AWS Foundations mapping table

3. CIS AWS Foundations Benchmark