In this blog, we’ll take a detailed look at the Security Hub CSPM features. For this purpose, I spun up a set of AWS resources and activated the free trial so you don’t have to. This post assumes you’ve already read my earlier blogs covering the new CSPM capability and its solution architecture. If you haven’t, I’d highly recommend starting there, as they help build a clear mental model of how everything fits together.

Summary page

This page is your at-a-glance view of what’s going on in Security Hub CSPM. Instead of digging through raw findings, the dashboard uses widgets to summarise your security posture and highlight the issues that matter most.

Widgets: Widgets are based on how security teams actually work and on real feedback from AWS customers. The idea is to help you spot risk quickly, not overwhelm you with noise. You can of course customise the page to suit your needs adding or removing more of the pre defined widgets that AWS makes available. At this time there is no option to make your own widgets from scratch. To customise the dashboard you can:

• Add widgets that are useful to you

• Remove ones that don’t add value

• Rearrange the layout to match how you work

Ask yourself:
What do I need to see first when I open this page?
What helps me make a decision faster?

Using filters to stay focused

At the top of the page, you can apply filters to narrow what the dashboard shows. You can save these filters as a filter set, so you don’t have to rebuild the same view every time. Just load it and carry on where you left off.

What data is actually included?

If you’ve set an aggregation Region, the dashboard shows findings from that Region and all linked Regions. If your account is a Security Hub CSPM administrator, the view goes even wider. You’ll see findings from:

• The administrator account

• All member accounts in scope

Understanding that context is critical, especially when you’re making decisions based on what the dashboard is telling you.

Controls

In AWS Security Hub CSPM, a security control, also referred to as a control, is a safeguard within a security standard such as CIS. A control relates to a specific resource or account level checks part of the standard.

When you enable a control in one or more standards, Security Hub CSPM begins running security checks on it for the in scope resources or accounts. The security checks result in Security Hub CSPM findings.

Can I disable a control?

You can enable or disable controls individually for a single account and AWS Region. To save time and reduce configuration drift in multi-account environments, AWS recommend using central configuration to enable or disable controls. With central configuration, the delegated Security Hub CSPM administrator can create policies that specify how a control should be configured across multiple accounts and Regions.

What if a control is part of multiple standards?

If you’ve turned on consolidated control findings, Security Hub CSPM generates a single finding even when a control is associated with more than one standard. For more information, see Consolidated control findings.

Severity levels

Severity levels for controls are rated from: CRITICAL, HIGH, MEDIUM, LOW

Status of controls

For administrator accounts, the Controls page reflects the status of controls across the member accounts. If a control check fails in at least one member account, the control status is Failed. If you have set an aggregation Region, the Controls page reflects the status of controls across all linked Regions. If a control check fails in at least one linked Region, the control status is Failed. Controls are evaluated periodically but the emulation can also be triggered manually.

Security score (new):

Security Hub CSPM uses the compliance status of control findings to determine an overall control status. Based on the control status, Security Hub CSPM also calculates a security score across all enabled controls and for specific standards.

The Controls page of the Security Hub CSPM console displays all of the controls available in the current AWS Region (you can view controls in the context of a standard by visiting the Security standards page and choosing an enabled standard). Security Hub CSPM assigns controls a consistent security control ID, title, and description across standards. Controls IDs include the relevant AWS service and a unique number (for example, CodeBuild.3).

AWS Config must be enabled with resource recording for scores to appear. ( See my blog on CSPM Architecture breakdown).

How its calculated?

Security scores represent the proportion of Passed controls to enabled controls. The score is displayed as a percentage rounded up or down to the nearest whole number.

Security Hub CSPM calculates a summary security score across all of your enabled standards. Security Hub CSPM also calculates a security score for each enabled standard. For purposes of score calculation, enabled controls include controls with a status of Passed, Failed, and Unknown. Controls with a status of No data are excluded from the score calculation. Security Hub CSPM ignores archived and suppressed findings when calculating control status. This can impact security scores. For example, if you suppress all failed findings for a control, its status becomes Passed, which can in turn improve your security scores.

