The cloud security posture management (CSPM) tool I run has never detected an attack. In twelve months of history, every alert I sampled traced back to an engineer's misconfiguration, with no attacker activity in sight. The findings queue ran thousands deep and the compliance dashboards stayed green, but none of that was detection in the sense the vendor's deck kept promising.
The deck used the word detection on nearly every slide, and the product had never done the thing that word describes. It had inventoried the conditions that make attacks easier, which is real and useful work, but credential abuse and runtime activity sit outside that job entirely. I keep paying for the tool anyway, and I would again, because posture is worth buying. The mistake is counting it as detection.
The question that actually decides your cloud detection budget is whether a vendor's claims rest on inventory or on attack telemetry. Separating configuration hygiene from attack detection is what tells you where your posture spend ends and your detection spend has to begin, and it is the difference between what a tool inventories and what it can actually catch.
In brief:
- CSPM earns its budget by handling misconfiguration, drift, identity and access management (IAM) exposure, and compliance evidence across large account estates.
- CSPM reads configuration state, so an attacker using valid stolen credentials against a correctly configured resource leaves the configuration unchanged. Capital One and the Snowflake campaign both read clean during exfiltration.
- Google Cloud's own incident data attributes 47.1% of cloud intrusions to weak or absent credentials versus 29.4% to misconfigurations. Posture tooling instruments the smaller share.
- The 2026 buyer question is which layer you staff and which you buy. Finding ownership cannot be purchased, and around-the-clock runtime detection is hard to staff when security budgets are barely growing.
What CSPM was built to catch, and still does well
CSPM continuously scans cloud accounts and configurations, compares them against baselines like the Center for Internet Security (CIS) and National Institute of Standards and Technology (NIST) frameworks, and flags deviations. It reads those configurations through cloud provider application programming interfaces (APIs) and nothing else, and everything it covers follows from that choice. The coverage that has earned its keep in my environments breaks down like this:
- Storage exposure: public Amazon Simple Storage Service (S3) buckets and Azure Blob containers, plus publicly shared Amazon Elastic Compute Cloud (EC2) snapshots
- IAM exposure: overly permissive roles, unused credentials, missing multi-factor authentication (MFA) on privileged accounts
- Network exposure: security groups open to 0.0.0.0/0
- Logging and encryption gaps: disabled CloudTrail, unencrypted data at rest
A CSPM tool maps accounts and resources far faster than a small team can do by hand, and public S3 bucket exposure has kept trending down across the industry as this kind of scanning became table stakes. CSPM earns its budget when it does the hygiene job it was built to do.
Where the posture model stops working
None of the failure modes below is a bug a vendor can patch. Each one follows from the architecture that makes CSPM good at hygiene: it reads configuration state and only configuration state.
The model only sees the configuration state
Posture tools evaluate configuration at scan time or against current API state, so threats that originate in application code or runtime behavior stay invisible unless that behavior changes a cloud resource configuration. The tool monitors control-plane settings and IAM policies, while operating systems, containers, and application behavior live at runtime, beyond the reach of a configuration scan.
Cadence compounds the problem because if posture scans run every six hours and an attacker compromises credentials at 3 pm, they have until 9 pm to exfiltrate data and cover their tracks before the next scan fires. Event-driven scanning narrows that window for any activity that changes a configuration, but attacker activity that changes nothing never triggers a scan at all.
A correctly configured resource under stolen credentials reads clean
In the Capital One breach, the attacker used a server-side request forgery (SSRF) flaw to pull IAM credentials from the EC2 metadata service, then reached data in S3 and exposed 106 million records. Every API call was authorized exactly as the IAM policy intended, so a scan run mid-exfiltration would have shown the environment as configured. The Snowflake campaign repeated the pattern: UNC5537 logged in with stolen credentials and exported data with ordinary SQL.
Credential abuse now accounts for a larger share of cloud incidents than misconfiguration does. Google Cloud's own incident data attributes 47.1% of cloud intrusions to weak or absent credentials versus 29.4% to misconfigurations, and CrowdStrike puts valid account abuse at 35% of cloud intrusions in the same period. Your posture tool instruments the smaller and shrinking share of how cloud environments get breached.
Finding volume without ownership becomes a backlog
A large security team can see dozens of new cloud misconfigurations a day, and the remediation math works against you, because IAM misconfigurations routinely age for months and critical alerts stay open far longer than anyone admits. Detection is not the hard part once a tool is running, since teams already have plenty of findings. The hard part comes after, when someone has to work out who owns the asset, whether an exception exists, and whether the fix landed.
The pattern shows up the same way in every environment I've run.When I pulled the aged findings during renewal prep, the oldest ones sat with application teams who had no permission to fix them, because the issue was an org-level configuration only the platform team could touch. Application teams own findings on resources they build, and the cloud team owns the wide-reaching ones they usually cannot change. A finding routed to a team that cannot act on it becomes backlog, not risk reduction.
Posture management needs runtime detection once attackers use valid credentials
Posture reports configuration state, while detection reports active attack behavior as it happens, and deciding where posture hands off to detection is what sets your architecture and your budget.
Runtime and detection pick up where CSPM ends
The line is easy to draw: if an attacker logs into AWS with a phished credential and starts cryptomining at 2 am, posture scanning has no telemetry for it, while cloud detection and response (CDR) catches it by watching CloudTrail activity against behavioral baselines. The telemetry that covers CSPM's blind spot lives in control-plane logs and virtual private cloud (VPC) Flow Logs, plus extended Berkeley Packet Filter (eBPF) sensors in running workloads.
Runtime-only coverage creates its own gaps because attack paths start well before runtime, so each layer covers a distinct phase of the attack chain. I have written separately about how much cloud-native security is rebadged hygiene. Posture and detection are complements, and vendors blur the line because posture is the easier of the two to build.
Where CSPM earns its seat in a stack, you actually staff
Budget growth has slowed while both CSPM and cloud managed detection and response (MDR) still consume real money, and extending managed detection into cloud workloads and identity, including software as a service (SaaS), costs materially more than endpoint-only coverage. Meanwhile, security budgets are growing only slightly, and few leaders say their teams are staffed for it. That leaves a tooling budget without matching headcount.
When I write these checks, I staff the work that requires our context and buy the work that requires around-the-clock coverage. Finding ownership, remediation routing, and exception handling are context work because no vendor knows which of your teams owns which account. Runtime detection at 3 am is coverage work, and nobody is hiring a follow-the-sun bench on today's budgets, so that layer gets bought as CDR or MDR coverage.
Three questions that show whether your CSPM detects or just inventories
The first vendor that fooled me on this had a polished demo with a Detections tab full of red counters, and when I asked what was inside, it was all misconfigurations. I almost signed the renewal anyway because the rest of the deck was strong, and since then, I open every CSPM and cloud-native application protection platform (CNAPP) evaluation with the same three questions.
- When an attacker uses valid credentials for legitimate API calls in an otherwise clean environment, what does your platform alert on, and from what telemetry source? A real answer names control-plane log analysis and behavioral baselines, and probably points at a separate CDR module, because missing MFA is an inventory finding while real active attack detection starts with attack telemetry.
- Is re-assessment triggered by configuration change events or by scheduled scans, and how long is the window? If scans run every six hours, ask what happens to a credential compromised ten minutes after the last one, because vendors with an event-driven architecture will explain it in detail and vendors without it will change the subject.
- If you claim MITRE ATT&CK coverage, show me the technique-level mapping and its scope. Ask whether the number includes the cloud and SaaS matrices or just endpoints, and demand technique-level IDs, because a marketing percentage means nothing without them.
A good vendor answers the first question by naming its own boundary, and I listen for whether they know where their product stops. I renewed my CSPM because it does the posture job better than my team could with scripts and quarterly audits, and then I deleted the word detection from every internal slide that mentioned it. Renew the tool, keep it honest about its job, and put your detection budget where the telemetry actually lives.
Frequently asked questions about CSPM
CSPM buying and operating decisions come down to telemetry and the staff available to act on findings. It remains a useful posture tooling, and it still needs runtime detection beside it.
How does CSPM work in cloud security?
Cloud security posture management continuously reads cloud resource configurations through provider APIs and compares them against policy baselines and frameworks such as CIS, PCI DSS, HIPAA, and NIST. It flags misconfigurations, drift, IAM exposure, and compliance gaps across many accounts at a scale manual review cannot match. Because it reads configuration state only, runtime identity and workload behavior sit outside its view.
What is the difference between CSPM and CNAPP?
CNAPP is a unified platform that consolidates previously siloed capabilities. CSPM, Kubernetes security posture management (KSPM), cloud infrastructure entitlement management (CIEM), and cloud workload protection are core functions, with cloud detection and response (CDR) and data security posture management (DSPM) as adjacent capabilities you evaluate separately. Most CSPM buying now runs through CNAPP, and CDR depth varies, so check it explicitly.
Does CSPM detect active attacks?
CSPM flags conditions that make attacks easier, like missing MFA or public storage, but it does not detect the attacks themselves. An attacker using valid credentials against a correctly configured resource leaves the configuration state unchanged and gives a posture scan no event to flag. Active attack detection needs control-plane log analysis, behavioral baselines, and runtime telemetry, which is the job of CDR and runtime sensors.
Is CSPM still worth it in 2026?
Yes, for the posture job. CSPM continues to grow, mostly bundled inside CNAPP platforms, though smaller teams with simple estates can still get practical value from CSPM plus a security information and event management (SIEM) tool without a full CNAPP. It stops being worth the money the moment anyone counts it as detection coverage.