AWS Control Tower gives most new AWS estates their first governance layer, but teams often treat the default landing zone as finished security and miss the gaps: elective controls never enabled, drift left unresolved and powerful cross-account roles nobody monitors. This guide explains how Control Tower is put together (landing zone, shared accounts, controls and Account Factory), what changed with landing zone version 4.0, which roles hold organisation-wide power, how to detect drift, and how to build a controls baseline on top of the defaults. It is written for cloud platform and security engineers who run or are about to adopt Control Tower. Provider-neutral landing zone design is covered in the Cloud Landing Zone Security Guide; this page is specific to AWS Control Tower and current as of October 2026.
Key takeaways
- Control Tower orchestrates other services: it builds on AWS Organizations, AWS Service Catalog, AWS IAM Identity Center, AWS Config and CloudTrail, so its security is only as good as how those services are governed underneath it.
- Controls apply per OU: a control enabled on an organisational unit governs every account in it, including accounts created or moved there later, so OU design is security design.
- Landing zone 4.0 changed the defaults: since November 2025 service integrations are optional, a Security OU is no longer required and mandatory controls are no longer applied by default, so check what your landing zone actually enforces.
- The management account sits outside the controls: AWS states its root user and administrators can do work that controls would otherwise deny, so keep workloads and day-to-day users out of it.
- Drift is a security signal: a detached SCP, a moved account or a missing Control Tower role is either an operational mistake or an attacker weakening governance, and both need the same urgency.
How identity and access work in AWS Control Tower
A Control Tower landing zone is a multi-account environment set up to AWS's recommended baseline. AWS describes it as orchestrating Organizations, Service Catalog and IAM Identity Center. In a typical deployment it creates or adopts three shared accounts alongside the management account, places them in a foundational OU, and enrols member accounts into registered OUs where controls apply.
| Component | Purpose | Security owner's concern |
|---|---|---|
| Management account | Organisation root; runs Control Tower and pays the bills | Not bound by controls; keep it free of workloads and limit access to a few break-glass and platform identities |
| Log Archive account | Central CloudTrail and AWS Config log storage | Immutability, retention and who can read or delete logs. See the AWS CloudTrail Guide. |
| Audit account | Security team's cross-account view; aggregates drift and compliance notifications | Holds roles that can reach every enrolled account; tightly control who can deploy into it |
| Registered OUs | Groups of accounts that inherit baselines and controls | Separate production, non-production, sandbox and suspended accounts so controls can differ |
| Account Factory | Account vending through Service Catalog provisioned products | Who can create accounts, and which baseline new accounts receive |
| IAM Identity Center | Workforce access to all accounts through permission sets | Federation to your identity provider, MFA and permission set scope. See the AWS IAM Identity Center Guide. |
Landing zone version 4.0
Landing zone version 4.0, released on 17 November 2025, is a major update that introduced what AWS calls a "Controls-Only experience". The changes that matter for security are:
- Optional service integrations: AWS Config, AWS CloudTrail, Security Roles and AWS Backup integrations can each be enabled or disabled. Disabling an integration removes its resources from managed and central accounts. Disabling the Config integration also requires disabling Security Roles, IAM Identity Center and AWS Backup integrations.
- Flexible structure: a Security OU is no longer required; the only requirement is that hub accounts sit in the same OU.
- Dedicated resources: separate S3 buckets for Config and CloudTrail and separate SNS topics per service.
- Controls without the baseline: a minimal landing zone can enable controls without the
AWSControlTowerBaselinebaseline. - Mandatory controls not by default: AWS's control reference notes that from version 4.0 mandatory controls are no longer applied by default.
The flexibility is useful for organisations with an existing logging or identity design, but it also means a 4.0 landing zone can be far thinner than an older one. After any upgrade, list which integrations and controls are actually active rather than assuming the previous baseline carried over.
Admin roles and privileged access
Control Tower works through a set of IAM roles, several of which can administer every enrolled account. They are created and maintained by Control Tower, and changing or deleting them causes drift that can block the console until the landing zone is reset.
| Role | Where | Power | Protection |
|---|---|---|---|
AWSControlTowerExecution | Every member account | Used by Control Tower (and management account automation) to baseline accounts and apply controls | Restrict who can assume it from the management account; alert on trust policy changes |
aws-controltower-AdministratorExecutionRole | Every managed account | Administrator permissions; trusted only by aws-controltower-AuditAdministratorRole in the audit account | Not assumable from the console; monitor every AssumeRole |
aws-controltower-ReadOnlyExecutionRole | Every managed account | Read-only, but can read S3 objects across the organisation, broader than SecurityAudit | Treat as data access, not metadata access; monitor use |
aws-controltower-AuditAdministratorRole, aws-controltower-AuditReadOnlyRole | Audit account | Can assume the execution roles above; trust only lambda.amazonaws.com | Control who can deploy Lambda functions in the audit account |
AWSControlTowerAdmin, AWSControlTowerStackSetRole, AWSControlTowerCloudTrailRole | Management account | Run Control Tower itself, StackSets deployment and CloudTrail delivery | If missing, the console requires a landing zone reset; alert on deletion or modification |
- The audit account is a pivot point: because its Lambda-only roles can reach administrator roles in every account, anyone who can create or update Lambda functions there effectively holds organisation-wide administrator rights. Restrict deployment into the audit account to the security team's pipeline.
- Management account discipline: use it only for organisation administration, Control Tower and billing. Deny human IAM users there, protect the root user with phishing-resistant MFA, and delegate security services such as GuardDuty and Security Hub CSPM to the audit or a security tooling account. See the AWS Organizations and SCPs Guide.
- Account creation rights: provisioning through Account Factory needs
AWSServiceCatalogEndUserFullAccessplus Identity Center, Control Tower and Organizations permissions. Grant these only to the platform team or the AFT pipeline.
Integrations, API tokens and service accounts
Most changes in a mature Control Tower estate are made by automation rather than by people in the console. Those pipelines are machine identities with some of the highest privileges in the organisation.
Account Factory and Account Factory for Terraform
| Option | How it works | Choose it when | Security considerations |
|---|---|---|---|
| Account Factory (console) | Service Catalog product that creates and enrols accounts with an approved configuration | Low account volume; a small platform team | Who has Service Catalog end-user access; manual requests are harder to audit |
| Account Factory for Terraform (AFT) | GitOps pipeline in a dedicated AFT management account; an account request file and a git push trigger provisioning and customisations | Many accounts; infrastructure as code culture; repeatable customisations | The AFT management account, its pipeline roles and the source repository become organisation-critical; protect branch rules and reviewers |
| Customisations for Control Tower or your own pipeline | CloudFormation StackSets or SCPs deployed on account lifecycle events | Existing CloudFormation tooling | Same: the deploying role can change every account |
AFT supports AWS CodeCommit and other sources through AWS CodeConnections, and HCP Terraform, Terraform Enterprise and Terraform Community Edition. AWS is clear that AFT is for provisioning and customising accounts, not for deploying application resources. Since September 2026 AFT supports plan-only customisation runs (the plan_only input to the aft-invoke-customizations state machine), which lets reviewers see the Terraform plan an account would receive before anything is applied. Use it in change review.
Protecting pipeline identities
- Federate CI/CD: give pipelines short-lived role credentials through OIDC federation rather than stored access keys. See the AWS STS and AssumeRole Guide.
- Separate duties: the repository that defines account requests should require review by someone other than the author, and the role that applies them should not be usable from developer laptops.
- Scope by OU: where possible, pipeline roles that deploy workload baselines should not be able to modify the security, log archive or management accounts.
- Inventory: list every role that can assume
AWSControlTowerExecutionor the AFT execution roles, with an owner, and review it each quarter. See the Cloud PAM and CIEM Guide.
Logging and detection
Controls as preventive, detective and proactive checks
| Behaviour | What it does | Implemented with | Status values |
|---|---|---|---|
| Preventive | Stops actions that would violate policy | SCPs, RCPs and declarative policies in AWS Organizations | enforced, not enabled |
| Detective | Finds non-compliant resources and reports them on the dashboard | AWS Config rules (service-linked since June 2025, which prevents manual edits causing drift) | clear, in violation, not enabled |
| Proactive | Checks CloudFormation resources before they are provisioned; non-compliant resources are not created | CloudFormation hooks | PASS, FAIL, SKIP |
Guidance categories are separate from behaviour. Mandatory controls protect the resources Control Tower deploys. Strongly recommended controls enforce common multi-account best practice. Elective controls restrict or track actions that many enterprises limit. The Control Catalog now holds hundreds of controls, including Security Hub controls owned by the Service-Managed Standard: AWS Control Tower.
Drift
| Drift type | Example | Resolution |
|---|---|---|
| Account drift | Account moved between OUs or removed from the organisation | Move it back or re-register; enable automatic enrolment to apply the new OU's baseline |
| Policy drift | A managed SCP edited or detached; RCPs and declarative policies are also scanned daily | Restore through Control Tower, not by hand |
| OU drift | Foundational OU deleted | Landing zone reset immediately |
| Role drift | AWSControlTowerAdmin, AWSControlTowerCloudTrailRole or AWSControlTowerStackSetRole missing | Landing zone reset; other console actions are blocked until done |
| Security Hub control drift | Controls in the Control Tower service-managed standard changed | Shown on the account pages and sent by SNS |
Drift notifications from member accounts are aggregated in the audit account, for example on the aws-controltower-AggregateSecurityNotifications SNS topic. Subscribe the SOC to it. AWS notes these notifications are not available when auto-enrolment is enabled, so if you turn on automatic enrolment, add your own EventBridge rules on Organizations and Control Tower events in CloudTrail. SCP attachments to managed OUs no longer cause drift (since August 2025), which reduces noise but means your own SCP changes need their own alerting.
What else to alert on
- Organizations changes:
DetachPolicy,UpdatePolicy,MoveAccount,RemoveAccountFromOrganizationandLeaveOrganizationoutside the platform pipeline. - Role use:
AssumeRoleintoAWSControlTowerExecutionoraws-controltower-AdministratorExecutionRolefrom any principal other than the expected service or Lambda. - Logging changes: any
StopLogging,DeleteTrailor Config recorder stop in an enrolled account. - Management account activity: any sign-in or API call by a human outside a planned change.
Metrics
- Enrolment coverage: percentage of organisation accounts enrolled in registered OUs (target 100% apart from documented exceptions).
- Control coverage: number of strongly recommended and chosen elective controls enabled per OU against your target baseline.
- Drift age: median time open for drift items, split by type.
- Detective compliance: resources "in violation" per OU, trending down.
- Privileged role use: count of unexpected assumptions of Control Tower execution roles (target zero).
Hardening baseline
| Area | Baseline |
|---|---|
| OU structure | Separate OUs for security, infrastructure, production workloads, non-production, sandbox and suspended accounts |
| Preventive controls | Region deny for unused Regions; deny leaving the organisation; protect CloudTrail, Config and Control Tower roles; deny root user actions in member accounts; Block Public Access for S3 enforced |
| Detective controls | Strongly recommended set on all workload OUs: public S3 access, unencrypted storage, MFA for root, unrestricted SSH and RDP |
| Proactive controls | On OUs where CloudFormation deploys workloads, to block non-compliant resources before creation |
| Integrations (4.0) | Keep CloudTrail and Config integrations on unless an equivalent central design exists and is documented |
| Identity | Workforce access only through Identity Center permission sets; no IAM users in member accounts |
| Security services | GuardDuty, Security Hub CSPM, IAM Access Analyzer and Macie delegated to a security account. See the Amazon GuardDuty Guide. |
| Data perimeter | RCPs and SCPs that keep data and identities inside the organisation. See the AWS Resource Control Policies and Data Perimeter Guide. |
Rollout in phases
- Design OUs and accounts first: decide shared accounts, OU layout and which integrations you keep before the landing zone is created; moving accounts later causes drift.
- Set up or upgrade the landing zone: in an existing organisation, register OUs one at a time, starting with a non-production OU, and enrol existing accounts after checking that their current SCPs and Config recorders will not conflict.
- Enable detective controls before preventive ones: detective controls show what would break; run them on an OU for two to four weeks and fix violations.
- Add preventive and proactive controls OU by OU: pilot on sandbox and non-production, then production. Rollback is disabling the control on the OU, which removes the SCP or hook.
- Automate vending: move account creation to AFT or another pipeline with review and plan-only runs.
- Operate: subscribe the SOC to drift notifications, review the enabled controls page monthly and plan landing zone upgrades as changes.
Decision guidance
- Control Tower or Organizations alone: Control Tower suits teams that want AWS-managed baselines and a controls catalogue with little build effort. Teams with mature infrastructure as code and their own logging may prefer Organizations with SCPs, RCPs and Config conformance packs, or the 4.0 controls-only experience as a middle path.
- Small or large: a small organisation can run the console Account Factory with a handful of OUs. A large one needs AFT or equivalent, a dedicated platform team, and change control on every control enablement because each affects many accounts at once.
Framework mapping
| Activity | NIST CSF 2.0 | NIST SP 800-53 Rev. 5 | CIS Controls v8.1 | ISO/IEC 27001:2022 Annex A |
|---|---|---|---|---|
| Landing zone and account baseline | PR.PS-01 | CM-2, CM-6 | 4.1 | A.8.9 |
| Preventive guardrails and least privilege | PR.AA-05 | AC-3, AC-6 | 6.8 | A.8.2, A.5.15 |
| Centralised logging | PR.PS-04 | AU-2, AU-12 | 8.2, 8.9 | A.8.15 |
| Drift and compliance monitoring | DE.CM-09 | CM-3, SI-4 | 4.1 | A.8.16 |
Common misconfigurations
- Running workloads or developer access in the management account, where controls do not apply and a compromise reaches the whole organisation.
- Stopping at mandatory controls: the default set protects Control Tower's own resources, not your data; strongly recommended and elective controls are where most workload protection comes from, and from 4.0 even mandatory controls are not applied by default.
- Fixing drift by hand: re-attaching an SCP manually or editing a Config rule leaves Control Tower's state wrong; repair through Control Tower or the landing zone reset.
- Ignoring the audit account's reach: letting several teams deploy into it gives each of them a path to administrator roles in every account.
- Weak AFT repository controls: an unreviewed merge to the account request or customisation repository changes production accounts with pipeline privileges.
- Thin 4.0 landing zones by accident: disabling the CloudTrail or Config integration during an upgrade without a replacement leaves accounts with no central logging.
Practitioner checklist
- Confirm your landing zone version and list which service integrations and controls are actually enabled per OU.
- Keep the management account free of workloads and human IAM users, with root protected by phishing-resistant MFA.
- Enable the strongly recommended controls and your chosen elective controls on every workload OU, detective first.
- Restrict deployment into the audit account and monitor use of the Control Tower execution roles.
- Subscribe the SOC to the aggregated drift notifications, or build EventBridge rules if auto-enrolment is on.
- Run account vending through AFT or a reviewed pipeline using OIDC-federated, short-lived credentials and plan-only runs.
- Delegate GuardDuty, Security Hub CSPM and IAM Access Analyzer to a security account.
- Alert on Organizations policy changes, account moves and logging changes outside the platform pipeline.
- Treat landing zone upgrades as changes with a pre-upgrade inventory and a post-upgrade comparison.
Standards and references
- AWS: What is AWS Control Tower?
- AWS: Control behavior and guidance
- AWS: About controls in AWS Control Tower
- AWS: Detect and resolve drift in AWS Control Tower
- AWS: How AWS Control Tower works with roles
- AWS: Provision accounts with AWS Control Tower Account Factory for Terraform
- AWS: AWS Control Tower release notes, January 2025 to December 2025
- NIST: SP 800-53 Rev. 5
Related NHI Mgmt Group resources: Cloud Landing Zone Security Guide · AWS Organizations and SCPs Guide · AWS Multi-Account Security Reference Architecture Guide · AWS Security Guide