When is the score updated & what if I have multiple regions?

After first-time score generation, Security Hub CSPM updates security scores every 24 hours. Security Hub CSPM displays a timestamp to indicate when a security score was last updated.

If you have set an aggregation Region, the overall security score reflects control findings across linked Regions.

Security standards

When you enable a standard, Security Hub CSPM automatically enables all the controls that apply to the standard. Security Hub CSPM then runs security checks on the controls, which generates Security Hub CSPM findings ( as seen in the finding tab covered below).

You can disable and later re-enable individual controls as necessary. You can also disable a standard completely. If you disable a standard, Security Hub CSPM stops running security checks on controls that apply to the standard. Findings are no longer generated for the controls.

In addition to findings, Security Hub CSPM generates a security score for each standard that you enable. The score is based on the status of the controls that apply to the standard. If you set an aggregation Region, the security score for a standard reflects the status of the controls across all linked Regions.

Supported Standards reference for Security Hub CSPM

Standards can be automatically enabled on new accounts and regions with central configuration.

Some standards such as the CIS V5 are not deployed via a conformance pack, instead they are AWS managed and deployed automatically when you enable teh standard. These are known as service linked rules.

Insights

In AWS Security Hub CSPM, an insight is a way of grouping related findings so you can spot patterns instead of looking at issues one by one. Rather than asking “what’s wrong?”, insights help you ask “where is the problem concentrated?”. For example, an insight might highlight EC2 instances that repeatedly fail security checks, pulling together findings from multiple providers into one view.

Each insight is built using two simple ideas: grouping and filters. Grouping defines what you want to list (such as resources, accounts, or Regions), while filters define which findings should be included. Security Hub CSPM gives you managed insights out of the box, which you can’t change, but you can also create custom insights tailored to your environment. On the Insights page in the console, you can filter between managed and custom insights, search by name, and focus only on what’s relevant. One important question to keep in mind: if an insight shows no results, is it because everything is secure or because the related standard or integration hasn’t been enabled yet?

Creating custom insights: When creating custom insights, you’re in control of what Security Hub CSPM shows you. By choosing the right combination of grouping and filters. To create one you can use the Security Hub CSPM console, Security Hub CSPM API or PowerShell.

Findings

In AWS Security Hub CSPM, a finding is a single recorded result of a security check or detection. It answers a basic question: did something pass, fail, or need attention?

Findings can come from CSPM controls, other AWS security services, third-party tools, or even your own custom integrations. No matter where they come from, Security Hub CSPM converts them into a common format called ASFF, so everything looks and behaves consistently. If you use cross-Region aggregation, those findings are automatically rolled up into your chosen aggregation Region.

Once a finding exists, it doesn’t stay static. Providers can update the findings they created, and you (or tools like SIEMs and SOAR platforms) can update investigation status through the console or API. To avoid long-term noise, Security Hub CSPM automatically deletes old findings: active findings expire after 90 days without updates, and archived ones after 30 days. Control findings rely mainly on the last update time, while other findings use whichever is most recent between processing and update time. If you need longer history, you’ll need to export findings to S3 using EventBridge because if a finding disappears, will you still have the evidence you need later?

IMPORTANT: Although AWS Security Hub and Security Hub CSPM use the same underlying findings platform, they do not share findings in the way many people expect. Security Hub CSPM acts as a separate finding producer, which means it creates its own findings even when an equivalent Security Hub control already exists for the same resource. As a result, closing a finding in Security Hub only updates the workflow status of that specific finding and does not automatically close or suppress a related CSPM finding. Each finding has its own ID, generator, and lifecycle, and it will only resolve automatically when the underlying configuration is fixed and the control is re-evaluated.

• Security Hub CSPM: Uses the AWS Security Finding Format (ASFF).

• Security Hub: Uses the OCSF format. While they track the same resource issues, they are technically separate “records” because the data structure is different.

Where is my single place of truth?

