Protecting Cloud Control-Plane Recovery Accounts and Credentials: Keep Root and Super Admin Access Safe and Usable

The accounts that can recover a cloud estate (the AWS root user, the Organizations management account, Microsoft Entra emergency access accounts and Google super administrators) are also the accounts that can destroy it, and attackers know it. If these credentials are stolen, the attacker can delete backups, lock out every administrator and hold the estate to ransom; if they are lost, a mundane outage becomes a crisis because nobody can fix the policy that locked everyone out. This guide covers how each major cloud handles top-level recovery, how attackers target recovery channels such as the root email inbox and recovery phone, and how to design, store, monitor and test these accounts so they stay both protected and usable. It complements the directory-focused Break-Glass Account Guide and is written for cloud platform, IAM and security operations teams.

Key takeaways

• Recovery channels are credentials: the root email inbox, recovery phone numbers and spare security keys can reset the most powerful accounts, so protect them as strictly as the passwords.
• Remove what you do not need: AWS centralised root access lets you delete root credentials from member accounts entirely, leaving one well-protected management path instead of hundreds of root users.
• Separate the people: AWS suggests splitting the root password and MFA between two groups and assigning the recovery email and phone to different people, so no single person (or single phished person) can act alone.
• Every use is an incident until proven otherwise: sign-ins by root, emergency or super admin accounts should page someone, with a runbook that starts by asking "was this us?".
• Test or it does not exist: Microsoft recommends validating emergency accounts at least every 90 days; untested recovery accounts often fail on an expired phone number or a departed holder.

Recovery accounts across the three major clouds

AWS: root users and the management account

• Centralise root access: with centralised root access enabled in AWS Organizations, you can delete member account root passwords, access keys, signing certificates and MFA devices. New member accounts have no root credentials by default and cannot run root password recovery unless the management account (or IAM delegated administrator) runs the "Allow password recovery" task.
• Use privileged task sessions for root-only fixes: an IAM principal in the management or delegated administrator account calls sts:AssumeRoot against a Regional STS endpoint with a task policy such as IAMDeleteRootUserCredentials, IAMCreateRootUserPassword, S3UnlockBucketPolicy or SQSUnlockQueuePolicy. Grant sts:AssumeRoot to very few roles and restrict it further with the sts:TaskPolicyArn condition key. This permission is now itself a recovery credential.
• Know what still needs root: for standalone accounts, changing the root email or password, closing the account and restoring IAM permissions when the only administrator locked themselves out; for any account, configuring S3 MFA Delete and recovering an unmanageable KMS key through AWS Support.
• Protect the management account root above all: it can reach every member account. Register several FIDO security keys (AWS allows up to eight MFA devices), never create root access keys (use aws login for temporary root CLI credentials if ever needed), and use a business-managed group email address not used for anything else.
• Deny root in members: apply an SCP that denies root actions in member accounts. See the AWS Organizations and SCPs Guide.

Microsoft Entra ID and Azure: emergency access and elevation

• Emergency accounts: Microsoft recommends at least two cloud-only accounts on the *.onmicrosoft.com domain, not federated or synchronised from on-premises, with Global Administrator assigned as permanent active rather than eligible in Privileged Identity Management. Authenticate with a FIDO2 passkey or certificate-based authentication, using a method different from normal admin accounts, on a credential that does not expire.
• Conditional Access: exclude these accounts through a dedicated group (for example EmergencyAccess) from any enforced policy that could block them, then test sign-in at least quarterly against the current policy set.
• Elevate access: a Global Administrator who sets "Access management for Azure resources" to Yes receives User Access Administrator at root scope, which can grant access to every subscription and management group. The setting is per user, it is not reset when a PIM role is deactivated, and it is logged under the "Azure RBAC (Elevated Access)" audit service. Treat it as a recovery capability that should be off by default and alerted on.
• Tenant-wide destructive power: in the Stryker Intune wiper attack, a compromised administrator account was used to create a new Global Administrator, and a source cited by BleepingComputer said Intune's wipe command then erased nearly 80,000 devices. The recovery accounts must survive exactly this scenario: separate from everyday admin accounts and monitored.

Google Cloud and Workspace: super administrators

• Separate and few: Google recommends more than one super admin, each managed by a different person, each with a separate non-admin account for daily work, signing in to the super admin account only for super admin tasks.
• Daily work elsewhere: put day-to-day Google Cloud administrators in a private group granted the Organization Administrator role (or a subset), without the super admin in it.
• Recovery settings: enrol more than one security key and store the spare safely, generate backup codes, and set a recovery phone and email. Self-recovery is off by default for new customers and Google Cloud advises keeping it disabled, but some existing customers with fewer than 3 super admins or 500 users have it on by default, so check rather than assume.
• Monitoring: Google Cloud recommends alerts on SetIamPolicy() calls so any change to an allow policy is noticed.

