Why AWS Delegated Administrators Are Essential for AWS Multi-Account Architectures

The management account in your AWS Organization is your most privileged asset. It controls billing, account creation, and organization-wide policies. Service Control Policies don't apply to it. If compromised, an attacker gains unrestricted access to your entire AWS infrastructure.

Yet most organizations manage GuardDuty, Security Hub, CloudTrail, and other critical services directly from the management account. This concentrates risk in the one place that should be most protected.

Delegated administrators solve this problem by moving service management to purpose-built member accounts where SCPs can restrict access, blast radius is limited, and separation of duties becomes enforceable.

This post explains what delegated administrators are, why they're essential for multi-account security, which services should be delegated, and how to implement them correctly.

What Are Delegated Administrators?

A delegated administrator is a member account in your AWS Organization designated to manage a specific AWS service across all accounts in the organization. Instead of managing services like GuardDuty, Security Hub, or CloudTrail from the management account, you register a member account as the delegated administrator for that service.

Once registered, that member account gains the permissions necessary to configure, monitor, and manage the service organization-wide. The delegated administrator can view findings from all accounts, deploy configurations across the organization, and perform administrative operations without requiring access to the management account.

This shifts service management from the management account (where SCPs don't apply and risk is concentrated) to dedicated member accounts (where SCPs can enforce least privilege and blast radius is contained).

Why Delegated Administrators Matter

Management Account Protection

The management account is the root of your AWS Organization. It controls billing, organization structure, account creation, and organization-wide policies. This makes it your most critical asset and your most valuable target for attackers.

Service Control Policies have one critical limitation: they don't apply to the management account. This creates a privileged environment where IAM policies are the only control mechanism. If a principal in the management account has broad IAM permissions, there's no organizational guardrail preventing destructive actions across your entire infrastructure.

Running security services like GuardDuty, Security Hub, and Config directly from the management account compounds this risk. A compromised management account with these services running in it gives an attacker visibility into your security tooling and the ability to disable detection across all accounts.

Delegated administrators move this risk out of the management account. Security services run from a dedicated Security account where SCPs can restrict what principals can do. If that account is compromised, the blast radius is limited to security service management, not your entire organization's billing and account structure.

Multi-Account Best Practice

Delegated administrators aren't an optional optimization you add later. They're a necessity when operating a multi-account AWS environment securely.

In a well-architected multi-account strategy, you organize accounts by function: Security accounts for security services, Infrastructure accounts for shared networking and platform services, Workload accounts for applications. This structure exists specifically to support patterns like delegated administration.

Without delegated administrators, you're forced to manage organization-wide services from the management account, which concentrates risk and violates separation of duties. With delegated administrators, you can distribute service management across purpose-built accounts aligned with team responsibilities.

This isn't theoretical. It's the practical reason AWS best practices consistently recommend dedicated Security and Log Archive accounts even for small organizations. These accounts become the delegation targets that enable secure service management at scale without compromising the management account.

Security and Operational Benefits

Separation of Duties Through Account Boundaries

Delegated administrators enable team-based access patterns that match how organizations actually operate. Your security team manages Security Hub, GuardDuty, and IAM Access Analyzer from the Security account. Your network team manages Firewall Manager from the Network account. Your platform team manages Systems Manager and CloudFormation StackSets from the Shared Services account.

Each team gets the access they need for their services without requiring credentials to the management account. This reduces credential sprawl, simplifies access reviews, and enforces separation of duties through account boundaries rather than complex IAM policies.

Blast Radius Containment

A delegated administrator for Security Hub managing security findings across your organization is powerful, but if that account is compromised, the impact is limited to Security Hub operations. The attacker can't delete accounts, change billing, or modify organization structure because those capabilities remain in the management account.

SCPs can further restrict delegated administrator accounts to only the services they're designated to manage. A Security account serving as the Security Hub delegated administrator doesn't need EC2 launch permissions, S3 bucket creation, or Lambda deployment. SCPs deny these capabilities while allowing security service operations.

Centralized Visibility Without Centralized Risk

Before delegated administrators, centralizing security monitoring meant concentrating security service management in the management account. This created a tension between visibility and risk. With delegation, you get centralized visibility (the delegated administrator sees findings from all accounts) without centralized risk (the management account remains minimal and protected).

Prerequisites for Setting Up Delegated Administrators

Before implementing delegated administrators, your AWS environment must have three foundational components in place.

AWS Organizations Must Be Enabled

Delegated administration only exists within AWS Organizations. If you're still running standalone AWS accounts, start by enabling AWS Organizations to establish the centralized management structure required for delegation.

AWS Organizations provides the foundation for multi-account management: organizational units, policy inheritance, consolidated billing, and the ability to enable services organization-wide. Without Organizations, you don't have the structure necessary to designate delegated administrators.

Dedicated Member Accounts Must Exist

Delegated administrators require dedicated member accounts to delegate to. You need at minimum:

• Security Account: For security service delegation (Security Hub, GuardDuty, Config, IAM Access Analyzer)
• Log Archive Account: For centralized logging delegation (CloudTrail)
• Network Account: For network service delegation (Firewall Manager)
• Shared Services Account: For operational service delegation (Systems Manager, CloudFormation StackSets)

Without these purpose-built accounts, you have nowhere to delegate management to. Don't use workload accounts (production, development, staging) as delegated administrators. Mixing delegated administration with application workloads complicates access control and incident response.

For guidance on designing your account structure to support delegation, see our post on AWS multi-account strategy.

Trusted Access Must Be Enabled

Each AWS service requires trusted access to be enabled at the organization level before you can designate a delegated administrator. Trusted access is the foundation that allows services to operate across all accounts in your organization.

When you enable trusted access for a service, AWS Organizations allows that service to create service-linked roles in member accounts, read your organization structure, and perform organization-scoped operations. Without trusted access enabled, services operate in isolation within individual accounts.

Trusted access is separate from delegation but necessary before delegation is possible. You must enable trusted access first, then register the delegated administrator. Attempting to register a delegated administrator without trusted access enabled will fail.

For comprehensive guidance on enabling trusted access and configuring service integrations, see AWS Organizations best practices for setting up delegated administrators correctly.

Which Services Should Be Delegated

Not every AWS service needs a delegated administrator, but security and operational services that manage resources across multiple accounts should be delegated to dedicated member accounts.

The following table maps AWS services to their recommended delegated administrator accounts and explains the business rationale for each delegation.

Key Delegation Patterns:

• Security Account receives delegation for all security, compliance, and threat detection services because the security team owns these functions and needs organization-wide visibility
• Log Archive Account receives delegation for CloudTrail because audit logs require write-only, immutable storage separate from security operations
• Network Account receives delegation for network security services because the network team owns firewall policies and network segmentation
• Shared Services Account receives delegation for operational and deployment services because the platform team manages infrastructure automation and centralized operations

Reference Architecture: Mid-Size Organization Pattern

To demonstrate how delegated administrators work in practice, here's a reference architecture based on Pattern 2 from the multi-account strategy guide. This pattern represents a mid-size organization with 50-500 employees managing approximately 10-20 AWS accounts.

Account Responsibilities:

• Management Account: Organization control plane, billing, organization-wide policies. No workloads, minimal resources, restricted access.
• Security Account: Delegated administrator for Security Hub, GuardDuty, Config, IAM Access Analyzer, Inspector, Macie, Detective, and Audit Manager. Managed by security team.
• Log Archive Account: Delegated administrator for CloudTrail. Write-only, immutable storage for audit logs with restricted access.
• Network Account: Delegated administrator for Firewall Manager. Centralized network security policy management by network team.
• Shared Services Account: Delegated administrator for Systems Manager, CloudFormation StackSets, AWS Backup, and Service Catalog. Platform automation and operations by platform team.
• Workload Accounts: Production, staging, and development application accounts. No delegated administrator responsibilities.

This structure provides clear delegation targets aligned with team responsibilities. The Security account is managed by the security team and hosts security services. The Log Archive account stores immutable audit logs. The Network account is managed by the network team for network security. The Shared Services account is managed by the platform team for operations and automation.

Each delegated administrator account manages its designated services across all workload accounts without requiring access to the management account.

Implementation Best Practices

Enable Trusted Access Before Registering Delegated Administrators

Each service requires trusted access enabled at the organization level before you can register a delegated administrator. Enable trusted access first:

aws organizations enable-aws-service-access \
    --service-principal <service-principal>

Then register the delegated administrator:

aws organizations register-delegated-administrator \
    --account-id <account-id> \
    --service-principal <service-principal>

Attempting to register a delegated administrator without trusted access enabled will fail.

Apply Restrictive SCPs to Delegated Administrator Accounts

A delegated administrator for Security Hub doesn't need EC2 launch permissions, S3 bucket creation, or Lambda function deployment. Apply SCPs that restrict delegated administrator accounts to only the services they're designated to manage:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Deny",
      "Action": [
        "ec2:RunInstances",
        "lambda:CreateFunction",
        "s3:CreateBucket"
      ],
      "Resource": "*",
      "Condition": {
        "StringNotLike": {
          "aws:PrincipalServiceName": [
            "securityhub.amazonaws.com",
            "guardduty.amazonaws.com"
          ]
        }
      }
    }
  ]
}

