IAM User Suddenly Losing Admin Access Due to Permissions Boundary

When a Permissions Boundary is attached to an IAM user, it sets the maximum allowed permissions. If an action isn't explicitly allowed by the boundary, it is denied - even if you have AdministratorAccess.

How to Recover Access

Since your IAM user is locked out, you cannot remove the boundary yourself. You must use a higher privilege:

• Root User: Log in using the account's root email address. The root user bypasses IAM boundaries and can remove the restriction from your IAM user.

• AWS Organizations: If this is a member account, a central admin can assume the OrganizationAccountAccessRole from the management account to fix it.

How to Identify Who Did It

Go to AWS CloudTrail (Event history) and filter by Event name: PutUserPermissionsBoundary. The log will reveal the exact IAM user, role, or automation script that applied the restriction.

See also:

• https://repost.aws/knowledge-center/iam-access-denied-root-user

Since you cannot access the Support console or CloudTrail, and an IAM user cannot bypass its own boundary, there is no technical backdoor for DDI_ADMIN. You must regain access externally. Here are your three options:

• 1. Root Password Reset: If you know the root email address, go to the AWS sign-in page, select Root user, and click Forgot password?. If someone in your company monitors that inbox, you can reset the password and remove the boundary.

• 2. Public Account Recovery: If you don't know the root email, use the public AWS Account Recovery form. Select I cannot log into my AWS account. Be prepared to prove account ownership using past invoices or credit card details.

https://support.aws.amazon.com/#/contacts/one-support?formId=contactU

Hi, The other answers cover the main recovery paths (root, Organizations, recovery form), but a few important points are missing — and one of them might unblock you without a full root recovery. Let me lay it out end to end.

First, an important distinction: is this really a permissions boundary, or could it be an SCP?

The error message "no permissions boundary allows the action" points to a boundary, but losing billing + IAM + account settings + support all at once can also come from an Organizations SCP or a modified identity-based policy. This matters because it changes who can fix it:

• Permissions boundary or identity policy → the account's root user can remove it (root ignores boundaries and IAM policies entirely).
• **SCP **→ root of a member account is still subject to SCPs. Only the Organizations management account can change it. A root password reset on this account would not help in that case. So before spending effort on root recovery, figure out which one you're dealing with.

Try to read your own boundary (you may still have read access): Even with a restrictive boundary, you might still have iam:GetUser. Run:

aws iam get-user --user-name DDI_ADMIN

Look at the PermissionsBoundary field — it shows the ARN of the policy attached. Knowing which policy it is tells you the intent (e.g. a "developer" boundary applied by mistake) and is useful information for AWS Support.

Recovery options, in order of speed:

• Check if this account belongs to an AWS Organization / was created by someone else. If an MSP, reseller, partner, or a central IT team created this account, there is almost certainly a management account that can assume OrganizationAccountAccessRole (or a similar cross-account role) and remove the boundary in minutes. Ask internally: who created this account, and do we go through a reseller/MSP? This is the fastest path and the one most people overlook.
• Root password reset. If your company controls the root email inbox (even if nobody uses it), go to the AWS sign-in page → Root user → Forgot password?. Root bypasses boundaries and can fix the user. If MFA is enabled on root and you don't have the device, use the MFA recovery flow (alternate authentication via email + registered phone).
• AWS Account Recovery / Support. If you don't know the root email, use the public account recovery form ("I cannot log into my AWS account") and be ready to prove ownership with past invoices or the card on file. If you happen to have Business/Enterprise Support, you can also reach Support by phone. https://support.aws.amazon.com/#/contacts/one-support?formId=contactUs

Once you regain access — treat this as a possible security event, not just a misconfig. A restrictive boundary appearing "suddenly" with nobody owning the change is worth investigating as potential unauthorized activity. In CloudTrail (Event history), filter for:

• PutUserPermissionsBoundary (who applied the boundary, when, from which identity)
• AttachUserPolicy / DetachUserPolicy / PutUserPolicy
• CreateAccessKey / DeleteAccessKey and any unusual ConsoleLogin events
• If it turns out to be an SCP, check AttachPolicy at the Organizations level from the management account

If anything looks unauthorized, rotate credentials and follow the AWS guidance for compromised accounts.

To prevent a repeat: This is the classic single-point-of-failure on one IAM user. After recovery:

• Secure the root user with MFA and store the credentials safely.
• Keep at least one break-glass admin identity separate from daily-use ones.
• Move to IAM Identity Center instead of long-lived IAM users.
• Add an EventBridge rule to alert on PutUserPermissionsBoundary and SCP changes so this can't happen silently again.

Bottom line: confirm boundary vs SCP first, try the Organizations/MSP route before root recovery (it's usually fastest), and once you're back in, check CloudTrail to confirm whether this was an error or unauthorized activity.