Security Hub is the central place where findings live, but Security Hub CSPM should be treated as the authoritative source for security posture. To avoid duplicate findings and inconsistent reporting, posture reporting should be based only on CSPM findings, with Security Hub used for triage, automation, and response.

Is the API shared between Security hub CSPM and Security Hub?

AWS Security Hub and Security Hub CSPM do not have separate APIs. CSPM findings are accessed through the same Security Hub API as all other findings, because Security Hub acts as the central findings platform. However, CSPM is a separate finding producer within that platform, so its findings are distinct objects that must be filtered explicitly (for example by ProductName or ProductArn). Using the same API does not mean the findings are shared or automatically linked it simply means they are managed through a single interface.

What is the posture management tab in security hub?

The posture management tab in security hub: The Posture management tab in Security Hub is the front-end for Security Hub CSPM. It visualises CSPM posture results and findings, but the findings themselves are still separate CSPM-generated findings stored and accessed through the Security Hub API.

I’ll be breaking down more advanced features in upcoming blogs, stay tuned!

• Automations - in depth blog coming soon

• Custom actions - in depth blog coming soon

Subscribe now

Share Coffee & Cloud ☁️ ☕️

Leave a comment

Have blog ideas, want to engage on a topic, or explore collaboration? Let’s take it offline reach out on LinkedIn. I’d love to connect and continue the conversation!

In my previous blog, I covered what the new AWS Security Hub CSPM capability provides and why it exists. In this post, we’re going a level deeper.

This blog focuses on the solution architecture behind Security Hub CSPM how data flows through AWS services, where findings come from, how they’re analysed, and how they ultimately surface as exposures in Security Hub.

The goal here isn’t to repeat documentation. It’s to give you a clear mental model of how the service works so you can make informed decisions about enablement and operational impact.

Where does security CSPM data come from?

The data you see in AWS Security Hub and Security Hub CSPM comes from two sources: AWS-native security services and third-party security tools that you choose to integrate.

Security Hub CSPM focuses on security posture. It evaluates how your AWS environment is configured and whether it aligns with security standards and best practices.

AWS native services used by Security Hub CSPM

Security Hub CSPM evaluates security posture using data from multiple AWS native services with AWS Config being the core and required data source, providing resource configuration state and change history used by most CSPM controls.

In addition, CSPM uses data from IAM, IAM Access Analyzer, AWS Organizations, and read-only AWS service APIs to evaluate account- and organisation-level controls that are not purely resource based. Together, these services allow Security Hub CSPM to assess standards. For example CIS AWS Foundations Benchmark v5.0.0 is evaluated by Security Hub CSPM using a combination of AWS Config data and other AWS service APIs, depending on whether a control is resource, account, or organisation-level.

AWS Config is therefore a prerequisite for Security Hub CSPM. Without it, a large portion of CSPM controls cannot be evaluated and will report no data or incomplete results.

AWS native detection services in Security Hub (not CSPM)

Services such as Amazon GuardDuty, Amazon Inspector, and Amazon Macie provide detections, not posture assessments.

These services identify threats, vulnerabilities, and data exposure risks. Their findings are sent to Security Hub and shown alongside CSPM results, but they are not the source of CSPM posture data.

How Security Hub brings this together

Security Hub acts as the central place where posture findings from CSPM and detections from other AWS services are normalised and correlated. Each service provides a different type of signal, and viewing them together gives security teams better context and prioritisation.

Getting data from AWS native services into Security Hub CSPM

Security Hub CSPM evaluates your security posture using data from AWS-native services (for example, configuration state, identity settings, and resource metadata).
It turns that data into controls and posture results, which are the surface in Security Hub as findings.

• If you are not using AWS Organisations, you enable Security Hub CSPM in one AWS account. That account can then invite other AWS accounts to join as member accounts. Once an invitation is accepted, the account that sent the invite becomes the administrator account, and the invited accounts become member accounts. The administrator account can manage Security Hub CSPM settings and view CSPM findings for its member accounts. An account cannot be both an administrator and a member at the same time, and each member account can only be associated with a single administrator account. This approach works for smaller setups but becomes harder to manage as the number of accounts grows.

