AWS Security Hub Multi-Account Setup — Organizations, Delegated Admin, Finding Aggregation

Designate delegated administrator

The delegated administrator designation is a one-time setup performed from the AWS Organizations management account. The designated account (typically a dedicated security or audit account, not the management account itself) becomes the central Security Hub controller for the organization.

# Run in the Organizations MANAGEMENT account
# Step 1: Enable Security Hub as a trusted service in Organizations
aws organizations enable-aws-service-access \
  --service-principal securityhub.amazonaws.com

# Step 2: Designate your security/audit account as Security Hub admin
# Replace 111111111111 with your security account ID
aws securityhub enable-organization-admin-account \
  --admin-account-id 111111111111

# Step 3: Verify the designation (from management account)
aws securityhub list-organization-admin-accounts
# Output: {"AdminAccounts": [{"AccountId": "111111111111", "Status": "ENABLED"}]}

# ---

# Now run in the DELEGATED ADMIN account (111111111111):
# Step 4: Enable Security Hub in the admin account if not already enabled
aws securityhub enable-security-hub \
  --no-enable-default-standards

# Step 5: Configure auto-enrollment for all current and future member accounts
aws securityhub update-organization-configuration \
  --auto-enable true \
  --auto-enable-standards DEFAULT   # DEFAULT = enable CIS 1.2 in members; NONE = no auto-standards

# With NONE for auto-enable-standards, members get Hub enabled but no standards
# You can then push specific standards via update-standards-control-associations across all members
# Recommended: use NONE and manage standards centrally

aws securityhub update-organization-configuration \
  --auto-enable true \
  --auto-enable-standards NONE

The --auto-enable true flag enrolls all existing member accounts in the organization and automatically enrolls any new accounts created in the future. Without it, each account must be enrolled individually via CreateMembers and member accounts must accept the invitation. For organizations with 10+ accounts, the auto-enable path is strongly preferred — invitation-based enrollment requires action in each member account.

Member account enrollment

With --auto-enable true, existing member accounts are enrolled automatically. You can also manually enroll specific accounts and check enrollment status.

# From the DELEGATED ADMIN account:

# List all member accounts and their Security Hub status
aws securityhub list-members \
  --only-associated true \
  --query 'Members[*].{Account:AccountId,Email:Email,Status:MemberStatus,UpdatedAt:UpdatedAt}'

# MemberStatus values:
# ENABLED: Security Hub active, findings flowing to admin account
# PENDING: Invitation sent, waiting for acceptance (invitation-based only)
# ENABLED_BUT_DELETED: Member left the organization; findings no longer flowing

# Manually enroll specific accounts (for accounts not auto-enrolled)
aws securityhub create-members \
  --account-details '[
    {"AccountId": "222222222222", "Email": "prod@example.com"},
    {"AccountId": "333333333333", "Email": "staging@example.com"}
  ]'

# For invitation-based flow (non-Organizations accounts):
aws securityhub invite-members \
  --account-ids '["444444444444", "555555555555"]'
# Member accounts must then run: accept-invitation from admin account

# Disassociate a member account (stops finding sharing)
aws securityhub disassociate-members \
  --account-ids '["444444444444"]'

# Get details on a specific member
aws securityhub get-members \
  --account-ids '["222222222222"]'

Cross-account finding visibility

Once member accounts are enrolled, all their findings appear in the admin account's Security Hub. The AwsAccountId field in each finding identifies the source account. Admin accounts can filter, triage, and update findings from all member accounts.

# From ADMIN account: get HIGH+ severity findings from ALL member accounts
aws securityhub get-findings \
  --filters '{
    "SeverityLabel": [
      {"Value": "HIGH", "Comparison": "EQUALS"},
      {"Value": "CRITICAL", "Comparison": "EQUALS"}
    ],
    "WorkflowStatus": [{"Value": "NEW", "Comparison": "EQUALS"}],
    "RecordState": [{"Value": "ACTIVE", "Comparison": "EQUALS"}]
  }' \
  --sort-criteria '[{"Field": "updatedAt", "SortOrder": "desc"}]' \
  --query 'Findings[*].{Account:AwsAccountId,Severity:Severity.Label,Title:Title,Resource:Resources[0].Id}'

