If you’ve accidentally locked yourself out of AWS by removing the AdministratorAccess policy from all IAM users and roles, you’re not alone. I’ve helped teams recover from this exact scenario multiple times, and there’s a systematic way to regain access without losing data or rebuilding your entire infrastructure. In this post, I’ll walk through exactly how to recover from an IAM admin lockout and how to prevent it from happening again.

The Problem

You’ve either deleted all IAM admin users, detached AdministratorAccess from all roles, or applied an SCP that blocks iam:* actions. Now when you try to log in or make API calls, you get:

Error Type Error Message
AccessDenied User: arn:aws:iam::123456789012:user/alice is not authorized to perform: iam:AttachUserPolicy on resource: arn:aws:iam::123456789012:user/bob

No user or role can perform any IAM action to fix the situation. You’re completely locked out. The good news: you’re not actually locked out. The root user exists outside normal IAM policy evaluation, and you can use it to recover.

Why Does This Happen?

  • Deleted the wrong user or role: Removed a user that was the only admin-level principal in the account
  • Detached AdministratorAccess from all users/roles: Removed the policy from all principals without leaving at least one with admin access
  • Overly restrictive SCP applied: An SCP denies all iam:* actions without an exception for a break-glass role, locking out even admins
  • Removed root user MFA device: Can’t log in as root because MFA was enabled and the device is lost
  • Root user email access lost: Can’t reset root password because you don’t have access to the email on the account

The Fix

Step 1: Access the Root User Account

The root user is not subject to IAM policies or SCPs. It operates outside normal permission evaluation, making it the ultimate recovery mechanism.

If you still have access to the root user’s email:

  1. Go to the AWS sign-in page
  2. Click “Root user” and enter the AWS account email address
  3. If MFA is enabled, you’ll need the MFA device. If you have it, proceed. If not, go to Step 2 below.
  4. Once logged in as root, you can re-attach AdministratorAccess to any IAM user or role:
# Attach AdministratorAccess to a user
aws iam attach-user-policy \
  --user-name alice \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

# Or attach to a role
aws iam attach-role-policy \
  --role-name MyRole \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

Step 2: If Root MFA Device is Lost

If root MFA is enabled but the device is lost, you’ll need to use AWS account recovery. This is a manual process:

  1. Go to AWS Account Recovery
  2. Select “I cannot sign in as the root user”
  3. Verify you own the account (via email or phone)
  4. AWS will temporarily disable MFA on the root account
  5. Log in as root and address the lockout
  6. Re-enable MFA with a new device

This process can take a few hours depending on AWS support load.

Step 3: If SCP is Blocking IAM Actions

If an SCP is blocking all iam:* actions, even the root user is affected in member accounts. However, the management account root user is NOT subject to SCPs.

From the management account root user:

# List all SCPs affecting the member account
aws organizations list-policies-for-target \
  --target-id 123456789012 \
  --filter SERVICE_CONTROL_POLICY \
  --output text

# Get the problematic SCP
aws organizations describe-policy \
  --policy-id p-xxxxxxxxxx \
  --query 'Policy.Content' \
  --output text | jq .

# Create an exception for a break-glass role
# Edit the SCP to add a NotAction clause:

A proper SCP for production should look like this, with a break-glass exception:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": "iam:*",
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:PrincipalArn": "arn:aws:iam::123456789012:role/BreakGlassAdminRole"
        }
      }
    }
  ]
}

This denies all IAM actions EXCEPT for the BreakGlassAdminRole. Use that role to recover.

Step 4: Restore Admin Access

Once you’ve accessed the root user or a break-glass role, restore admin access to regular IAM users:

# Attach AdministratorAccess to a user
aws iam attach-user-policy \
  --user-name alice \
  --policy-arn arn:aws:iam::aws:policy/AdministratorAccess

# Verify the user now has admin access
aws sts get-caller-identity \
  --output text

Have the user run this command from their own credentials to verify they have access.

Prevention: Set Up a Break-Glass Emergency Account

To prevent future lockouts, create a dedicated break-glass account with these properties:

  1. Dedicated root account with no regular use
  2. No **IAM users or roles** — access is only via root account
  3. MFA enabled but device stored securely (vault, password manager)
  4. Exempted from all restrictive **SCPs* using a NotAction condition
  5. Documented and communicated to your security team

Example break-glass SCP exception (in the organization management account):

{
  "Effect": "Deny",
  "Action": "iam:*",
  "Resource": "*",
  "Condition": {
    "StringNotEquals": {
      "aws:PrincipalAccount": "123456789012"
    }
  }
}

This denies all IAM actions in member accounts but allows the entire break-glass account (123456789012) to perform IAM actions.

Lockout Prevention Checklist

  1. Never remove AdministratorAccess from all users → Keep at least one admin user or role with explicit permissions
  2. Always test SCPs before applying → Verify they don’t block necessary actions
  3. Create a break-glass account → Dedicated account with root access and SCP exceptions
  4. Document your recovery process → Write down recovery steps and store them securely
  5. Test recovery quarterly → Periodically verify you can still access the break-glass account
  6. Enable CloudTrail → Log who does what, so you can audit who made the breaking change

Is This Safe?

Root user access is powerful and must be handled carefully. Use it only for emergency recovery and then switch back to IAM users/roles for regular operations.

Key Takeaway

An IAM admin lockout is recoverable using the root user account, which operates outside normal IAM policy and SCP evaluation. Always have a break-glass recovery account with root access and SCP exceptions configured. In my experience, teams that experienced an IAM lockout don’t make the same mistake twice — they immediately implement proper break-glass procedures.

Have questions or ran into a different IAM issue? Connect with me on LinkedIn or X.