• When using AWS Organisations, you select one account to act as the Security Hub CSPM administrator for the organisation. This administrator account manages CSPM centrally and can enable it across other organisation accounts, which automatically become member accounts. No manual invitations are required, and onboarding new accounts is much simpler. This model provides better scale, consistency, and central visibility, making it the recommended approach for most environments.

Regional setup

Security Hub CSPM operates on a regional basis, but findings can be centrally viewed using region aggregation. This allows security teams to manage posture results without switching between regions.

Region aggregation

When region aggregation is enabled, one region is designated as the home region. CSPM findings from other enabled regions are automatically sent to this home region, where they are normalised and displayed in Security Hub.

This provides a single view of security posture across regions while still allowing CSPM controls to run locally where resources exist. Even when findings are aggregated into a single home region, each finding still belongs to the original account and region where it was generated. This also means remediation workflows must run in the source account, not the administrator account.

Linked regions

Linked regions are the AWS regions that send their CSPM findings to the home region. Controls continue to be evaluated in each linked region, but the results are aggregated centrally.

This setup simplifies reporting and investigation while preserving regional evaluation and scope.

For multi-region environments, findings are evaluated in the region where the resource or setting exists and then forwarded to the designated home region using region aggregation. This provides a single, central view of posture without duplicating data collection.

How is data stored?

Security Hub findings are stored natively inside the Security Hub service.
You do not get direct access to an underlying database or log store.

You interact with the data through:

• The AWS console

• The Security Hub APIs

• The AWS CLI

• SDKs

There is no native query engine like KQL or log analytics work space where the data ends up if you are familiar with how Azure works with its security services. Security Hub CSPM data can be sent out using EventBridge and exported to services like S3, Lambda, or third-party tools.

Control lifecycle

how a control is evaluated end-to-end: Security Hub CSPM works by continuously evaluating controls rather than running one-off scans. Each control represents a specific security expectation, such as whether logging is enabled or whether a setting is configured correctly. For resource-level controls, CSPM evaluates the latest configuration state recorded by AWS Config. When a resource changes, AWS Config records the change, and CSPM re-evaluates the relevant controls.

For account- and organisation-level controls, CSPM evaluates settings using AWS service APIs, such as AWS IAM or AWS Organizations. These controls are checked periodically or when AWS detects relevant changes. Each evaluation results in a control state such as PASSED, FAILED, or NO DATA, which is then surfaced in Security Hub.

Learn about AWS config trigger types while some triggers run periodically you can also manually trigger a config rule to be re evaluated.

If you enable a standard in Security Hub CSPM but haven’t enabled AWS Config, Security Hub CSPM tries to create service-linked AWS Config rules according to the following schedule:

• On the day that you enable the standard.

• The day after you enable the standard.

• 3 days after you enable the standard.

• 7 days after you enable the standard, and continuously every 7 days thereafter.

If you use central configuration, Security Hub CSPM also tries to create service-linked AWS Config rules each time you associate a configuration policy that enables one or more standards with accounts, organisational units (OUs), or the root.

In AWS Config, you can choose between continuous recording and daily recording of changes in resource state. If you choose daily recording, AWS Config delivers resource configuration data at the end of each 24–hour period if there are changes in resource state. If there are no changes, no data is delivered. This can delay the generation of Security Hub CSPM findings for change-triggered controls until a 24–hour period is complete.

Control states

CSPM Security Hub control results are not just pass or fail. Each state tells you something important about your environment.

PASSED means the required configuration or setting is present and correctly configured.

FAILED means CSPM detected a misconfiguration or missing requirement.

NO DATA usually means CSPM could not evaluate the control. This often happens when AWS Config is not recording a required resource type, global resources are disabled, or a dependency is missing.

DISABLED means the control exists but has been intentionally turned off by an administrator.

