CSPM Explained: What It Catches, What It Misses, and What to Fix First

Most cloud breaches start with a setting somebody got wrong or never changed: a storage bucket left public, an access key nobody rotated, an admin account without multifactor authentication (MFA), a server that will hand over its credentials to anyone who can make it fetch a URL. Cloud security posture management (CSPM) tools read your cloud configuration through the provider APIs and flag those settings, continuously, across every account they are connected to.

For scale: IBM's 2026 Cost of a Data Breach report put the global average breach at $4.99 million. Verizon's 2026 Data Breach Investigations Report found exploited vulnerabilities were the way in for 31% of breaches and stolen credentials for 13%, and a third party was involved in 48%.

This guide covers what CSPM checks and what it cannot see, two breaches that were configuration failures, what the cloud providers now enforce for you, how the native tools changed in 2025 and 2026, and how to rank findings when the first scan returns thousands of them.

What CSPM checks

A CSPM tool connects to each cloud account with read-only access (an IAM role in AWS, a connector or service principal in Azure, an organization-level service account in Google Cloud) and compares resource settings against rules. It needs no agent on the servers. Typical checks include:

• Storage buckets, snapshots, and database backups that are public or shared with unknown accounts
• Security groups and firewall rules that open SSH, RDP, or database ports to the whole internet
• Audit logging (AWS CloudTrail, Azure activity logs, Google Cloud audit logs) turned off or kept too briefly
• Root and global admin accounts without MFA, IAM users with old access keys, and roles with wildcard permissions
• Encryption settings and key rotation
• Virtual machines that still accept version 1 of the AWS instance metadata service (more on that below)

Most tools map each rule to the CIS Benchmarks, the providers' own security baselines, and frameworks such as SOC 2, PCI DSS, HIPAA, and ISO 27001. That mapping is what makes CSPM useful at audit time; our SOC 2 Type 2 guide explains how auditors use that evidence.

What it does not see

• What runs inside a workload. A vulnerable package or malware on a VM or container is the job of workload scanning, often called CWPP.
• SaaS settings. Microsoft 365, Google Workspace, Salesforce, and Snowflake each have their own configuration, which SaaS security posture management (SSPM) tools cover.
• The data itself. A private bucket may still hold customer records it should not. Data security posture management (DSPM) scans the content.
• Accounts nobody connected: a sandbox, an acquired company's subscription, a project created with someone's personal login. Onboard at the organization level so new accounts enroll automatically.

Two breaches that started with configuration

Capital One, 2019. An attacker used a misconfigured web application firewall to make a server request credentials from the EC2 instance metadata service, then used those temporary credentials to copy data from S3. About 100 million people in the US and 6 million in Canada were affected. In August 2020 the OCC fined the bank $80 million, citing its failure to assess risk properly before moving significant IT operations to the public cloud.

That technique, server-side request forgery against the metadata service, is now easy to block. Version 2 of the service (IMDSv2) requires a session token that a simple forged request cannot obtain. Since March 2024 AWS has let you make IMDSv2-only the account default in each region, and instance types released since mid-2024 default to IMDSv2 only. The account setting is opt-in and does not touch existing instances, so a CSPM check for instances that still allow version 1 is still worth running.

Snowflake customers, 2024. Mandiant tracked a group it calls UNC5537 that logged in to the Snowflake accounts of about 165 organizations using passwords stolen by infostealer malware, some from infections dating back to 2020. The accounts had no MFA and no network allow lists, and Mandiant found no breach of Snowflake's own environment. A CSPM tool watching only AWS and Azure would have shown nothing wrong, because the weakness sat in a data platform's identity settings. Snowflake is now closing that gap: in the final phase of its rollout, running August to October 2026, every human user who signs in with a password must use MFA, and service users can no longer use passwords at all.

What the providers now enforce for you

The Azure change breaks scripts and pipelines that run under a person's account. Microsoft's recommended fix is to move them to workload identities (managed identities or service principals), which the requirement does not cover.

