CIS AWS Foundations v1.2 1.12: IAM root user access key should not exist

The requirement “cis aws foundations v1.2 1.12: iam root user access key should not exist requirement” is simple to state but easy to fail during account bootstrap, legacy migrations, or rushed automation. The AWS root user is a super-privileged identity tied to the account itself. If a root access key exists, it creates persistent programmatic access that is hard to attribute, hard to rotate safely, and catastrophic if exposed.

Most compliance leaders don’t need a deep IAM primer here. You need a crisp control design: one owner, one detection method, one remediation path, and an evidence bundle that stands up to a SOC report, a customer diligence review, or an internal audit. This page gives you requirement-level implementation guidance you can hand to Cloud Security, SRE, or Platform teams and then validate as the control owner.

You will map the control to AWS Security Hub’s CIS mapping (IAM.4), define what “passing” means, remove any root keys, prevent re-creation through process and monitoring, and retain artifacts that prove ongoing operation. Sources for the benchmark and mapping are the CIS AWS Foundations Benchmark and AWS Security Hub CIS AWS Foundations mapping table.

Regulatory text

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

Operator interpretation: You must ensure the AWS account root user does not have any IAM access keys. In AWS terms, the root user should have zero access keys (neither active nor inactive). Your control should detect violations (for example, via AWS Security Hub’s CIS control mapping) and drive timely remediation, with evidence that you check continuously or on a defined cadence. ¹

Plain-English interpretation (what the requirement really means)

• The AWS root user should be used only for tightly controlled break-glass actions that require root (for example, certain account-level billing or configuration tasks), and those actions should be interactive with MFA, not programmatic.
• If root access keys exist, anyone who gets those keys can call AWS APIs as root. That bypasses the accountability and guardrails you typically build around IAM roles, identity provider federation, approvals, logging, and session controls.
• “Should not exist” means you don’t “disable and keep” them for convenience. You delete them and prove they remain absent.

Who it applies to

Entities: Any organization operating workloads in AWS where the CIS AWS Foundations Benchmark is in scope, including regulated companies, SaaS providers, and enterprises with customer-driven security requirements. ²

Operational context (where this breaks in practice):

• Multi-account AWS Organizations environments where legacy accounts were created before standard guardrails.
• Mergers/acquisitions where inherited AWS accounts have unknown root key history.
• Automation scripts written early on that used root keys “temporarily” and never removed them.
• Third parties (consultants, MSPs) that requested root keys for setup work. Even if the third party is trusted, the control still fails if the key exists.

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

Treat this as a preventive + detective control with an immediate remediation playbook.

Step 1: Establish control ownership and runbook

Create a short “control card” your team can execute:

• Control objective: Root user has no access keys in any AWS account in scope.
• Control owner: Cloud Security or Platform Security, with Compliance as oversight.
• Operating cadence: Continuous detection via AWS Security Hub plus scheduled review (for example, as part of monthly control health checks).
• Trigger events: New AWS account creation, account onboarding, incident response, Security Hub finding, or exceptions request.
• Exception rule: “None” should be the default. If someone claims a business need, require documented root-only task justification and route them to a non-root solution.

This aligns with the benchmark’s expectation that requirements are implemented in an operable way, not just written into policy. ²

Step 2: Detect whether a root access key exists ²

Use one or more of these approaches:

Option A (preferred for auditability): AWS Security Hub

• Enable Security Hub and the CIS AWS Foundations standard where applicable.
• Locate the control mapped to this requirement (IAM.4) and confirm it reports pass/fail per account. ³

Option B: AWS CLI / API check (spot checks and incident response)

• Sign in as root (interactive) only if absolutely required to verify account settings, and only under your break-glass procedure.
• For day-to-day verification, rely on Security Hub outputs or centralized config/compliance tooling rather than repeated root sign-ins.

What “pass” looks like: The root user has no access keys present. No “inactive spare,” no “just in case” backup key.

Step 3: Remediate immediately if a root access key is found

If Security Hub (or another check) indicates root has access keys:

1. Open an incident or high-priority ticket (security finding with tracking to closure).
2. Confirm scope: Identify which AWS account and whether one or two keys exist.
3. Delete the root access key(s) (do not rotate root keys; remove them).
4. Hunt for use: Review logs to see whether the root key was used and what actions it performed. Route suspicious activity into your incident response process.
5. Eradicate dependencies: If any automation depended on root keys, replace it with:
   • IAM roles with least privilege and short-lived sessions, or
   • CI/CD roles with external identity federation, or
   • AWS service roles as designed.
6. Validate closure: Re-run the detection check and confirm the control is passing.

Security Hub’s mapped control provides a clean “before/after” evidence trail when retained properly. ³

Step 4: Prevent recurrence (the part auditors care about)

Deleting keys once is not the control. Sustained prevention is.