UNKNOWN typically indicates a temporary evaluation issue or an upstream service dependency problem.

Warning: If a required resource was never recorded by AWS config, or recording was turned off before that resource existed, the control will show a WARNING. This warning doesn’t reflect the real configuration it’s just a default result because Security Hub has no data to evaluate.

Data freshness and latency

Security Hub CSPM is not real-time. There is always a delay between a configuration change and the corresponding CSPM result. For resource-based controls, the delay depends on how quickly AWS Config records the change and processes it. This can range from minutes to longer in large or busy environments.

For account-level controls evaluated via APIs, updates occur on a periodic basis rather than instantly. According to AWS Security Hub offers Near real-time risk analytics “Security Hub now calculates exposures in near real-time and includes threat correlation from GuardDuty alongside existing vulnerability and misconfiguration analysis.“

AWS Config

AWS Config rules that Security Hub CSPM uses for controls are referred to as service-linked rules. For every control that uses a service-linked AWS Config rule, Security Hub CSPM creates instances of the required rule in your AWS environment.

These service-linked rules are specific to Security Hub CSPM. Security Hub CSPM creates these service-linked rules even if other instances of the same rules already exist. The service-linked rule adds securityhub before the original rule name and a unique identifier after the rule name. For example, for the AWS Config managed rulevpc-flow-logs-enabled, the service-linked rule name might be securityhub-vpc-flow-logs-enabled-12345.

To conserve costs, AWS recommend recording global resources in only one Region.
If you use central configuration or cross-Region aggregation, this should be your home Region. By default, AWS Config records all supported Regional resources that it discovers in the AWS Region in which it is running.

By default, AWS Config records supported resources only in the Region where it’s enabled. To get all Security Hub CSPM control findings, you also need to enable recording for global resources. AWS recommends turning on AWS Config recording before enabling any Security Hub CSPM standards and controls, so all resources are fully covered from the start.

Automation

Security Hub CSPM does support automated response, but it does not perform remediation by itself.

When a CSPM control changes state (for example, from PASSED to FAILED), the resulting finding is published as an event. These events are emitted through Amazon EventBridge, where customers can define rules to trigger automation.

That automation is entirely customer-controlled. For example, a CSPM finding can trigger:

• A AWS Lambda function to remediate a setting

• A ticket in an ITSM tool

• A notification or approval workflow

• A SOAR or third-party response platform

Security Hub CSPM itself does not decide when to remediate, how to remediate, or whether remediation is safe. It only evaluates posture and emits findings.

Next see: AWS Security Hub Architecture

Subscribe now

Leave a comment

Share Coffee & Cloud ☁️ ☕️

Have blog ideas, want to engage on a topic, or explore collaboration? Let’s take it offline reach out on LinkedIn. I’d love to connect and continue the conversation!

On December 2, 2025, AWS announced the general availability of Security Hub CSPM, following its preview at AWS re:Inforce 2025. In this blog, I’ll break down what Security Hub CSPM actually is, how it differs from the original Security Hub experience, and what you should realistically expect if you enable it.

An important note

Security Hub CSPM is not a replacement for Security Hub, it extends it.

Security Hub remains the central place where security findings are aggregated, prioritised, and acted upon. Security Hub CSPM focuses on cloud security posture management — evaluating your AWS environment against security standards and best practices and identifying risky misconfigurations.

When both services are enabled:

• Security Hub CSPM generates posture and risk findings

• Those findings are automatically sent into Security Hub

• Security Hub correlates them with signals from other services (such as Amazon Inspector) to identify exposures

You can enable Security Hub CSPM on its own if your primary goal is identifying misconfigurations and measuring posture. However, if you enable Security Hub without CSPM, you miss the additional risk context and exposure analysis that CSPM provides.

For most environments, running both together provides the most value and is reccomended by AWS.

What was Security Hub before CSPM?

To understand what changed with the addition of the new CSPM capability to AWS security hub, it helps to look at what Security Hub traditionally did. Security Hub collected security findings from AWS services such as:

• Amazon GuardDuty

• Amazon Inspector

• IAM Access Analyzer

• Supported partner security tools

It brought those findings into a single view across accounts and regions, making it easier to see what was wrong and where. For security standards like CIS AWS Foundations, Security Hub relied on AWS Config to evaluate resource configurations against predefined rules and determine whether controls were met.

At its core, the original Security Hub focused on:

• Compliance visibility

• Configuration checks against standards

• Centralised aggregation of security alerts

While useful, this approach had some clear limitations.

The problems teams ran into

Alert fatigue

In the traditional Security Hub experience, teams often saw hundreds or thousands of high-severity alerts from services like Amazon GuardDuty.

Many of these alerts were technically correct but not actually risky for example, findings on resources that were not publicly reachable or could not realistically be exploited.

Security Hub CSPM reduces this noise by focusing on real risk, highlighting situations where multiple risky conditions exist together, such as:

• A vulnerable resource

• That is publicly exposed

• And has overly permissive access

Lack of context

Previously, you might see a failed configuration check for an S3 bucket or EC2 instance, but have no idea:

• Whether it was reachable from the internet

• Whether it could realistically be abused

CSPM adds context by showing how and why a misconfiguration matters not just that it exists.

Slow and manual investigation

Before CSPM, security teams often had to manually piece things together, such as:

• Which security group belongs to which EC2 instance

• How traffic flows through VPCs, gateways, and peering connections

This was time-consuming and error-prone.

Security Hub CSPM introduces attack path visualisations that clearly show where exposure comes from, such as:

• An internet gateway

• A VPC peering connection

• An overly permissive security group

Instead of guessing, teams can see the actual path an attacker could take.

What capabilities does Security Hub CSPM add?

Security Hub CSPM builds on existing security data and adds a risk-analysis layer that helps prioritise what matters most.

Attack Path Analysis

CSPM creates a visual graph showing how an attacker could realistically move through your environment. For example, it might show that an EC2 instance:

• Has a critical vulnerability (from Amazon Inspector)

• Is publicly reachable (from CSPM analysis)

• Uses an overly privileged IAM role

Together, these signals form a clear, actionable risk.

Near real-time risk analytics

Instead of relying on periodic scans, CSPM continuously updates a security score based on live signals across your environment. It uses the Open Cybersecurity Schema Framework (OCSF) to process and correlate data more consistently and quickly than the older ASFF-only approach.

Automated finding correlation

Rather than flooding teams with dozens of related alerts, CSPM groups related findings into a single Exposure. For example, if one database generates 50 individual findings, CSPM can roll those up into one high-priority issue — making it far easier to understand and act on.

Security hub CSPM third party integrations

AWS Security Hub CSPM can ingest security findings from several AWS services and supported third-party AWS Partner Network security solutions.

Pricing

When you enable Security Hub CSPM for the first time, the account is automatically enrolled in a 30-day free trial. Security Hub CSPM pricing is based on resources monitored per month, with costs pro-rated by usage time.

Example (simplified):

• 500 EC2 instances

• 500 resource units × $3.75 per unit

• Estimated monthly cost: $1,875

This is a simplified example. Actual costs vary by:

• Resource type

• Region

• Monitoring duration

• Discount tiers and ingestion usage

During the free trial, you are still charged for usage of other AWS services CSPM relies on (such as AWS Config items). However, AWS Config rules enabled solely by CSPM security standards are not charged separately.

Note: The usage information and estimated cost are only for the current account and current Region that you are in. In the case that you are using aggregation into a single hime region, the usage information and estimated cost don't include linked regions. Today you can create a cost estimate.

Security Hub CSPM Feature Breakdown

I’ll be breaking down set up and features in upcoming blogs, stay tuned!

Subscribe now

Share Coffee & Cloud ☁️ ☕️

Leave a comment

Have blog ideas, want to engage on a topic, or explore collaboration? Let’s take it offline reach out on LinkedIn. I’d love to connect and continue the conversation!