The providers still leave a lot to you: the IMDSv2 default, long-lived IAM user keys, service account keys, cross-account trust policies, public snapshots, and anything created before the new defaults. A CSPM tool should check each of these.

Native tools and third-party platforms in 2026

Each of the three large providers changed its posture tooling in the past year.

• AWS. In June 2025 AWS renamed the original Security Hub to Security Hub CSPM and launched a new Security Hub, generally available since December 2, 2025. The new service correlates Security Hub CSPM misconfigurations with Amazon Inspector vulnerabilities and GuardDuty threat findings into "exposure" findings, such as a publicly reachable EC2 instance with a highly exploitable vulnerability. It emits findings in the OCSF format, so automation written for the older ASFF format needs updating.
• Microsoft. Defender for Cloud's Foundational CSPM is free and covers Azure, AWS, and Google Cloud with Secure Score and the Microsoft cloud security benchmark. The paid Defender CSPM plan adds attack path analysis and lists at about $5 per billable resource per month (servers, databases, and storage), metered hourly. Check the pricing page for your region.
• Google. Security Command Center Standard is free and Premium is paid. The multicloud Enterprise tier is deprecated and shuts down on May 21, 2027, after which organizations move to Premium. Separately, Google closed its $32 billion acquisition of Wiz on March 11, 2026; Wiz kept its brand and continues to support AWS, Azure, and Oracle Cloud.

A company on one cloud with a small security team can usually get what it needs from the native tools and should put the savings into fixing findings. Third-party CNAPP platforms make more sense when you run two or more clouds and want one findings queue and one policy set across them.

An illustration of the budget math: 800 servers, databases, and storage accounts under Defender CSPM at about $5 each comes to roughly $4,000 a month, or $48,000 a year at list price. Third-party platforms quote on their own units, so compare vendors using your real resource counts.

CSPM, CNAPP, and the other acronyms

The case for combining them is correlation. A public VM on its own is a medium finding, and a critical vulnerability on a private VM is a routine patching ticket. A public VM with that vulnerability and an attached role that can read your customer database is the path an attacker would take, and only a tool that sees all three facts can show it to you.

Ranking findings: an illustration

The first full scan of an established cloud estate often returns thousands of findings, and working through them in severity order stalls quickly. An illustration:

• The scan reports 4,800 open findings, 610 of them rated critical or high.
• The team closes about 40 findings a week, so the critical and high findings alone would take about 15 weeks.
• Filtering for resources reachable from the internet leaves 38.
• Of those 38, six have either a vulnerability listed in CISA's Known Exploited Vulnerabilities catalog or an attached role that can read restricted data. Two have both.

Fix those two today and the rest of the 38 this week, because those are the findings an attacker can use. The remaining 572 critical and high findings go to the owning teams on a normal schedule. Verizon's 2026 DBIR found that only 26% of KEV-listed vulnerabilities were fully remediated, with a median of 43 days to fix, which is why the exploitable subset deserves its own queue.

Ask three questions of every finding:

1. Can it be reached from the internet or from an account you do not control?
2. Is it exploitable now? Examples: a KEV-listed vulnerability or one with a high EPSS score, a password-only admin login, a public access key.
3. What can it reach: sensitive data, admin permissions, production systems?

AWS exposure findings and Defender attack paths automate this correlation. Without them, an export of findings and a few filters will get you most of the way.

Stop the same findings coming back

A setting fixed in the console lasts until the next deployment overwrites it, so lasting fixes happen upstream.

• Policy checks in the pipeline. Scan Terraform, CloudFormation, Bicep, and Kubernetes manifests with a tool such as Checkov or Open Policy Agent, and fail the build when a change would create a public bucket or open an admin port.
• Organization guardrails. AWS service control policies and declarative policies (which can enforce IMDSv2 across accounts and regions), Azure Policy, and Google Cloud organization policy constraints such as storage.publicAccessPrevention and iam.disableServiceAccountKeyCreation stop a bad setting before it exists.
• Findings routed to owners. Send each finding to the team that owns the resource, with the file and line in the infrastructure code where possible. A shared chat channel full of alerts gets muted within weeks.
• Automation only for safe fixes. Re-enabling public access blocks on buckets tagged private, or turning logging back on, is low risk. Deleting security groups or disabling keys in production without asking the owner can cause an outage worse than the finding.

