AWS Security Hub Best Practices

AWS Security Hub provides a comprehensive view of your security posture across AWS accounts and Regions. It aggregates, organizes, and prioritizes security findings from AWS services such as Amazon GuardDuty, Amazon Inspector, Amazon Macie, and AWS Config, as well as from third-party partner products. Security Hub evaluates your resources against security standards like the AWS Foundational Security Best Practices (FSBP) and the CIS AWS Foundations Benchmark, generating findings in the standardized AWS Security Finding Format (ASFF).

In December 2025, AWS announced a major update to Security Hub at re:Invent, delivering near real-time risk analytics, unified security operations that automatically aggregate and correlate findings across GuardDuty, Inspector, Macie, and Security Hub CSPM, and up to one year of historical trend data through a customizable Summary dashboard. These enhancements make Security Hub the central nerve center for cloud security operations -- but only if it is configured correctly.

This guide covers 12 best practices for deploying, configuring, and operationalizing Security Hub across multi-account, multi-Region environments. Whether you are enabling Security Hub for the first time or optimizing an existing deployment, these recommendations reflect the latest capabilities available in early 2026.

1. Enable Security Hub with a Delegated Administrator Account

Security Hub should be managed from a dedicated security tooling account designated as the delegated administrator -- not the management account. This follows the AWS recommended pattern of separating security operations from billing and organizational management. The delegated administrator account can view findings, manage standards, and configure policies across all member accounts.

# Step 1: Enable trusted access for Security Hub in Organizations (from management account)
aws organizations enable-aws-service-access \
  --service-principal securityhub.amazonaws.com

# Step 2: Designate the delegated administrator account
aws securityhub enable-organization-admin-account \
  --admin-account-id 111122223333

# Step 3: Verify the delegated admin is active
aws securityhub list-organization-admin-accounts

Once the delegated admin is set, enable auto-enable for new accounts so that any account added to the organization is automatically enrolled in Security Hub with your chosen configuration. Use an SCP to prevent member accounts from disabling Security Hub by denying securityhub:DisableSecurityHub.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PreventSecurityHubDisable",
      "Effect": "Deny",
      "Action": [
        "securityhub:DisableSecurityHub",
        "securityhub:DisassociateFromAdministratorAccount"
      ],
      "Resource": "*"
    }
  ]
}

2. Use Central Configuration for Multi-Account Standards Management

Central configuration, introduced in 2023 and now the recommended approach, lets you configure Security Hub standards and controls across all accounts and Regions from a single delegated administrator account. Without central configuration, you must individually enable or disable each standard in each account and Region -- an error-prone and unscalable process.

The default configuration policy enables Security Hub in all Regions for all accounts, activates the AWS Foundational Security Best Practices standard, and automatically applies the same configuration to new accounts added to the organization.

# Enable central configuration
aws securityhub update-organization-configuration \
  --organization-configuration '{
    "ConfigurationType": "CENTRAL"
  }'

# Create a configuration policy that enables FSBP and CIS v5.0
aws securityhub create-configuration-policy \
  --name "SecurityBaselinePolicy" \
  --description "Standard security baseline for all accounts" \
  --configuration-policy '{
    "SecurityHub": {
      "ServiceEnabled": true,
      "EnabledStandardIdentifiers": [
        "arn:aws:securityhub:::standards/cis-aws-foundations-benchmark/v/5.0.0",
        "arn:aws:securityhub:us-east-1::standards/aws-foundational-security-best-practices/v/1.0.0"
      ],
      "SecurityControlsConfiguration": {
        "EnabledSecurityControlIdentifiers": [],
        "SecurityControlCustomParameters": []
      }
    }
  }'

# Associate the policy with the organization root
aws securityhub start-configuration-policy-association \
  --configuration-policy-identifier "arn:aws:securityhub:us-east-1:111122223333:configuration-policy/POLICY_ID" \
  --target '{"OrganizationalUnitId": "r-abcd"}'

Best practice: Start with broad policies at the organization root level and refine with child policies for specific OUs where certain controls may not apply (for example, sandbox accounts that do not require PCI DSS compliance).

3. Enable the Right Security Standards

Security Hub supports multiple security standards. Selecting the right combination depends on your compliance requirements and operational maturity. Each standard maps to a set of automated security checks (controls) that evaluate your AWS resources.

Available Standards

