IAM access lockout

Lockout means you cannot administer the account with the identities you normally use. Recover with a pre-created emergency identity, not a creative delete. Design: multi-cloud identity.

Symptoms

Console login loops, MFA that cannot complete, or AccessDenied / 403 on every write. PIM activation fails for every eligible admin. IAM Identity Center or another IdP is down. An SCP, management-group policy or organization policy now denies iam:*, Microsoft.Authorization/* or resourcemanager.googleapis.com. Someone deleted the last user in the admin group. If workloads still serve traffic, this is a control-plane incident.

Business impact

You cannot patch IAM, rotate keys, or reverse a bad change. If billing or DNS is in the same lockout, you also cannot pay or fail over. Deleting “stale admins” can remove the last principal that could recover the account. Provider support is not the first step; break-glass is.

Immediate checks

1. Stop applying Terraform, Bicep, Deployment Manager or console IAM changes.
2. Write down the last change: policy JSON, Conditional Access, SCP, org policy, group membership.
3. Confirm whether end users are locked out or only operators. Different scopes.
4. Locate break-glass material: vault entry, hardware MFA, emergency account list.
5. If one person can still read CloudTrail, Entra logs or Audit Logs, have them pull the denied events. Do not let them attach new deny statements.

Provider commands and console paths

AWS. If Identity Center is down, use the IAM user or root path documented for emergency access. Root is for a short list of account-recovery tasks; AWS also documents a dedicated emergency IAM user and an emergency access process. Organizations can perform some member-account root tasks through centralized root access.

aws sts get-caller-identity
aws iam get-account-authorization-details
aws organizations list-policies --filter SERVICE_CONTROL_POLICY
aws cloudtrail lookup-events --lookup-attributes AttributeKey=EventName,AttributeValue=AttachUserPolicy

Those read calls work only if your current principal is still allowed. If they fail, stop using that principal.

Azure. Microsoft Entra admin center. Use a cloud-only emergency access account with a permanent Global Administrator assignment, as documented in emergency access accounts. PIM is for eligible admins during normal operations (PIM). If Conditional Access locked everyone, the emergency accounts must already be excluded.

az ad signed-in-user show
az role assignment list --assignee OBJECT_ID
az account management-group list

Sign-in logs: Entra ID, Sign-in logs, filter Conditional Access failures.

Google Cloud. Cloud Console, IAM. Organization Admin is an organization-level role (organization access control). If Cloud Identity or Google Workspace is the IdP, a Workspace super admin may be required to recover the user that holds Organization Admin.

gcloud auth list
gcloud organizations get-iam-policy ORGANIZATION_ID
gcloud resource-manager org-policies list --organization=ORGANIZATION_ID

Alibaba Cloud. Resource Directory management account, or a RAM user that still has AdministratorAccess-equivalent rights. RAM console: users, groups, policies. ActionTrail for the deny.

aliyun ram GetUser --UserName USER
aliyun ram ListPoliciesForUser --UserName USER

If those flags do not match your CLI version, use the RAM console and the RAM help center rather than improvising.

Interpretation

IdP or MFA outage: local emergency users should still work if they are not federated. Federated-only admin models fail together.

Conditional Access or SCP too tight: the last change is the cause. Revert that object, do not rewrite the entire identity platform.

Deleted last admin: you need root, emergency Global Administrator, Organization Admin or the Resource Directory management account. There is no in-band IAM API left to use.

Key or client-secret expiry: create a new credential from break-glass, then disable the expired one after you confirm a second admin exists.

Safe mitigation

Authenticate as the emergency identity. Revert the last policy, SCP, org policy or Conditional Access change from version history. Restore a second named admin (or a second PIM-eligible Global Administrator) before you log out. Leave Azure emergency accounts as permanent assignments. File the break-glass use.

Risky actions to avoid

Do not delete the last admin, the last Global Administrator, Organization Admin or Resource Directory owner.

Do not attach AdministratorAccess or Owner to a wide group so “someone can get in.” You have multiplied the incident.

Do not disable MFA on root or Global Administrator as a shortcut.

Do not rotate root or break-glass passwords in Slack.

Do not remove the emergency accounts from Conditional Access exclusions to “make policy consistent” while you are still locked out.

Validation

A normal operator assumes the admin role or activates PIM. A second person repeats the login. Audit logs show the emergency sign-in and the revert. Return MFA devices and vault secrets to storage.

Prevention

1. Keep two emergency identities that are cloud-native, vaulted, monitored, and excluded from the corporate IdP and from Conditional Access that can lock the tenant.
2. AWS: an emergency IAM user plus controlled root, following the current AWS emergency-access guidance. Azure: two emergency Global Administrators; PIM for everyone else. Google Cloud: more than one Organization Admin, plus a Workspace super admin if you use Cloud Identity. Alibaba Cloud: Resource Directory management-account credentials that are not bound to one laptop.
3. Test break-glass on a written schedule. A vaulted password that has never been used is an untested recovery path.
4. Alert on any use of the emergency identity.
5. Follow the provider emergency-access pages linked below, not informal folklore.