Root credentials and break-glass
Lesson 5 of 5 in The Multi-Account Foundation.
The account root user is the identity created with the account, authenticated by the account's email address, and unconstrained by IAM policies, permission boundaries or service control policies. You cannot restrict it with an identity policy because it has no identity policy; an SCP does bind a member account's root user, which is a genuine control, but the management account's root user is bounded by nothing you can write.
So the discipline is not "secure root" so much as stop needing it. The baseline every standard expects: no access keys on the root user ever, hardware or virtual MFA enabled, a long unique password nobody has memorised, and an email address on a monitored distribution list rather than a departed engineer's mailbox. Then a small set of tasks remains that genuinely requires root — and the exam wants you to know which ones, because candidates habitually reach for root when an IAM role would do.
| Task | Root required? | How you do it in 2026 |
|---|---|---|
Close the AWS account; change the account name, root email or support plan | Yes — account-level, not API-level, operations | Root sign-in (or, for closing a member account, the management account’s Organizations console) |
Recover from a bucket policy or SQS queue policy that denies every principal | Yes — nobody else can read or replace the policy | The classic lockout, and now the headline use of a centrally assumed root session instead of a root password |
Restore access after the last administrator revoked their own permissions | Yes | Root sign-in, or a centrally assumed root session from the management account |
Enable S3 MFA delete on a bucket; register as a Reserved Instance Marketplace seller | Yes — narrow, rare, documented exceptions | Root sign-in, pre-approved and alarmed |
Everyday administration — IAM, networking, data, deployments | No, and using root here is the finding | Federated human access through IAM Identity Center, with roles per job |
Emergency administrative access when federation is broken | No — this is what people get wrong | A dedicated break-glass IAM role per account, alarmed and time-boxed. Root is the last resort, not the designed one |
Centralized root access is the structural answer at organization scale. Enable root credentials management in IAM from the management account (it needs Organizations with all features and trusted access for IAM), and two things become possible.
First, you can delete the root user credentials of member accounts entirely — password, MFA devices, signing certificates, any access keys. The account keeps its root user as an entity; what it no longer has is a long-term credential anyone could phish, reuse or leave in a password manager. For an organization with two hundred accounts, that is two hundred unmanaged administrator credentials removed in one programme rather than two hundred password rotations repeated forever.
Second, the privileged tasks that genuinely need root are performed centrally and temporarily. A permitted principal in the management account takes a short-lived root session into a specific member account (sts:AssumeRoot), scoped by a task policy to one job — unlock a deny-all bucket policy, delete a deny-all queue policy, audit or delete root credentials — does it, and the session expires in minutes. The credential that used to sit in a safe is now an authorized, logged, expiring action.
Recovery stays available: the member account's root password can be recovered through the account email if an edge case demands it, so removing credentials is not a one-way door.
A break-glass procedure that survives an audit
- Emergency declared
Federation is down, or a lockout needs an identity no policy can restrict. The trigger is written down in advance — not decided at 3am.
- Can a scoped root session do it?
Deny-all bucket and queue policies, and root credential audits, are exactly the tasks centralized root access covers. If so, no credential leaves the safe at all.
- Short-lived root session from the management account
Task-scoped, expiring in minutes, authorized by an IAM policy and recorded in CloudTrail as an assumed root session.
- Two-person approval, recorded
Separate custodians: one holds the password envelope, another the hardware MFA token. Neither can act alone.
- Root sign-in
Hardware MFA, from a known device and network if you can constrain it. CloudTrail records the ConsoleLogin event with userIdentity.type = Root.
- Alarm fires — security watches live
The alarm is not a post-hoc audit artifact: it is the control that distinguishes an approved break-glass from an attacker who reached the same credential.
- Perform only the pre-approved task
Scope creep during a break-glass session is the incident inside the incident. The runbook lists the exact steps.
- Rotate, re-seal, write it up
New password, new envelope, MFA re-verified, ticket updated with who, when, why and what was changed.
- Review: can this stop requiring root?
Every genuine break-glass use is a backlog item. The target is a procedure you rehearse and never need.
Alarm on root usage
The standard control, and the one to be able to write from memory. A CloudWatch Logs metric filter over the CloudTrail log group, incrementing a metric on any root API activity, with an alarm at a threshold of 1 publishing to an SNS topic the security team actually reads:
{ $.userIdentity.type = "Root"
&& $.userIdentity.invokedBy NOT EXISTS
&& $.eventType != "AwsServiceEvent" }
The two exclusions matter. invokedBy NOT EXISTS drops events an AWS service performed on the account's behalf, and eventType != "AwsServiceEvent" drops service-generated events — without them the alarm cries wolf and gets muted, which is worse than not having it.
EventBridge on console sign-in
For the narrower "someone signed in as root" signal, an EventBridge rule matching the CloudTrail ConsoleLogin event where userIdentity.type is Root, targeting SNS, a Lambda that pages, or a Systems Manager automation. In an organization, put the rule where the events land — the organization trail's account, or an EventBridge rule per account forwarding to a central bus.
Pair it with the logging architecture from Domain 1: this is a detective control whose value is entirely in how fast a human sees it.
Continuous posture checks
Config managed rules check the state rather than the event: root-account-mfa-enabled, root-account-hardware-mfa-enabled, iam-root-access-key-check. Security Hub's CIS and AWS Foundational standards include the equivalent controls, so enabling the standard org-wide gives you root hygiene across every account without writing a rule.
State checks and event alarms answer different questions — is root configured safely? versus is root being used right now? — and a complete answer carries both.
Key terms: Centralized root access, Break-glass procedure, Management account, Preventive control
Interactive checkpoint quiz (2 questions) — open this page in a browser to take it.