# Filter findings from a specific member account
aws securityhub get-findings \
  --filters '{
    "AwsAccountId": [{"Value": "222222222222", "Comparison": "EQUALS"}],
    "SeverityLabel": [{"Value": "CRITICAL", "Comparison": "EQUALS"}]
  }'

# Admin can update workflow state on ANY member account finding
aws securityhub batch-update-findings \
  --finding-identifiers '[{
    "Id": "arn:aws:securityhub:us-east-1:222222222222:subscription/aws-foundational-security-best-practices/v/1.0.0/S3.2/finding/abc123",
    "ProductArn": "arn:aws:securityhub:us-east-1::product/aws/securityhub"
  }]' \
  --workflow '{"Status": "NOTIFIED"}' \
  --note '{"Text": "Ticket created: OPS-4521. Prod account S3 bucket exposure.", "UpdatedBy": "security-ops"}'

# Member accounts can view their own findings but cannot see other members' findings
# Member accounts cannot call GetFindings for findings from other accounts
# Admin account has read+write access to all member account findings

Cross-region aggregation with multi-account

Organizations setup handles account membership (which accounts' findings flow to the admin). Cross-region aggregation handles regional coverage (which regions' findings from all those accounts flow to the home region). Both must be configured for full visibility.

# From the DELEGATED ADMIN account, in your HOME REGION:

# Create a finding aggregator — aggregates findings from linked regions
# into this home region (us-east-1 in this example)
aws securityhub create-finding-aggregator \
  --linking-mode ALL_REGIONS

# This aggregates:
# - ALL member accounts × ALL linked regions → admin account home region
# Full scope: every finding from every member in every region appears in us-east-1

# For multi-region MCP deployments, verify all relevant regions are linked:
aws securityhub get-finding-aggregator \
  --finding-aggregator-arn "arn:aws:securityhub:us-east-1:111111111111:finding-aggregator/abcd1234" \
  --query '{
    LinkingMode: FindingAggregationRegion,
    LinkedRegions: LinkedRegions
  }'

# If a new region is not linked (e.g., new ap-southeast-4 region):
aws securityhub update-finding-aggregator \
  --finding-aggregator-arn "arn:aws:securityhub:us-east-1:111111111111:finding-aggregator/abcd1234" \
  --linking-mode ALL_REGIONS

# Finding source identification in cross-account + cross-region aggregation:
# AwsAccountId: "222222222222"        → which member account
# Region field in Resources[0]: "eu-west-1"  → which region the resource is in
# ProductArn region: "eu-west-1" in the ARN  → which region the finding originated in

Enabling standards across the organization

The delegated admin can centrally enable or disable compliance standards and controls across all member accounts, replacing the need to log into each account individually.

# Enable FSBP across all member accounts in all regions from admin account
# Note: this does not enable standards in the admin account itself — run batch-enable-standards separately
aws securityhub update-organization-configuration \
  --auto-enable true \
  --auto-enable-standards NONE   # New accounts get Hub enabled but no standards

# Push specific standards to all members:
# This requires iterating over member accounts using batch-enable-standards
# or using CloudFormation StackSets for fleet-wide standards deployment

# CloudFormation StackSet approach (recommended for 10+ accounts):
# Template enables Security Hub + FSBP + CIS v1.4 in each member account
# StackSets deploys it across all accounts in the OU automatically

# Verify which standards are enabled in a specific member account:
# (run as admin account — requires Organizations delegated admin access)
aws securityhub get-enabled-standards   # Returns standards for the calling account
# To check a member account, assume-role into that account first:
aws sts assume-role \
  --role-arn "arn:aws:iam::222222222222:role/SecurityHubAuditRole" \
  --role-session-name "securityhub-audit"
# Then run get-enabled-standards with the assumed credentials

Failure modes reference