This prevents the Security account from being used for workload deployment while allowing security service operations.

Document Your Delegation Mapping

During incident response, you need to know immediately which account manages which service. Document your delegation mapping in runbooks and maintain it in version control:

• Service name
• Delegated administrator account ID and name
• Team responsible for managing the service
• Access procedure for the delegated administrator account

Monitor Delegated Administrator Changes

Register an EventBridge rule to alert when delegated administrators are registered or deregistered:

{
  "source": ["aws.organizations"],
  "detail-type": ["AWS API Call via CloudTrail"],
  "detail": {
    "eventName": [
      "RegisterDelegatedAdministrator",
      "DeregisterDelegatedAdministrator"
    ]
  }
}

Unauthorized changes to delegated administrators represent a potential security incident requiring immediate investigation.

Verify Delegated Administrator Configuration

After registering delegated administrators, verify the configuration:

# List all delegated administrators in your organization
aws organizations list-delegated-administrators

# View delegated administrator for a specific service
aws organizations list-delegated-administrators \
    --service-principal securityhub.amazonaws.com

# Verify trusted access is enabled
aws organizations list-aws-service-access-for-organization

Test that the delegated administrator account has the expected permissions before relying on it for operations. Assume a role in the delegated administrator account and confirm you can view resources and perform management operations across the organization.

Don't Over-Delegate

Not every service needs a delegated administrator. Services used only in the management account (like Organizations itself or Billing) shouldn't be delegated. Delegate services that need organization-wide visibility or management across member accounts.

Delegated administrators represent a fundamental shift in how you architect AWS security. Instead of concentrating security management in the management account (where SCPs don't apply and compromise has maximum impact), you distribute management to purpose-built accounts where SCPs can enforce least privilege and blast radius is contained.

This isn't an optional optimization. It's a security boundary that prevents management account compromise from immediately compromising your entire AWS infrastructure. The management account should handle only organization-level operations (account creation, policy management, billing), while dedicated Security, Log Archive, Network, and Shared Services accounts handle service management with appropriate SCPs restricting their scope.

If you're designing a new multi-account architecture or refactoring an existing one, make delegated administrators a first-class concern in your design, not an afterthought. The account structure should explicitly support delegation through dedicated accounts. The baseline configurations should register delegated administrators during account provisioning. Your access control model should assume that principals never need direct access to the management account for day-to-day operations.

This is the difference between an AWS Organizations setup and a production-ready multi-account environment. Delegated administrators are the mechanism that makes centralized security management possible without centralized security risk.