AWS GuardDuty Multi-Account: Centralized Threat Detection Across Your Organization

When GuardDuty runs independently in each account, the threat picture is fragmented. An attacker who compromises credentials in one account, pivots to another via a cross-account role, and provisions resources in a third account generates findings in three separate GuardDuty consoles — and no single view shows the full attack chain. Multi-account GuardDuty with delegated administrator changes this: findings from every account in your organization flow to one place.

This guide covers the delegated administrator setup process, the auto-enable configuration that ensures new accounts are covered automatically, the scope of centralized visibility you get from this model, and the operational gaps that remain even with proper multi-account configuration.

The Old Model vs. Delegated Administrator

Before AWS Organizations support, GuardDuty multi-account management used a master/member invitation model. The master account sent invitations to member accounts, which had to be manually accepted. This approach worked but required coordination for every new account addition and left windows where new accounts were not covered.

The delegated administrator model eliminates the manual invitation process. Any account in an AWS Organization can be designated as the GuardDuty delegated administrator, after which it can automatically enroll all organization accounts — existing and future — without requiring manual acceptance in each member account. The invitation model still exists but should be considered legacy for Organizations users.

Setting Up the Delegated Administrator

The setup requires two API calls, both made from the Organizations management account. First, register the GuardDuty delegated administrator using guardduty:EnableOrganizationAdminAccount. Designate your dedicated security tooling account rather than the management account — keeping security tooling in a separate account from organization management reduces the blast radius if either is compromised.

After registering the delegated administrator, switch to that account and enable auto-enable for new organization members using guardduty:UpdateOrganizationConfiguration with autoEnable set to ALL (to enable in all member accounts) or NEW (to enable only in accounts added after this point). The ALL setting is the right default for most organizations — it ensures existing accounts that joined before you configured GuardDuty are retroactively covered.

The delegated administrator can also configure which protection plans are enabled organization-wide. S3 Protection, RDS Protection, and EKS Protection can all be auto-enabled for all member accounts from the delegated administrator configuration — removing the need to configure each protection plan independently in each account.

What Centralization Gives You

The delegated administrator account receives all findings from all member accounts. From this single console or API endpoint, you can query findings across hundreds of accounts simultaneously, apply suppression rules that affect all accounts, and route findings to centralized alerting systems via a single EventBridge integration.

This centralization matters most for attack detection that spans multiple accounts. GuardDuty finding data includes the account ID of the affected account, enabling you to identify multi-account attack patterns: the same source IP appearing in findings across multiple accounts, the same IAM access key used in findings across different accounts, or a sequence of findings that shows an attacker moving from a development account to a production account using a cross-account role.

Amazon Detective, when deployed in the same delegated administrator account, extends this cross-account visibility further — automatically correlating GuardDuty findings with CloudTrail events across all enrolled accounts in an interactive graph view that makes attack path reconstruction significantly faster.

Suppression Rule Scope in Multi-Account Deployments

Suppression rules created in the delegated administrator account apply only to the delegated administrator's view of findings — they do not propagate to member account consoles. Member accounts continue to see all findings in their own consoles, regardless of what the delegated administrator has suppressed. This is the correct behavior: the delegated administrator's suppression reflects operational decisions about what warrants investigation from a centralized operations perspective, not a judgment that the finding is definitively benign.

For organization-wide suppression of known-good patterns (a security scanner that runs in every account and generates consistent findings), you need to create suppression rules in each member account individually, or use an automated deployment (SSM, Lambda, or Terraform) to create consistent suppression rules across accounts.

Cross-Account EventBridge Routing

GuardDuty findings in member accounts generate EventBridge events in those member accounts. To centralize finding routing for automated response, configure EventBridge rules in each member account to forward GuardDuty finding events to a central EventBridge event bus in the delegated administrator account. This enables a single Lambda function or SNS topic in the delegated administrator account to handle findings from all organization accounts, including account ID-based routing to account-specific response workflows.

Alternatively, use AWS Security Hub's delegated administrator, which aggregates Security Hub findings (including those imported from GuardDuty) in a single account — and Security Hub's EventBridge integration covers all aggregated findings centrally.

Coverage Gaps That Remain

Even with the delegated administrator model fully configured, GuardDuty has blind spots. It does not monitor the AWS Organizations management account for actions taken through the Organizations API itself. It does not detect configuration changes made via the console without API calls (though essentially all console actions make API calls that CloudTrail records). And its behavioral models require a historical baseline — newly created accounts generate more false positives until GuardDuty establishes normal patterns, which takes approximately two weeks.

Related Reading

• Multi-account monitoring guide — unified visibility across security, billing, and compliance
• GuardDuty setup guide — initial configuration and protection plan selection
• AWS Organizations best practices — account structure and governance
• AWS security tools compared — how GuardDuty fits into the full stack

FAQ

Can I designate any account as the GuardDuty delegated administrator?

Yes, with one restriction: the management account of your AWS Organization cannot be designated as the delegated administrator through the new model (it has its own separate mechanism). Any member account can be designated. The common pattern is to use a dedicated Security Tooling account that also hosts Security Hub, AWS Config aggregator, and other centralized security services.

What happens to GuardDuty findings in member accounts when I enable delegated administrator?

Existing findings remain in member accounts. New findings are visible in both the member account and the delegated administrator account. Member accounts retain read access to their own findings. They cannot disable GuardDuty or modify organization-level settings unless explicitly granted the delegated administrator permissions.

How do I ensure all existing accounts are covered when I set up delegated administrator?

Use the auto-enable ALL setting in UpdateOrganizationConfiguration. This enables GuardDuty in all existing member accounts, not just future ones. For accounts that already had GuardDuty enabled independently, the delegated administrator model will link their existing detectors to the central account without disrupting existing findings or configuration.

Can I have different GuardDuty configurations for different OUs?

The GuardDuty delegated administrator model applies organization-wide configuration uniformly. There is no native OU-level GuardDuty configuration. For different configurations per OU, you need to manage GuardDuty at the account level using automation (Terraform, SSM) rather than the organization-level auto-enable feature.