AWS Security Hub is often described as a security findings aggregator, which understates what it actually does. It is the centralised control plane for your AWS security posture: a single location where findings from GuardDuty, Amazon Inspector, Amazon Macie, IAM Access Analyzer, and dozens of third-party tools arrive in a normalised format, where compliance against security standards is continuously evaluated across your entire account estate, and from which automated response workflows can be triggered. Used correctly, it compresses the time between a misconfiguration appearing and being detected or remediated from weeks to minutes.

This guide covers how Security Hub works, how to enable and configure it across an AWS organisation, the standards and integrations that provide immediate value, and the automation patterns that turn findings into action.

How Security Hub Works

Security Hub operates on a normalised data format called the Amazon Security Finding Format (ASFF) — a JSON schema that all security findings, regardless of source, are translated into. The key fields you need to understand:

  • ProductArn — the source of the finding (GuardDuty, Inspector, Macie, IAM Access Analyzer, a custom integration, or a third-party partner product)
  • Types — finding classification using a three-part taxonomy: Namespace/Category/Classifier (e.g., Software and Configuration Checks/AWS Security Best Practices/Network Reachability)
  • Severity — normalised severity score (0–100) mapped to INFORMATIONAL, LOW, MEDIUM, HIGH, CRITICAL
  • Resources — the AWS resources the finding applies to, with ARNs and additional context
  • Compliance — when a finding is generated by a Security Hub security standard check, this field indicates the compliance status and which control triggered it
  • WorkflowStatus — the current disposition of the finding: NEW, NOTIFIED, SUPPRESSED, or RESOLVED

Understanding ASFF is important because it is the interface for all Security Hub integrations, automation, and custom finding sources.

Enabling Security Hub at Organisation Level

The correct deployment pattern is organisation-level enablement with a dedicated delegated administrator account — typically your Security Tooling or Audit account, not the management account.

Step 1: Designate a Delegated Administrator

From your AWS Organisation management account:

aws securityhub enable-organization-admin-account \
  --admin-account-id 123456789012

This designates an account as the Security Hub administrator for the organisation. All findings from member accounts flow to this account. The management account itself should not be used for security tooling — keep it clean and reserved for organisation-level administrative operations.

Step 2: Auto-Enable for New Accounts

From the delegated administrator account, configure auto-enable so new accounts joining the organisation are automatically enrolled:

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

NONE means new accounts are enrolled in Security Hub but standards are not automatically applied — you control which standards are enabled, rather than inheriting defaults that may generate noise.

Step 3: Enable Existing Member Accounts

aws securityhub create-members \
  --account-details '[{"AccountId":"111111111111"},{"AccountId":"222222222222"}]'

Alternatively, use the Security Hub console in the delegated administrator account to select and enrol all existing organisation members.

Security Standards

Security Hub evaluates your account configuration against security standards — collections of controls that map to industry frameworks. Each control runs periodically (or in near-real-time for some checks) and generates a PASS or FAIL finding for each evaluated resource.

AWS Foundational Security Best Practices (FSBP)

The most useful standard to start with. FSBP covers 300+ controls mapped to AWS-specific security practices across IAM, compute, storage, networking, logging, and encryption. Key control categories:

  • IAM: root account MFA, access key rotation, unused credentials, password policy
  • S3: public access blocking, bucket policy settings, encryption, versioning, logging
  • EC2: security group rules, IMDSv2 enforcement, EBS encryption, default VPC controls
  • CloudTrail: enabled in all regions, CloudWatch integration, log file validation
  • Config: enabled in all regions
  • KMS: key rotation enabled
  • GuardDuty: enabled across all accounts

FSBP is the right default starting point. Enable it across all accounts via the delegated administrator.

CIS AWS Foundations Benchmark

The CIS Benchmark (v1.4.0 and v3.0.0 available) covers a subset of similar controls with slightly different framing, useful if your organisation needs to demonstrate CIS alignment specifically for an audit or certification. If you are already running FSBP, the CIS Benchmark adds some controls not covered there but also generates a significant number of duplicate findings. Run both in environments where the CIS control mapping is specifically required; otherwise FSBP alone is sufficient.

PCI DSS v3.2.1

