A team member panicked during a meeting: “I can’t create accounts in Organizations anymore. I’m getting AccessDenied.” My first thought was an SCP was blocking it, so I checked the organization—but then realized: SCPs don’t apply to the management account. That’s a fundamental Organizations rule. The real issue was an IAM policy or permission boundary on their role. In this post, I’ll walk through exactly how management account permissions work and how to recover access.

The Problem

You’re in the AWS Organizations management account, trying to perform org-level actions, but getting:

  • AccessDenied or UnauthorizedOperation errors
  • Root user can perform the action, but IAM roles/users can’t
  • You suspect an SCP is blocking you, but nothing makes sense
  • Permission boundaries seem to be involved but you’re not sure
Action Error Suspected Cause
organizations:CreateAccount AccessDenied SCP blocking? (No—SCPs don’t apply to mgmt account)
organizations:AttachPolicy UnauthorizedOperation IAM policy missing? (Yes)
Any action AccessDenied Permission boundary set? (Possible)

Why Does This Happen?

Here’s the critical point: Service Control Policies (SCPs) do NOT apply to the management account. This is a fundamental AWS Organizations design principle. The management account is always unrestricted by SCPs.

If you’re getting denied in the management account, the issue is always IAM-based, never SCP-based:

  • The IAM user/role doesn’t have the required permissions
  • A permission boundary is restricting the role
  • The IAM policy lacks organizations:* permissions
  • The trust policy of the role prevents assumption

The Fix

Step 1: Verify You’re in the Management Account

First, confirm you’re actually in the management account:

# Check the account ID and organization status
aws sts get-caller-identity \
  --query '{AccountId:Account,UserId:UserId,Arn:Arn}' \
  --output table

# Check if this account is the management account
aws organizations describe-organization \
  --query 'Organization.MasterAccountId'

If these don’t match, you’re in a member account, not the management account. SCPs and organizational policies do apply there.

Step 2: Test as Root User

Log in as the root user of the management account and try the same action:

# If root can perform the action, the issue is IAM-based, not SCP-based
# (Root account is unrestricted by any policy)

If root succeeds but your IAM user/role fails, you’ve confirmed the issue is IAM permissions or permission boundaries, not SCPs.

Step 3: Check IAM Permissions on the Role/User

Simulate the policy to see what’s being denied:

# Simulate an action for your IAM principal
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:user/john.doe \
  --action-names organizations:CreateAccount \
               organizations:AttachPolicy \
               organizations:DescribeOrganization \
  --query 'EvaluationResults[*].{Action:EvalActionName,Result:EvalDecision,EvalResourceName}'

This shows which actions would be allowed or denied. If all show implicitDeny, the IAM policy lacks the required permissions.

Step 4: Add Required Permissions

Add organizations permissions to the user/role’s IAM policy:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "organizations:*"
      ],
      "Resource": "*"
    }
  ]
}

Attach this to the user or role:

# Attach to a user
aws iam put-user-policy \
  --user-name john.doe \
  --policy-name OrganizationsFullAccess \
  --policy-document file://orgs-policy.json

# Or attach to a role
aws iam put-role-policy \
  --role-name OrganizationsAdmin \
  --policy-name OrganizationsFullAccess \
  --policy-document file://orgs-policy.json

Step 5: Check for Permission Boundaries

If the IAM policy allows the action but you’re still denied, check for permission boundaries:

# Get the permission boundary for a user
aws iam get-user \
  --user-name john.doe \
  --query 'User.PermissionsBoundary'

# Get the permission boundary for a role
aws iam get-role \
  --role-name OrganizationsAdmin \
  --query 'Role.PermissionsBoundary'

If a permission boundary exists, it acts as a filter. Even if the IAM policy allows an action, the permission boundary must also allow it.

View the boundary policy:

# If the boundary is a managed policy, view it
aws iam get-policy \
  --policy-arn arn:aws:iam::123456789012:policy/PermissionBoundary \
  --query 'Policy'

# View the default version of the policy
aws iam get-policy-version \
  --policy-arn arn:aws:iam::123456789012:policy/PermissionBoundary \
  --version-id v1 \
  --query 'PolicyVersion.Document'

If the boundary is too restrictive, either update it or remove it from the principal.

Step 6: Generate Policy from Access Activity (Access Analyzer)

If you’re unsure what permissions are needed, use IAM Access Analyzer to generate a least-privilege policy based on access activity:

# Generate a policy based on activity
aws accessanalyzer validate-policy \
  --policy-document file://proposed-policy.json \
  --policy-type IDENTITY_POLICY

# Or use the console to review activity and generate policy
# Console: IAM → Access Analyzer → Unused access

How to Run This

  1. Run aws sts get-caller-identity to confirm your account and principal
  2. Run aws organizations describe-organization to verify the management account ID
  3. Test the failing action as root user
  4. Simulate the policy with iam simulate-principal-policy to identify missing permissions
  5. Add organizations:* (or more specific actions) to the IAM policy
  6. Check for permission boundaries and either update or remove them
  7. Retry the action

Is This Safe?

Yes. These are diagnostic commands and standard IAM permission updates. No policies are deleted or organizational structures changed.

Key Takeaway

SCPs never apply to the management account. If you’re denied in the management account, the issue is always IAM-based. Check IAM policies and permission boundaries, not SCPs. Root user always succeeds in the management account, which is a great diagnostic tool.

Have questions? Connect with me on LinkedIn or X.