Separate environments

Development environments usually have weaker controls, more people with admin rights, and test code with debugging turned on. If development can reach production over the network, or shares its credentials, a breach of the weaker environment becomes a breach of the stronger one.

• Put production in its own accounts, subscriptions, or projects (grouped with AWS Organizations, Azure management groups, or Google Cloud folders), not only its own virtual network.
• Allow no network peering or transit routes from development to production.
• Give each environment its own deployment role, so a compromised development pipeline cannot deploy to production.
• Keep unmasked production customer data out of development.

With environment tags in place, a CSPM tool can flag peering connections, routes, and role trust policies that cross from a development account into a production one. If you are mid-migration, build this account structure before moving workloads; our cloud migration guide covers the cost side.

Identity and access keys

The providers are pushing customers from long-lived secrets to short-lived credentials, and the CSPM checks follow the same direction.

• Disable credentials unused for 45 days or more. That is the CIS AWS Foundations Benchmark v5.0.0 recommendation, checked in AWS as Security Hub CSPM control IAM.22. Rotate any access keys you keep at least every 90 days.
• Replace stored keys in CI/CD with workload identity federation, for example GitHub Actions signing in to an AWS role through OIDC, an Azure federated credential, or Google Cloud workload identity federation.
• Remove unused permissions. CIEM tools and AWS IAM Access Analyzer can list roles, keys, and permissions nobody has used.
• Keep a small number of break-glass accounts, protect them with hardware security keys, and alert on every use.
• Treat SaaS and data platforms such as Snowflake, Databricks, and Salesforce as part of the same identity estate: SSO enforced, no local passwords, network policies where the platform offers them.

Our zero trust guide covers identity architecture in more depth, and our SaaS security guide covers SaaS posture.

Reporting obligations

• US public companies must disclose a material cybersecurity incident on Form 8-K, Item 1.05, within four business days of determining it is material, under SEC rules adopted in 2023. Posture records showing what was exposed and for how long feed that materiality decision.
• US federal civilian agencies fall under CISA's BOD 25-01, which requires secure configuration baselines for Microsoft 365 and now Google Workspace, checked with CISA's free assessment tools such as ScubaGear. Private companies on those suites can use the same baselines as a free starting point.
• Privacy laws carry their own breach notification deadlines; see our AI and SaaS data privacy guide.
• Cyber insurance applications typically ask about MFA coverage, backups, and privileged access; see our cybersecurity insurance guide.

A 90-day plan

Days 1 to 30

• Connect every account, subscription, and project at the organization level so new ones enroll automatically.
• Turn on the free native posture tools.
• Confirm MFA on every human admin and every root or break-glass account.
• Block public storage at the account or organization level, and set the IMDSv2-only default in every AWS region you use.

Days 31 to 60

• Rank findings with the three questions above and fix everything that is both internet-reachable and exploitable.
• Disable credentials unused for 45 days and move CI/CD pipelines to federated identity.
• Map which environments can reach production and plan the split.

Days 61 to 90

• Add pipeline policy checks and organization guardrails for the rules you fixed by hand.
• Route findings to the owning teams' ticket queues.
• Report a short set of numbers monthly: accounts onboarded, internet-exposed critical findings, median days to fix them, and the share of resources with an owner tag.

For budget guardrails in the same accounts, see our cloud cost governance guide; for data classification and retention, our cloud data governance guide; for threat detection, our AI cyber threat intelligence guide.

This guide is for informational purposes only. Cloud security depends on your specific architecture, providers, and obligations; prices and product features change often. Consult qualified cybersecurity professionals and cloud architects when designing your controls.