If your organisation processes payment card data and operates within AWS environments in scope for PCI DSS, the PCI DSS standard checks controls relevant to cardholder data environment (CDE) accounts. Enable it specifically in CDE accounts rather than organisation-wide.

NIST SP 800-53 Rev 5

The NIST standard is appropriate for US Federal deployments and UK central government environments aligned to NCSC guidance based on NIST controls. Higher signal-to-noise ratio than FSBP in regulated environments but more verbose.

Native Security Service Integrations

The most immediate value from Security Hub comes from enabling the native AWS security services, all of which send findings to Security Hub automatically once enabled in the same account.

Amazon GuardDuty

GuardDuty is the primary threat detection source in Security Hub. Enable it at the organisation level via the GuardDuty delegated administrator (which can be the same account as the Security Hub delegated administrator). Once enabled, GuardDuty findings appear in Security Hub automatically with their severity mapped to the ASFF scale.

Enable GuardDuty’s additional protection plans — Malware Protection for EC2 and ECS, Runtime Monitoring for EC2/ECS/EKS, and S3 Protection — all of which feed additional findings to Security Hub.

Amazon Inspector

Inspector provides continuous vulnerability scanning for EC2 instances (via SSM agent), ECR container images (on push and continuously against new CVEs), and Lambda function code. Enable Inspector at the organisation level via the Inspector delegated administrator; findings flow to Security Hub automatically and include CVE identifiers, severity scores, and affected package versions.

Inspector findings in Security Hub are particularly useful for prioritisation: a critical GuardDuty finding on an EC2 instance that also has critical Inspector vulnerability findings represents a compounded risk — active threat detection on a host with known exploitable vulnerabilities.

Amazon Macie

Macie discovers and classifies sensitive data in S3 — PII, credentials, financial data, health data — and generates findings when sensitive data is found in unexpectedly accessible locations. Macie findings appear in Security Hub as SOFTWARE_AND_CONFIGURATION_CHECKS type findings. Enable Macie at the organisation level.

IAM Access Analyzer

IAM Access Analyzer analyses resource-based policies — S3 buckets, IAM roles, KMS keys, Lambda functions, SQS queues, Secrets Manager secrets — for external access paths. Findings indicate resources accessible from outside your account or organisation. Access Analyzer sends findings to Security Hub automatically.

Finding Workflow Management

Security Hub findings accumulate quickly. Without a workflow discipline, the finding list becomes a backlog that nobody trusts or acts on. The WorkflowStatus field is the mechanism for managing this:

  • NEW — finding has arrived and not been actioned
  • NOTIFIED — finding has been sent to a ticketing system or SIEM (typically set automatically by integration)
  • SUPPRESSED — finding is acknowledged and will not be surfaced for review (used for accepted risks, exceptions, or false positives)
  • RESOLVED — the underlying issue has been fixed; Security Hub will automatically re-open the finding if the control re-evaluates to FAIL

Suppression

Suppress findings you have reviewed and accepted, not findings you want to ignore. Common legitimate suppression use cases:

  • Controls that do not apply to your environment (e.g., S3.11 — S3 event notifications — in accounts where S3 is not used)
  • Resources intentionally configured against the standard’s recommendation (e.g., a public S3 bucket for a static website, with a documented exception)
  • Test accounts where security controls are intentionally relaxed

Use Security Hub automation rules (formerly custom actions) to apply suppression at scale — for example, suppressing all findings for resources tagged Environment: Test in non-production accounts.

EventBridge Automation

Security Hub publishes finding events to Amazon EventBridge. This is the integration point for automated response: route findings to Lambda functions, Step Functions workflows, or Systems Manager Automation documents based on finding type, severity, or affected resource.

Example: Alert on Critical Findings

{
  "source": ["aws.securityhub"],
  "detail-type": ["Security Hub Findings - Imported"],
  "detail": {
    "findings": {
      "Severity": {
        "Label": ["CRITICAL"]
      },
      "WorkflowStatus": ["NEW"]
    }
  }
}

Route this rule to an SNS topic for immediate alerting to your on-call channel, and to a Lambda that creates a ticket in your ITSM platform.

Example: Auto-Remediate Specific Controls

For deterministic remediations — enabling S3 public access blocking on a non-compliant bucket, enabling CloudTrail in a region where it is disabled, revoking a security group rule that opens port 22 to 0.0.0.0/0 — implement Lambda-based remediations triggered by EventBridge rules matching those specific control IDs.