• AWS Foundational Security Best Practices (FSBP) v1.0.0: AWS-curated best practices across 30+ AWS services. Recommended for all customers as the baseline.
• CIS AWS Foundations Benchmark v5.0.0: Published by CIS in March 2025; supported in Security Hub since October 2025. Includes 40 automated controls across Identity and Access Management, Storage, Logging, Monitoring, and Networking. Security Hub has CIS Security Software Certification for v5.0.0 Level 1 and Level 2.
• CIS AWS Foundations Benchmark v3.0.0: 37 automated Security Hub controls across five sections. Still widely used for compliance reporting.
• PCI DSS v3.2.1: For organizations processing payment card data.
• NIST SP 800-53 Rev. 5: For US government workloads and organizations following NIST frameworks.

# List all available standards in the current Region
aws securityhub describe-standards

# Enable CIS AWS Foundations Benchmark v5.0.0
aws securityhub batch-enable-standards \
  --standards-subscription-requests '[{
    "StandardsArn": "arn:aws:securityhub:::standards/cis-aws-foundations-benchmark/v/5.0.0"
  }]'

# List enabled standards
aws securityhub get-enabled-standards

Recommendation: At minimum, enable FSBP for all accounts. Add CIS v5.0.0 for organizations that need CIS compliance attestation. You can enable multiple versions of CIS simultaneously for transitional reporting.

4. Configure Cross-Region Aggregation

By default, Security Hub findings are regional. Without cross-region aggregation, your security team must switch between Regions to review findings -- leading to missed alerts and delayed response. Cross-region aggregation designates a home Region that receives findings from all linked Regions, providing a single pane of glass.

# Create a finding aggregator in your home Region (e.g., us-east-1)
aws securityhub create-finding-aggregator \
  --region us-east-1 \
  --region-linking-mode ALL_REGIONS

# Alternatively, link only specific Regions
aws securityhub create-finding-aggregator \
  --region us-east-1 \
  --region-linking-mode SPECIFIED_REGIONS \
  --regions us-west-2 eu-west-1 ap-southeast-1

# Verify the aggregation configuration
aws securityhub list-finding-aggregators --region us-east-1

Important: When cross-region aggregation is enabled, automation rules can only be created in the home Region, and they automatically apply to all linked Regions. Rules created in linked Regions before aggregation was enabled will no longer apply once the aggregator is active. Plan your automation rule strategy before enabling aggregation.

5. Implement Automation Rules for Finding Management

Automation rules let you automatically update or suppress findings based on criteria you define. This is essential for reducing alert fatigue, routing findings to the right teams, and enforcing consistent triage workflows. Without automation rules, security teams drown in low-priority findings and miss critical issues.

Common Automation Rule Patterns

• Suppress known false positives: Suppress findings for resources that are intentionally configured in a non-standard way (e.g., a public S3 bucket for static website hosting).
• Elevate severity: Upgrade findings for production accounts from MEDIUM to HIGH to ensure they receive immediate attention.
• Add notes and workflow status: Automatically set workflow status to NOTIFIED and add investigation notes for specific finding types.

# Create an automation rule to suppress findings for a known public bucket
aws securityhub create-automation-rule \
  --rule-name "Suppress-Public-Website-Bucket" \
  --rule-order 1 \
  --description "Suppress S3 public access findings for static website bucket" \
  --criteria '{
    "ResourceId": [{"Value": "arn:aws:s3:::my-public-website-bucket", "Comparison": "EQUALS"}],
    "Type": [{"Value": "Software and Configuration Checks", "Comparison": "PREFIX"}]
  }' \
  --actions '[{
    "Type": "FINDING_FIELDS_UPDATE",
    "FindingFieldsUpdate": {
      "Workflow": {"Status": "SUPPRESSED"},
      "Note": {
        "Text": "Intentionally public - static website hosting",
        "UpdatedBy": "SecurityHubAutomation"
      }
    }
  }]'

# Create a rule to elevate severity for production accounts
aws securityhub create-automation-rule \
  --rule-name "Elevate-Prod-Severity" \
  --rule-order 2 \
  --description "Upgrade MEDIUM findings to HIGH in production accounts" \
  --criteria '{
    "AwsAccountId": [{"Value": "444455556666", "Comparison": "EQUALS"}],
    "SeverityLabel": [{"Value": "MEDIUM", "Comparison": "EQUALS"}]
  }' \
  --actions '[{
    "Type": "FINDING_FIELDS_UPDATE",
    "FindingFieldsUpdate": {
      "Severity": {"Label": "HIGH"}
    }
  }]'

# List all automation rules
aws securityhub list-automation-rules

6. Create Custom Insights for Operational Visibility

Security Hub insights are saved filters that group findings by a specific attribute, helping you identify trends, high-risk resources, and security patterns. Security Hub provides managed (built-in) insights, but custom insights are where operational teams get real value -- tailored views of findings relevant to your organization.

