7.1.5. Root User Credential Management
First Principle: The root user has unrestricted access to every resource in an account. SCPs can restrict a member account's root user but never the management account's, and a deny policy still leaves the credential itself to be protected. Securing root credentials is therefore the single highest-priority credential management task in any AWS environment.
Centralized Root Access Management — expanded in C03:
- AWS Organizations supports centralized root access for member accounts
- Eliminates the need for individual root passwords on each member account
- Root access for member accounts can be managed through the management account
- Reduces the number of root credentials that need protection
Root User Security Best Practices:
| Control | Implementation |
|---|---|
| MFA on root | Hardware MFA device (recommended) or virtual MFA |
| No access keys | Delete all root access keys — use IAM roles instead |
| Email security | Dedicate a distribution list email for root (not personal email) |
| Break-glass procedures | Documented process for emergency root access with approval workflow |
| Monitoring | CloudWatch alarm on root login (ConsoleLogin where userIdentity.type = Root) |
Break-Glass Procedure Design:
- Root credentials stored in a hardware-encrypted safe or secrets vault (physical security)
- MFA device stored separately from credentials (dual-control)
- Access requires approval from 2+ authorized personnel
- All root usage is logged and reviewed within 24 hours
- Root password rotated after every use
Federation is itself a dependency: if the identity provider is down, so is SSO-based access. Keep a few emergency IAM users that do not depend on it — MFA-protected, credentials held under the same dual-control process, and alarmed on any use — so that root stays the last resort.
⚠️ Exam Trap: SCPs DO apply to the root user of member accounts (only the management account is exempt), so a deny SCP can block member-account root actions — but every root password still exists and must be protected. When a question asks how to reduce root credential risk across many member accounts, centralized root access management, which removes member-account root credentials, is the answer rather than an SCP.
Scenario: A security audit reveals that 50 member accounts each have independent root credentials, 12 of which lack MFA. You enable centralized root access management through Organizations, eliminating individual root passwords, and configure CloudWatch alarms for any root account activity.
Reflection Question: Why does blocking root actions with an SCP still leave risk that centralized root access management removes?
