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.

• Identify the management account ID with aws organizations describe-organization and confirm it matches the account where the unexpected success occurred.
• List SCPs attached to the Root OU with aws organizations list-policies --filter SERVICE_CONTROL_POLICY and confirm the relevant deny policy is present and attached at the expected level.
• Run aws organizations list-targets-for-policy --policy-id <policy-id> and confirm the management account never appears as an SCP-enforced target, regardless of OU placement.
• 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 
  --is-organization-trail 
  --is-multi-region-trail 
  --s3-bucket-name <existing-log-bucket>

This command is state-changing. Apply it 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, since AWS Organizations permits only one organization trail per organization.

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 and confirm the management account is still, and will always be, absent from the target list; this is expected and confirms the platform boundary rather than a fault.
• 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, checking that AccountMFAEnabled equals 1 and that no root access keys are reported.
• 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.