# Create a custom insight: Top 10 accounts by CRITICAL findings
aws securityhub create-insight \
  --name "Critical Findings by Account" \
  --filters '{
    "SeverityLabel": [{"Value": "CRITICAL", "Comparison": "EQUALS"}],
    "WorkflowStatus": [{"Value": "NEW", "Comparison": "EQUALS"}],
    "RecordState": [{"Value": "ACTIVE", "Comparison": "EQUALS"}]
  }' \
  --group-by-attribute "AwsAccountId"

# Create a custom insight: Failed controls by standard
aws securityhub create-insight \
  --name "Failed Controls by Resource Type" \
  --filters '{
    "ComplianceStatus": [{"Value": "FAILED", "Comparison": "EQUALS"}],
    "RecordState": [{"Value": "ACTIVE", "Comparison": "EQUALS"}]
  }' \
  --group-by-attribute "ResourceType"

# List all insights (managed and custom)
aws securityhub get-insights

# Get insight results
aws securityhub get-insight-results \
  --insight-arn "arn:aws:securityhub:us-east-1:111122223333:insight/custom/INSIGHT_ID"

Operational tip: Create insights for each team or business unit. Application teams should see findings for their resources; platform teams should see infrastructure-level findings. Use insights in executive dashboards to track security posture over time.

7. Integrate GuardDuty, Inspector, Config, and Macie

Security Hub becomes most powerful when it aggregates findings from multiple AWS security services. Each service provides a different lens into your security posture, and Security Hub unifies them through the ASFF format. Without these integrations enabled, you have fragmented visibility and cannot correlate threats across services.

Key Integrations

• Amazon GuardDuty: Sends threat detection findings (malicious activity, unauthorized behavior, compromised resources) within five minutes of detection. See GuardDuty Security Card.
• Amazon Inspector: Sends vulnerability findings for EC2, Lambda, and ECR container images. Includes CVE details and CVSS scores.
• AWS Config: Required for Security Hub security checks. Config rules evaluate resource configurations, and Security Hub uses Config to run its automated compliance checks.
• Amazon Macie: Sends sensitive data discovery findings for S3 buckets containing PII, financial data, or credentials.

# Verify integrations are enabled
aws securityhub list-enabled-products-for-import

# Enable a product integration (GuardDuty example)
aws securityhub enable-import-findings-for-product \
  --product-arn "arn:aws:securityhub:us-east-1::product/aws/guardduty"

# Check that AWS Config is recording resources (required for Security Hub controls)
aws configservice describe-configuration-recorders
aws configservice describe-configuration-recorder-status

# List all available product integrations
aws securityhub describe-products

Critical dependency: AWS Config must be enabled and recording all resource types for Security Hub controls to function. If Config is not running, Security Hub controls will show a status of NOT_AVAILABLE. Use the AWS Config conformance pack for Security Hub to ensure the right Config rules are deployed. See Security Hub security card for a quick overview.

8. Configure Finding Notifications with EventBridge

Security Hub integrates natively with Amazon EventBridge to send findings to downstream targets such as SNS topics, Lambda functions, Step Functions, and ticketing systems. This enables real-time alerting and automated remediation workflows. Without EventBridge integration, findings sit in the Security Hub console waiting for someone to check.

# Create an EventBridge rule for CRITICAL and HIGH Security Hub findings
aws events put-rule \
  --name "SecurityHub-Critical-High-Findings" \
  --event-pattern '{
    "source": ["aws.securityhub"],
    "detail-type": ["Security Hub Findings - Imported"],
    "detail": {
      "findings": {
        "Severity": {
          "Label": ["CRITICAL", "HIGH"]
        },
        "Workflow": {
          "Status": ["NEW"]
        },
        "RecordState": ["ACTIVE"]
      }
    }
  }'

# Add an SNS target for email notifications
aws events put-targets \
  --rule "SecurityHub-Critical-High-Findings" \
  --targets '[{
    "Id": "SecurityHubSNS",
    "Arn": "arn:aws:sns:us-east-1:111122223333:security-alerts"
  }]'

For automated remediation, route specific finding types to Lambda functions that take corrective action -- for example, revoking an overly permissive security group rule when [EC2.19] is triggered, or enabling S3 bucket encryption when [S3.4] fails.

9. Disable Controls That Do Not Apply to Your Environment

Not every Security Hub control is relevant to every environment. Controls that generate findings for resources you do not use create noise and lower your security score. Disabling irrelevant controls improves signal-to-noise ratio and helps your team focus on findings that matter.

