In June 2024, attackers calling themselves UNC5537 logged into roughly 165 Snowflake customer tenants using credentials harvested from infostealer malware — some of it dating back to 2020. The Snowflake platform itself was not breached. What got breached was customer-side configuration: tenants where MFA was optional, where SSO wasn’t mandatory, where dormant demo accounts still had production access. AT&T lost 109 million call records. Ticketmaster and Santander followed. The common thread was not a CVE. It was posture.
That distinction is what SaaS Security Posture Management — SSPM — exists to address. Gartner defines it as a tool that continuously assesses the security risk and manages the security posture of SaaS applications. In practice, SSPM platforms connect to SaaS tenants over API, pull configuration and identity data, compare it to a baseline, and surface drift. That sounds simple. The interesting questions are which configurations matter, which baselines to compare against, what SSPM doesn’t catch, and where it overlaps with CSPM, CASB, ITDR, and DSPM in ways that confuse buyers and leave gaps. This piece walks through what SSPM actually does, where it sits in the security stack, and the meaningful limits buyers tend to discover after rollout.
What SSPM Actually Monitors
The category formed around a specific gap. CASBs (cloud access security brokers) sat between users and SaaS apps to enforce policy on traffic. CSPM (cloud security posture management) covered IaaS and PaaS — AWS account configurations, Azure resource groups, GCP IAM. Neither looked inside the SaaS tenant itself, where the actual settings lived. Whether Salesforce had IP restrictions enabled, whether Microsoft 365 allowed legacy authentication, whether a dormant Slack workspace admin still had a valid session — those were invisible to anything outside the app’s own admin console.
SSPM platforms address that by talking directly to the SaaS application’s API. Microsoft Graph API, Salesforce REST API, Okta API, the Google Workspace Admin SDK, Slack’s audit and SCIM endpoints — the tool authenticates with read scopes (sometimes write, for remediation), pulls configuration state on a schedule, and evaluates it against rules. The data SSPM collects typically falls into five buckets:
Configuration state. The tenant’s own settings — MFA enforcement, session timeouts, allowed IP ranges, sharing defaults, external collaboration policies, password complexity, audit logging. This is the most concrete part of “posture” and the easiest to map to compliance frameworks.
Identities and entitlements. Who exists in the tenant, what roles they hold, which accounts are dormant, which have admin privileges, which lack MFA. Modern SSPMs extend this to non-human identities (NHIs) — service accounts, API keys, OAuth-connected apps — which are now where most SaaS attacks land.
Third-party integrations. OAuth-connected apps a user installed by clicking “Allow,” browser extensions, marketplace add-ons. Each one holds a token with some scope into the tenant. A 2024 attacker who pivoted from Cloudflare’s compromised Atlassian instance into source code repositories did so through OAuth tokens left from a prior breach.
Sharing and exposure. Files shared publicly, calendars set to “anyone with the link,” Salesforce reports exposed externally, Confluence pages set to “anyone on the internet.” Not strictly configuration, but a posture question: what’s reachable, by whom.
Activity baselines for drift detection. Less universal across vendors, but increasingly standard: noticing when posture changes — a security setting flipped off, an admin role granted, a previously restricted app suddenly listed in OAuth grants.
The output is some combination of a posture score, a prioritized findings list, mapping to compliance frameworks (SOC 2, ISO 27001, NIST CSF 2.0, HIPAA, PCI-DSS), and — depending on the vendor — guided or automated remediation.
How SSPM Sits Next to CSPM, CASB, DSPM, and ITDR
The acronym pile is partly a marketing problem and partly a real one. Each tool addresses a different slice of the same broad question — how do we secure cloud-resident assets — and the overlap is genuine.
The simplest mental model: CSPM checks how you built the cloud, SSPM checks how you configured the SaaS tenants running on top of it, CASB controls what flows in and out, DSPM tracks what data lives where, and ITDR watches who’s doing what with identities. SSPM is preventive and configuration-centric. ITDR is detective and behavior-centric. The Snowflake breach — credential abuse against weakly configured tenants — sits in the seam between them, which is why most serious vendors have spent the past two years stitching the categories together.
That convergence is real. CrowdStrike acquired Adaptive Shield in 2024 and rebranded it Falcon Shield. Palo Alto’s Prisma Cloud bundles CSPM, SSPM, and CASB. Wiz, traditionally a CSPM, added SSPM capabilities in late 2025. Standalone leaders — AppOmni, Obsidian Security, Valence Security, DoControl, Wing Security, Grip Security, Spin.AI, Axonius — increasingly compete on adjacencies (ITDR coverage, NHI governance, shadow AI discovery) rather than core configuration scanning, which has commoditized.
How an SSPM Rollout Actually Works
Onboarding follows a predictable pattern. The team picks an initial set of tenants — almost always Microsoft 365 or Google Workspace first, then Salesforce, Slack, and whatever else holds regulated data. For each, an admin grants the SSPM tool API access via OAuth or a service account with the read scopes the vendor requires. The Centers for Medicare & Medicaid Services, which uses AppOmni internally, reports onboarding takes one to two weeks per app. That tracks with most enterprise deployments — the time goes into scope review, change-management approval, and tuning out the initial flood of findings.
After connection, the tool scans and produces a baseline. For a tenant that’s never had posture review, the first scan typically returns hundreds of findings. Most are noise or low-risk. The work in the first few weeks is triage: marking accepted risks, suppressing duplicate rules, mapping findings to owners. Mature deployments end up with maybe 5–15% of initial findings flagged as genuinely actionable.
Then comes the steady state — which is the actual product. Drift detection runs continuously. When someone disables MFA enforcement, grants a new admin role, or installs a marketplace app with broad scopes, the SSPM should catch it within hours and route an alert. Many vendors integrate natively with SIEM and SOAR platforms so a posture change becomes a SOC ticket or triggers an automated response — revoking an OAuth grant, rotating a token, opening a Jira ticket to the app owner.
Coverage depth varies sharply by app. The big four — Microsoft 365, Google Workspace, Salesforce, Slack — get hundreds of rules per vendor. ServiceNow, Workday, Atlassian, GitHub, Zoom, Box, Okta typically get strong coverage. Long-tail apps — niche industry tools, internal SaaS — often have a handful of generic checks or none. SaaS apps without robust admin APIs are simply not coverable. CMS’s program documentation explicitly notes that incompatible apps are excluded from their SSPM scope. That gap is permanent for some apps.
What SSPM Does Not Catch
This is where most buyer disappointment originates. SSPM is a configuration tool. It is excellent at finding settings that are wrong against a baseline. It is not designed to do several things buyers expect.
It does not detect active credential abuse in real time. When UNC5537 logged into Snowflake tenants with valid stolen credentials and no MFA was required, every login was, from the platform’s perspective, a normal authenticated session. A pure SSPM would flag the posture problem — MFA optional, dormant accounts active — but would not catch the attack without behavioral telemetry layered on top. That’s the ITDR job. Mature platforms (Obsidian, Valence, Falcon Shield, AppOmni) now bundle ITDR; pure-play SSPM does not.
It does not classify data. SSPM knows a Salesforce object is shared externally. It does not know that the object contains regulated health information. That mapping requires DSPM or in-app DLP. Without it, every external sharing finding looks the same — which leads to alert fatigue and missed real exposures.
It does not prevent the breach in progress. Knowing an OAuth app has dangerous scopes is a posture finding. Catching that app exfiltrating mailbox contents requires behavioral monitoring. The 2024 Microsoft Midnight Blizzard breach involved a legacy OAuth app with full privileges — SSPM would have flagged the over-permissioned app; ITDR or anomaly detection would have flagged the exfiltration.
It cannot cover what it cannot reach. Apps without API access for posture data are invisible. Custom-built internal SaaS, niche regional vendors, and apps without enterprise admin APIs all fall through. Shadow SaaS — apps employees signed up for using corporate email but IT never sanctioned — is partially covered by some SSPMs through email/log analysis (Grip, Wing, Nudge Security focus here), but the discovery layer is a different problem from the posture layer.
It does not solve operational ownership. Findings need an owner. In organizations where SaaS apps are operated by business units rather than IT (Salesforce by RevOps, Workday by HR, GitHub by Engineering), the SSPM creates a long list of misconfigurations whose remediation requires cross-functional negotiation. The tool finds the gap; humans close it.
Buying Considerations That Actually Matter
After dozens of public SaaS breaches in 2024 and 2025 — including the Drift-Salesloft-Salesforce OAuth token compromise that hit hundreds of organizations across August 2025 — most CISOs are not asking whether to buy SSPM. They’re asking what bundle. Several factors materially affect outcomes.
App coverage map vs. actual SaaS estate. Get the vendor’s coverage list and overlay it against your top 30 apps by data sensitivity. Marketing pages often claim “200+ apps.” Posture-rule depth on app #50 is usually a fraction of depth on app #5.
Pricing model. Some vendors charge per integration. Others charge per user or per tenant. Per-integration pricing creates exactly the wrong incentive — teams skip apps to control cost and end up with the precise blind spots SSPM is meant to eliminate. Falcon Shield (CrowdStrike), among others, has positioned its unmetered-app model against this.
API rate-limit handling. Microsoft Graph and Salesforce APIs have hard caps. Vendors handle this with delta scanning, where only changes since the last scan are pulled. Ask how often a full vs. delta scan runs and what happens when rate limits hit.
Remediation depth. “Guided” remediation (here’s the change, click through to the admin console) is meaningfully different from “automated” remediation (the tool flips the setting via API). Automated remediation requires write scopes most security teams gate carefully.
Integration with your detection stack. If you have a SIEM (Splunk, Sentinel, Chronicle) and a SOAR, the SSPM’s value goes up significantly when posture findings flow into existing playbooks rather than living in a separate console.
Adjacent capabilities. Decide whether you want a pure-play SSPM and pair it with separate ITDR/DSPM tools, or a converged platform. Early 2026 buyer surveys split roughly evenly — about half prefer integrated platforms, half best-of-breed. There is no defensibly correct answer; it depends on team size, existing tools, and procurement appetite.
FAQ
Is SSPM the same as CSPM? No. CSPM monitors cloud infrastructure (AWS, Azure, GCP) — accounts, IAM, networks, storage. SSPM monitors SaaS application tenants — Microsoft 365, Salesforce, Slack settings and identities. Some platforms now do both, but the underlying problems differ.
Does SSPM replace CASB? No, they overlap but solve different problems. CASB enforces policy on traffic between users and SaaS in real time. SSPM monitors configuration state inside SaaS tenants. Many enterprise platforms include both, but neither makes the other obsolete.
Can SSPM cover apps with no admin API? Generally no. Posture data has to come from somewhere; no API means no read access to settings. Some vendors compensate with browser-extension telemetry or log analysis, but coverage is shallow compared to API-connected apps.
Will SSPM stop a Snowflake-style breach? It can prevent the conditions — flag MFA-optional tenants, dormant accounts, missing IP restrictions. Stopping the active credential-stuffing attempt requires ITDR. Many SSPM vendors now bundle both.
The Honest Verdict
SSPM is genuinely useful, genuinely necessary for any organization running a meaningful SaaS estate, and genuinely insufficient on its own. The 2024–2025 wave of SaaS breaches did not happen because companies lacked CASBs or firewalls. They happened because hundreds of configuration decisions inside dozens of SaaS tenants drifted, decayed, or were never made well — and nobody was watching. SSPM watches. That alone justifies the spend for most enterprises.
The mistake is treating SSPM as a complete answer. Configuration is one layer. Identity behavior is another. Data exposure is a third. The buyers getting the most from SSPM treat it as the foundation of a SaaS security program — the layer that gets the tenant configured correctly and keeps it that way — and pair it with detection capabilities that catch what configuration alone cannot. Those that treat it as a standalone control will eventually find out, like every Snowflake customer in mid-2024, that an attacker only needs one open door.