• Guardrails for account vending / new account creation: Make “root has no access keys” a required acceptance criterion before an account is marked production-ready.
• Break-glass design: Document that root usage must be interactive with MFA and logged, and that programmatic root keys are prohibited.
• Continuous monitoring: Keep Security Hub findings integrated into your ticketing system so failures create tracked work items with owners and due dates. ³
• Third party governance: If a third party requests root access keys, your standard answer is “no.” Provide time-boxed, least-privileged roles instead, and require your own staff to supervise any root-only tasks.

Required evidence and artifacts to retain

Build a minimum evidence bundle that answers: “How do you know root keys don’t exist, and how do you prove it over time?”

Evidence to collect ²:

• Security Hub control status exports or screenshots showing the IAM.4 control result per account, with timestamps. ³
• Ticket(s) and remediation records for any findings, including:
  • finding ID/reference,
  • owner,
  • remediation steps,
  • closure validation proof.
• Runbook / control card (owner, cadence, triggers, exception handling).
• Account inventory indicating which AWS accounts are in scope for the control.
• Change record or post-incident note if you removed root keys and refactored automation.

Retention location: A GRC evidence repository (or equivalent) with immutable storage controls where possible, plus links to Security Hub reports and ticketing records.

Common exam/audit questions and hangups

Auditors and customer assessors tend to press on a few predictable points:

1. “Show me proof for every AWS account.”
   A single screenshot from one account is not enough in a multi-account environment. Export per-account Security Hub status or provide an aggregated report. ³

2. “How do you know this stays true after new account creation?”
   You need an onboarding gate plus monitoring, not a one-time cleanup.

3. “What’s your exception process?”
   The clean answer is: no exceptions for root access keys. If you allow exceptions, expect deep scrutiny and compensating controls that are difficult to defend.

4. “What happens if Security Hub is off?”
   Document fallback checks and alerting ownership. Also document who owns turning Security Hub on in new accounts.

Frequent implementation mistakes (and how to avoid them)

Mistake	Why it fails	Better approach
Keeping a disabled root key “just in case”	The requirement is “should not exist,” not “should be inactive”	Delete the key and use break-glass MFA for root
Treating this as policy-only	Audits test operation, not intent	Tie Security Hub findings to tickets and evidence bundles 3
Fixing one account and forgetting the org	Violations reappear during onboarding	Add an account acceptance checklist and recurring control health checks
Letting a third party request root keys for setup	Expands exposure and breaks accountability	Issue scoped roles; supervise root-only actions if ever needed

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific CIS requirement. Still, the risk is straightforward: root access keys create high-impact credential theft scenarios and reduce traceability compared to federated roles and short-lived sessions. From a GRC standpoint, this control is commonly requested in security questionnaires and cloud risk reviews because it is easy to test and directly tied to blast radius reduction. ²

Practical 30/60/90-day execution plan

Use phases to avoid slipping into a “big bang” project while still driving fast risk reduction.

First 30 days (stabilize and clean up)

• Assign control owner and publish the runbook/control card.
• Turn on or confirm AWS Security Hub CIS mapping coverage where applicable; confirm IAM.4 visibility across accounts. ³
• Identify all failing accounts and delete any root access keys immediately.
• Open and close remediation tickets with validation evidence.

Next 60 days (industrialize)

• Add a gating step to account onboarding: account is not “ready” until Security Hub shows pass for IAM.4.
• Integrate Security Hub findings with ticketing and escalation.
• Document the break-glass procedure (root interactive access only, MFA enforced, approvals/logging expectations).

Next 90 days (prove sustained operation)

• Run a control health review and confirm evidence completeness (monitoring outputs, closure tickets, inventory).
• Exercise the exception path (tabletop). Your goal is to confirm you can say “no” to root keys and still support urgent operational needs.
• If you manage third parties, update onboarding language so third parties never require root keys for delivery.

Where Daydream fits: Daydream becomes useful once you have the control logic and want repeatable evidence operations: assigned ownership, a standard evidence bundle per cycle, and tracked remediation to validated closure without hunting through consoles during audit season.

Frequently Asked Questions

Does enabling MFA on the root user satisfy CIS AWS Foundations v1.2 1.12?

No. MFA is a separate control objective. This requirement is specifically that the root user access key should not exist, regardless of MFA.

What if we need programmatic access for a one-time account setup task?

Don’t use root keys. Create a tightly scoped IAM role for the task, time-box access, and remove permissions after completion. If a task truly requires root, perform it interactively under a break-glass process.

We found a root access key but it’s inactive. Is that compliant?

No. “Should not exist” means delete it. Auditors commonly treat “inactive but present” as a failure because the key can be reactivated.

How do we prove this across a multi-account AWS Organization?

Retain Security Hub evidence that shows the IAM.4 control status per account, plus your account inventory that defines scope. ³

Can a third party (MSP/consultant) hold root keys if they’re contractually bound?

Contract terms don’t change the technical control outcome. If a root access key exists, you fail the requirement. Provide least-privileged roles and supervise any root-only actions.

What evidence will an auditor accept if we don’t use AWS Security Hub?

Provide a repeatable report from your chosen compliance tooling that demonstrates root has zero access keys per account, plus the runbook and remediation records. If you use Security Hub, the mapping is explicit and easier to defend. ³

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