# Disable a specific control (e.g., Redshift controls if you do not use Redshift)
aws securityhub update-standards-control \
  --standards-control-arn "arn:aws:securityhub:us-east-1:111122223333:control/aws-foundational-security-best-practices/v/1.0.0/Redshift.1" \
  --control-status "DISABLED" \
  --disabled-reason "Redshift is not used in this account"

# List controls for a standard to review which are enabled
aws securityhub describe-standards-controls \
  --standards-subscription-arn "arn:aws:securityhub:us-east-1:111122223333:subscription/aws-foundational-security-best-practices/v/1.0.0"

# With central configuration, disable controls across all accounts at once
aws securityhub update-configuration-policy \
  --identifier "arn:aws:securityhub:us-east-1:111122223333:configuration-policy/POLICY_ID" \
  --configuration-policy '{
    "SecurityHub": {
      "ServiceEnabled": true,
      "EnabledStandardIdentifiers": [
        "arn:aws:securityhub:us-east-1::standards/aws-foundational-security-best-practices/v/1.0.0"
      ],
      "SecurityControlsConfiguration": {
        "DisabledSecurityControlIdentifiers": [
          "Redshift.1", "Redshift.2", "Redshift.3", "Redshift.4"
        ]
      }
    }
  }'

Guideline: Document why each control is disabled. Periodically review disabled controls -- as your environment evolves, previously irrelevant controls may become applicable when new services are adopted.

10. Use the ASFF Format for Custom Findings

The AWS Security Finding Format (ASFF) is a JSON schema with over 1,000 available fields that standardizes how findings are represented in Security Hub. All AWS service integrations and third-party partners use ASFF. You can also send custom findings from your own security tools, CI/CD pipelines, or compliance scanners using the BatchImportFindings API.

# Import a custom finding into Security Hub
aws securityhub batch-import-findings \
  --findings '[{
    "SchemaVersion": "2018-10-08",
    "Id": "custom-finding-001",
    "ProductArn": "arn:aws:securityhub:us-east-1:111122223333:product/111122223333/default",
    "GeneratorId": "custom-security-scanner",
    "AwsAccountId": "111122223333",
    "Types": ["Software and Configuration Checks/Industry and Regulatory Standards"],
    "CreatedAt": "2026-02-01T00:00:00Z",
    "UpdatedAt": "2026-02-01T00:00:00Z",
    "Severity": {"Label": "HIGH"},
    "Title": "Custom compliance check failed",
    "Description": "Resource does not meet internal security baseline requirement XYZ-42",
    "Resources": [{
      "Type": "AwsEc2Instance",
      "Id": "arn:aws:ec2:us-east-1:111122223333:instance/i-0abc123def456",
      "Region": "us-east-1"
    }]
  }]'

# Verify the finding was imported
aws securityhub get-findings \
  --filters '{
    "GeneratorId": [{"Value": "custom-security-scanner", "Comparison": "EQUALS"}]
  }'

Custom findings are particularly useful for integrating third-party vulnerability scanners, internal compliance tools, and CI/CD security gates into your centralized security view. They appear alongside AWS-native findings, can trigger automation rules, and are included in insights.

11. Monitor and Improve Your Security Score

Security Hub calculates a security score for each enabled standard as a percentage of passed controls versus total enabled controls. This score provides a high-level metric for tracking security posture improvement over time. A declining score indicates new resources being deployed without proper security configurations or controls falling out of compliance.

# List findings grouped by compliance status
aws securityhub get-findings \
  --filters '{
    "ComplianceStatus": [{"Value": "FAILED", "Comparison": "EQUALS"}],
    "RecordState": [{"Value": "ACTIVE", "Comparison": "EQUALS"}],
    "WorkflowStatus": [{"Value": "NEW", "Comparison": "EQUALS"}]
  }' \
  --sort-criteria '{"Field": "SeverityLabel", "SortOrder": "desc"}' \
  --max-items 20

# Count findings by severity
aws securityhub get-findings \
  --filters '{
    "SeverityLabel": [{"Value": "CRITICAL", "Comparison": "EQUALS"}],
    "ComplianceStatus": [{"Value": "FAILED", "Comparison": "EQUALS"}],
    "RecordState": [{"Value": "ACTIVE", "Comparison": "EQUALS"}]
  }' \
  --query "Findings | length(@)"

Operational cadence: Review your security score weekly. Prioritize CRITICAL and HIGH severity failed controls first. Use the Security Hub Summary dashboard (with up to one year of historical trend data) to identify trends and demonstrate progress to leadership. Set targets -- for example, maintain a score of 90% or higher across all standards.

