I was managing a Control Tower environment last month when a security team tried moving an account between OUs directly from the Organizations console. The move appeared to complete, but when we checked Control Tower, the account was marked as drifted and several security controls were no longer in place. Fifteen minutes of troubleshooting revealed they’d bypassed the proper Control Tower process. In this post, I’ll walk through exactly what causes this and how to fix it.

The Problem

When you attempt to move an account from one OU to another in the Organizations console or CLI, the operation fails with a permission error, or the account gets stuck in a transitional state. You might see errors like:

Error: User: arn:aws:iam::111111111111:role/AdminRole is not authorized to perform:
organizations:MoveAccount on resource: account 222222222222
(Service: AWSOrganizations; Status Code: 400)

Or in Control Tower environments, the move succeeds in Organizations but Control Tower flags the account as drifted.

Issue Symptom
Missing IAM permission Move fails with UnauthorizedOperation
SCP blocks the move Target OU has restrictive SCP
Control Tower bypass Move succeeds but CT flags drift
Root OU restriction Account is orphaned in Root

Why Does This Happen?

  • Current user/role doesn’t have organizations:MoveAccount permission: The IAM role performing the move must have explicit permissions. Even organization admins need this specific permission granted in their role policy.

  • Target OU has an SCP that restricts the account or its tags: If the target OU has an SCP that denies actions based on account tags or principal ARN, the move can fail. For example, an SCP that only allows production workloads will block a dev account from joining.

  • In a Control Tower environment—moving via Organizations console bypasses Control Tower: Control Tower orchestrates account enrollment, applies guardrails, and tracks compliance. When you move an account directly in Organizations, Control Tower’s state machine isn’t triggered. Guardrails may be unapplied, and Control Tower marks the account as drifted.

  • Account is in Root (no parent OU) and the target OU doesn’t allow it: If your organization structure has strict OUs, moving an account from Root to a specific OU might conflict with organizational policies or access controls.

The Fix

Step 1: Verify IAM permissions

Ensure your role has the organizations:MoveAccount permission:

aws iam get-role-policy \
  --role-name AdminRole \
  --policy-name OrgManagePolicy \
  --output json | jq '.RolePolicy'

If organizations:MoveAccount is not in the policy, add it:

{
  "Effect": "Allow",
  "Action": [
    "organizations:MoveAccount",
    "organizations:ListParents",
    "organizations:DescribeAccount"
  ],
  "Resource": "*"
}

Step 2: Check for blocking SCPs

aws organizations describe-effective-policy \
  --policy-type SERVICE_CONTROL_POLICY \
  --target-id ou-xxxx-yyyyyyyy \
  --output json

Review the policy to ensure it doesn’t explicitly deny actions for the account you’re moving.

Step 3: For Control Tower environments—use Account Factory

Do NOT move accounts directly in Organizations. Instead:

  1. Log into Control Tower → Account Factory.
  2. Click Update provisioned product on the account you want to move.
  3. Change the Organizational Unit parameter to your target OU.
  4. Review and apply the changes.

This ensures Control Tower updates its state machine, re-applies guardrails, and prevents drift.

Step 4: Perform the move (if not using Control Tower)

aws organizations move-account \
  --account-id 123456789012 \
  --source-parent-id ou-source-xxxxxxxx \
  --destination-parent-id ou-dest-xxxxxxxx

Verify the move succeeded:

aws organizations list-parents \
  --child-id 123456789012 \
  --output table

Step 5: Repair Control Tower drift (if needed)

If you already moved an account directly and Control Tower flagged drift:

  1. Go to Control Tower console → Organization.
  2. Select the drifted account.
  3. Click Re-register OU or Re-enroll account.
  4. Wait for the repair operation to complete (5–15 minutes).

How to Run This

  1. Confirm your IAM role has the organizations:MoveAccount permission.
  2. Check effective policies on the target OU to ensure no SCPs block the move.
  3. For Control Tower: use Account Factory’s Update provisioned product feature—never move directly in Organizations.
  4. For non-CT organizations: use the move-account command and verify with list-parents.
  5. If drift occurred, re-register the OU or re-enroll the account in Control Tower to restore guardrails.

Is This Safe?

Yes. Moving accounts between OUs is safe if done through the proper channel (Account Factory for Control Tower, CLI/console for standalone organizations). Control Tower drift repair is also safe and typically completes within 15 minutes.

Key Takeaway

In Control Tower environments, always use Account Factory to move accounts—never bypass it with the Organizations console or CLI directly. For standalone organizations, ensure your IAM role has the organizations:MoveAccount permission and check for blocking SCPs before moving. If Control Tower drift occurs, use the re-register or re-enroll feature to repair it quickly.

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