AWS Security Hub provides a library of automated remediations through the AWS Security Hub Automated Response and Remediation (SHARR) solution, available in the AWS Solutions Library. SHARR provides pre-built remediation playbooks for over 50 FSBP controls, deployable via CloudFormation.

Cross-Region Aggregation

By default, Security Hub findings are regional. If you operate in multiple AWS regions, enable cross-region aggregation in the delegated administrator account to route findings from all regions to a single aggregation region:

aws securityhub create-finding-aggregator \
  --region-linking-mode ALL_REGIONS

This allows the security team to see all findings across all regions and accounts in one place, without switching between regional Security Hub consoles. Critical for any multi-region deployment.

Third-Party SIEM Integration

Security Hub findings can be routed to third-party SIEMs and ticketing platforms through several mechanisms:

  • EventBridge → Lambda → SIEM API — a simple pattern for pushing Security Hub events to any platform with an API (Splunk, Elastic, Jira, ServiceNow, PagerDuty)
  • EventBridge → Kinesis Firehose → S3 / Splunk HEC — for high-volume finding ingestion into log analytics platforms
  • AWS Partner integrations — Splunk, Elastic, Sumo Logic, Microsoft Sentinel, and others have pre-built Security Hub integrations in the AWS Marketplace that handle the data normalisation

When integrating with a SIEM, consider which findings to forward: routing all Security Hub findings including low-severity and SUPPRESSED findings will generate significant volume. Route at minimum: NEW findings with severity HIGH or CRITICAL, and all findings from GuardDuty regardless of severity.

What Architects Should Do

  • Enable Security Hub at the organisation level immediately — even without tuning, the FSBP standard provides immediate visibility into the most common misconfigurations across your entire account estate
  • Designate a Security Tooling account as delegated administrator — keep Security Hub management out of the management account
  • Enable AWS Foundational Security Best Practices as the baseline standard — FSBP is the correct default; add CIS or NIST only if a specific audit requirement demands them
  • Enable GuardDuty, Inspector, Macie, and IAM Access Analyzer in the same delegated administrator account — these native integrations are the highest-signal sources with the lowest operational cost
  • Build EventBridge rules for CRITICAL findings on day one — delayed alerting on critical findings negates the detection value; CRITICAL findings should generate immediate notification
  • Establish a finding triage cadence — Security Hub is only useful if findings are reviewed and actioned; build a weekly triage process and measure finding age as an operational metric
  • Enable cross-region aggregation — a multi-region environment without aggregation gives a fragmented view of findings; aggregation is a one-line change with significant operational benefit

Key Takeaways

  • Security Hub is the aggregation layer, not a detection engine — it normalises findings from GuardDuty, Inspector, Macie, IAM Access Analyzer, and third parties; the detection engines must be separately enabled
  • ASFF normalisation enables consistent automation — regardless of which service generates a finding, the EventBridge event format is predictable, making automated response workflows straightforward
  • Enable at the organisation level, not account-by-account — cross-account visibility through a delegated administrator is the only way to detect patterns that span the account estate
  • Finding workflow discipline is as important as enabling the service — Security Hub without triage becomes a backlog that teams stop trusting; suppression, resolution, and triage cadence are operational requirements
  • EventBridge is the integration point for automation — route findings to Lambda remediations for deterministic fixes and to SIEM/ticketing for high-severity alerting
  • Cloud Threat Detection — Security Hub aggregates GuardDuty findings; this guide covers how GuardDuty detects threats and how to tune its coverage.
  • AWS CloudTrail Configuration Best Practices — Several FSBP controls validate CloudTrail configuration; this guide covers what correct configuration looks like.
  • AWS Compliance and Governance — Security Hub security standards map to the compliance frameworks this guide covers for UK regulated environments.
  • What is CSPM? — Security Hub’s security standards are a form of CSPM; this guide covers the broader discipline and third-party CSPM tooling that extends beyond Security Hub.
  • Cloud Security Vulnerability Management — Amazon Inspector findings in Security Hub feed directly into vulnerability management prioritisation workflows.
  • Cloud Identity and Access Management — IAM Access Analyzer findings in Security Hub surface over-permissive identity configurations; this guide covers the IAM controls those findings check.