Service Control Policies Never Restrict the AWS Organizations Management Account

Symptom

An organization-wide Service Control Policy (SCP) attached at the Root of an AWS Organization is expected to block a specific action everywhere, but a call executed from the organization’s management account succeeds even though the same call is correctly denied when attempted from any member account.

Teams typically discover this during a security review or incident: a “deny all” guardrail SCP is confirmed as attached to the Root OU, and testing from a member account shows the expected AccessDenied result. Testing the identical action from the management account, using either the root user or an IAM principal in that account, succeeds without any policy evaluation error.

False Assumption

The team assumed that an SCP attached at the Organization Root applies uniformly to every account inside the organization, including the management account that owns the organization itself.

This assumption is reasonable given how SCP inheritance is described for member OUs and accounts: policies attached higher in the hierarchy are inherited downward. Nothing in the resulting IAM permission boundary, security finding, or console SCP editor visibly flags that one account, the management account, sits outside that inheritance chain entirely.

Root Cause

AWS Organizations Service Control Policies are, by design, never evaluated against the organization’s management account. SCPs constrain the maximum available permissions for IAM users, roles and the root user in member accounts only. The management account’s principals, including its root user, are excluded from SCP enforcement regardless of where a policy is attached in the OU hierarchy, including the Root.

This is an architectural characteristic of AWS Organizations rather than a bug, a misconfiguration of a single policy, or an attachment error. No SCP wording, deny statement, or attachment target can extend enforcement to the management account, because the account sits structurally outside the scope SCPs are permitted to affect.

Impact

The operational consequence is that every preventive guardrail built through SCPs leaves the single highest-privilege account in the organization, the one capable of leaving the organization, closing member accounts, and holding root credentials for the entire billing and organizational structure, completely unconstrained by those guardrails.

Where the management account is also used to run workloads, issue access keys, or hold long-lived credentials, the organization has no SCP-based defence against misuse, compromise or accidental destructive action performed from that account, even though the security team’s control inventory may record the “deny all” SCP as an organization-wide protection.

Diagnosis

Confirm the exemption structurally, not just behaviourally, before treating it as the root cause of an observed gap. All of these checks are read-only.

• Identify the management account ID by running aws organizations describe-organization and reading the ManagementAccountId field of the returned Organization object; confirm it matches the account where the unexpected success occurred.
• List SCPs with aws organizations list-policies --filter SERVICE_CONTROL_POLICY and confirm the relevant deny policy exists.
• Run aws organizations list-targets-for-policy --policy-id <policy-id> only to see where a policy is directly attached (Root, OUs or accounts). This does not confirm enforcement: a policy attached at the Root lists the Root rather than individual accounts. Attaching an SCP directly to the management account is permitted but has no effect, because SCPs never apply to it, so appearing in this list does not mean the policy is enforced. The exemption is documented AWS behaviour, not something this command can show.
• Reproduce the denial with aws sts get-caller-identity alongside the tested action from both a member account principal and a management account principal, confirming the account context for each result.

Correction

The correction is architectural rather than a policy edit: stop relying on SCPs to govern the management account, and replace that expectation with controls that can actually reach it.

• Do not run workloads, issue long-lived access keys, or store application resources in the management account; treat it strictly as an organization-management identity, delegating operational work to member accounts.
• Apply AWS account root user protections directly in the management account: enforce MFA on the root user, remove any root access keys, and store root credentials under documented break-glass procedures.
• Delegate administration of services that support it (for example security and monitoring services) to a dedicated member account using AWS Organizations delegated administrator, reducing the number of sensitive actions that must occur in the management account.
• Enable organization-wide CloudTrail logging so that actions taken in the management account, which SCPs cannot block, are at least fully recorded for detection and audit.

aws cloudtrail create-trail --name org-management-account-trail --s3-bucket-name <bucket> --is-organization-trail --is-multi-region-trail

aws cloudtrail start-logging --name org-management-account-trail

Replace <bucket> with your log-destination bucket. These commands are state-changing and must be run from the management account (or a delegated administrator). The destination bucket must already have a CloudTrail bucket policy allowing log delivery, and create-trail does not start logging, so start-logging is required. Before running them, run aws cloudtrail describe-trails (read-only) to check for existing organization trails or overlapping logging, to avoid duplicate logging cost. Apply them only after confirming an appropriate log-destination bucket and retention policy already exist, and only where you have authority to add logging infrastructure. Stop and escalate if the organization already has a conflicting organization trail.

Validation

Validate that the corrected control set produces evidence rather than assumption, using both structural checks and behavioural reproduction.

• Re-run aws organizations list-targets-for-policy against the Root-attached SCP to confirm where the policy is attached. This shows attachment points only; the management account’s exemption from SCP enforcement is documented AWS behaviour and is not verified by this listing.
• Confirm the organization CloudTrail trail is active with aws cloudtrail get-trail-status --name org-management-account-trail and check that IsLogging returns true.
• Confirm root user protections with aws iam get-account-summary in the management account, using the management account’s credentials. The AccountMFAEnabled and AccountAccessKeysPresent keys describe the account root user only: check that AccountMFAEnabled equals 1 and that AccountAccessKeysPresent equals 0.
• Confirm delegated administration is active for any service moved out of the management account, and confirm the intended member account appears as the delegated administrator.

Rollback

Rollback applies specifically to the compensating CloudTrail change, since the underlying SCP exemption itself cannot be created, removed or reversed by configuration.

• If the new organization trail duplicates existing logging, causes unexpected storage cost, or conflicts with another monitoring process, remove it with aws cloudtrail delete-trail --name org-management-account-trail only after confirming no alerting or compliance workflow depends on that trail name.
• Before deleting, confirm retention of any log data already written to the destination S3 bucket, since deleting the trail stops future delivery but does not delete previously delivered logs.
• Do not attempt to reverse the correction by re-enabling root access keys or removing root MFA; those are safety-hardening steps, not rollback targets.

Prevention

Record the management-account SCP exemption explicitly in the organization’s control inventory so future guardrail work is not designed against a false assumption.

• When documenting any SCP as an organization-wide control, add an explicit note that the management account is out of scope, rather than leaving that gap implicit.
• Review AWS Organizations design principles referenced in the AWS Well-Architected Security Pillar when introducing new preventive guardrails, and confirm current documented behaviour for the account types involved before relying on inheritance assumptions.
• Periodically re-run the diagnosis steps above as part of a scheduled organization security review, since account structure, delegated administrators and trail configuration can drift independently of the SCP policy set.
• Treat the management account as a permanently privileged, minimally used control-plane account, and measure its hygiene rather than assuming SCP coverage protects it.

Related reading

• An AWS Principal Field Left as an Account ARN Silently Grants Every Role in That Account
• AWS Cross-Account AssumeRole Is Denied by a Mismatched Trust Policy
• AWS Identity Controls Leave Workloads Exposed Until Verified
• AWS Site-to-Site VPN Tunnel Down After BGP Flap to Azure: Fix