How attackers target recovery access

Destruction and extortion do not need the top account if long-lived keys already have enough rights: in the Codefinger S3 ransomware campaign, stolen AWS access keys with S3 read and write permissions were used to re-encrypt data with keys only the attacker held. Recovery planning has to assume both paths. Unauthorised compute abuse is the other common outcome of stolen top-level credentials. See the Cryptojacking Guide.

Storing and holding recovery credentials

Change safe combinations when a holder leaves (Microsoft explicitly recommends this), keep the holder list short and current, and record every access to the safe.

Where identity fits: non-human paths to the top

Automation often holds rights close to recovery level: a deployment role in the management account, a service principal with Global Administrator or a Workspace service account with domain-wide delegation. These non-human identities need the same treatment as recovery accounts: inventory, no static keys where federation is possible, alerts on use outside pipelines, and removal of rights not needed. See the Cloud PAM and CIEM Guide.

Implementation: a phased approach

1. Inventory: every AWS management and standalone account root, every principal with sts:AssumeRoot, every Entra Global Administrator and emergency account, every Google super admin. Record recovery email, recovery phone, MFA devices and holders for each.
2. Reduce: enable centralised root access and delete member root credentials; cut Google super admins and Global Administrators to the minimum that still gives redundancy.
3. Harden channels: move recovery emails to dedicated group mailboxes with phishing-resistant MFA, move recovery phones to corporate numbers with different holders, enrol at least two hardware keys per account.
4. Monitor: deploy the alerts below before you need them, and route them to an on-call channel that does not depend on the same tenant.
5. Test in a pilot first: rehearse a member account root recovery through "Allow password recovery" in a sandbox account, and an emergency account sign-in against Conditional Access in report-only mode before enforcing changes.
6. Rollback: keep at least one tested recovery path working while changing another, and never delete the last root credential or super admin before the replacement path is proven.

Small versus large organisations: a small organisation with one AWS account and one Workspace tenant may only need two hardware keys, one sealed envelope and a group mailbox. A large organisation with hundreds of accounts should centralise root access, restrict sts:AssumeRoot to a small break-glass role with multi-person approval, and run quarterly recovery drills.

Detection and measurement

• AWS: CloudWatch or EventBridge rules with SNS for root sign-in and usage, GuardDuty root credential usage findings, and AWS Config, Security Hub CSPM or Trusted Advisor checks for root MFA and root access keys. Alert on AssumeRoot calls and on changes to the account's root email or contacts.
• Entra ID and Azure: a Severity 0 alert on any emergency account sign-in by object ID, plus alerts on "Azure RBAC (Elevated Access)" audit events and on Global Administrator assignments.
• Google: alerts on super admin sign-ins, super admin role grants, recovery setting changes and SetIamPolicy().

Common failure patterns

• Root email on a personal or departed employee's mailbox: nobody can reset the password, or an outsider can.
• Emergency accounts caught by a new Conditional Access policy: an MFA or compliant-device policy rolled out to "All users" silently disables the recovery path.
• Elevated access left on: User Access Administrator at root scope stays assigned after the task because deactivating the PIM role does not reset it.
• Recovery accounts used for daily work: their credentials are then exposed to the same phishing and session theft as everyone else.
• Backups recoverable only with the same credentials: if one identity can delete production and backups, a single compromise destroys both.
• Self-recovery left on by default: some older Google tenants have super admin self-recovery enabled without anyone deciding it.

Framework mapping

Practitioner checklist

• Inventory every root, management account, emergency and super admin identity with its recovery channels and holders.
• Enable AWS centralised root access and delete member account root credentials.
• Restrict sts:AssumeRoot to a few roles and constrain task policies with sts:TaskPolicyArn.
• Register at least two hardware security keys per recovery account and store them in separate locations.
• Use dedicated group mailboxes and corporate phone numbers for recovery, held by different people.
• Exclude emergency accounts from blocking Conditional Access through a dedicated group and test quarterly.
• Keep Azure elevated access off by default and alert on every elevation.
• Keep Google super admin self-recovery disabled and super admins separate from daily accounts.
• Alert on every recovery account sign-in and recovery setting change to an out-of-band channel.
• Store backups under credentials that cannot also delete production.

Standards and references

• AWS: Root user best practices for your AWS account
• AWS: AWS account root user
• AWS: Perform a privileged task on an AWS Organizations member account
• Microsoft Learn: Manage emergency access admin accounts in Microsoft Entra ID
• Microsoft Learn: Elevate access to manage all Azure subscriptions and management groups
• Google Cloud: Super administrator account best practices
• Google Workspace: Security best practices for administrator accounts
• NIST: SP 800-53 Rev. 5

Related NHI Mgmt Group resources: Break-Glass Account Guide · Cryptojacking Guide · Cloud Recovery and Clean Room Guide · Admin panels and super admin accounts