12. Export Findings to a SIEM or Security Data Lake

For organizations with mature security operations, exporting Security Hub findings to a SIEM (such as Splunk, Datadog, or an Elastic-based SIEM) or to Amazon Security Lake provides long-term retention, cross-platform correlation, and advanced analytics capabilities that go beyond what Security Hub natively offers.

# Export findings to S3 via EventBridge and Firehose
# Step 1: Create a Firehose delivery stream targeting S3
aws firehose create-delivery-stream \
  --delivery-stream-name "securityhub-findings-export" \
  --s3-destination-configuration '{
    "RoleARN": "arn:aws:iam::111122223333:role/FirehoseSecurityHubRole",
    "BucketARN": "arn:aws:s3:::security-findings-archive",
    "Prefix": "securityhub/year=!{timestamp:yyyy}/month=!{timestamp:MM}/day=!{timestamp:dd}/",
    "BufferingHints": {"SizeInMBs": 64, "IntervalInSeconds": 300}
  }'

# Step 2: Create an EventBridge rule targeting the Firehose stream
aws events put-rule \
  --name "SecurityHub-All-Findings-Export" \
  --event-pattern '{
    "source": ["aws.securityhub"],
    "detail-type": ["Security Hub Findings - Imported"]
  }'

aws events put-targets \
  --rule "SecurityHub-All-Findings-Export" \
  --targets '[{
    "Id": "FirehoseExport",
    "Arn": "arn:aws:firehose:us-east-1:111122223333:deliverystream/securityhub-findings-export",
    "RoleArn": "arn:aws:iam::111122223333:role/EventBridgeFirehoseRole"
  }]'

For native AWS integration, consider Amazon Security Lake, which automatically normalizes Security Hub findings into the Open Cybersecurity Schema Framework (OCSF) format and stores them in S3 with Apache Iceberg tables for efficient querying via Amazon Athena.

Common Misconfigurations

The following misconfigurations frequently undermine Security Hub deployments and lead to incomplete visibility or operational overhead:

• AWS Config not enabled: Security Hub controls depend on AWS Config for resource evaluation. If Config is not enabled or is not recording all resource types, controls show NOT_AVAILABLE status and your security score is inaccurate. Always verify Config is active before enabling Security Hub standards.
• Security Hub not enabled in all Regions: Attackers target Regions where monitoring is absent. Use central configuration with ALL_REGIONS to ensure coverage, including Regions you do not actively use for workloads.
• No cross-region aggregation: Without a finding aggregator, security teams must check each Region individually. Critical findings in non-primary Regions go unnoticed for days or weeks.
• All controls left enabled by default: Enabling every control without reviewing relevance creates hundreds of findings for unused services (Redshift, DocumentDB, Neptune), inflates noise, and lowers your security score artificially. Disable controls for services you do not use.
• No automation rules for known exceptions: Failing to suppress findings for intentional configurations (public website buckets, development account exceptions) means the security team wastes time triaging the same false positives repeatedly.
• No EventBridge integration: Findings that sit in the Security Hub console without notifications are findings that nobody acts on. Always configure EventBridge rules for CRITICAL and HIGH severity findings at minimum.
• Member accounts can disable Security Hub: Without an SCP preventing securityhub:DisableSecurityHub, individual account owners can turn off Security Hub, creating blind spots in your posture management.
• Stale findings not archived: Findings for resources that have been deleted remain active in Security Hub. Use automation rules or scheduled Lambda functions to archive findings for resources that no longer exist.

Quick Reference Checklist

Best Practice	Priority	Effort	Key Controls
Enable Security Hub with delegated admin	Critical	Low	Delegated admin
Use central configuration	Critical	Medium	Organization-wide
Enable FSBP and CIS v5.0 standards	Critical	Low	CIS 1.x-5.x, FSBP all
Configure cross-region aggregation	High	Low	Finding aggregator
Implement automation rules	High	Medium	Suppression, severity
Create custom insights	Medium	Low	Per-team visibility
Integrate GuardDuty, Inspector, Config, Macie	Critical	Low	All service findings
Configure EventBridge notifications	High	Medium	CRITICAL/HIGH alerts
Disable irrelevant controls	Medium	Medium	Unused service controls
Use ASFF for custom findings	Medium	Medium	BatchImportFindings
Monitor and improve security score	High	Ongoing	Weekly review cadence
Export findings to SIEM / Security Lake	Medium	High	Long-term retention

For a quick overview of Security Hub capabilities, finding types, and key configuration settings, see the Security Hub security card. For related AWS security services, review our guides on GuardDuty, IAM, and CloudTrail best practices.