Continue your mission
Continuous monitoring and remediation of SaaS application security configurations. SSPM tracks misconfiguration drift across the modern SaaS stack (Salesforce, Microsoft 365, Slack, GitHub, Workday), identifies over-privileged users, and governs third-party OAuth integrations across hundreds of connected applications.
SaaS Security Posture Management (SSPM) is a security product category focused on continuously monitoring the configuration security of Software-as-a-Service applications. It addresses a problem that did not exist at scale a decade ago and now sits at the center of most enterprise security risk: organizations run dozens to hundreds of SaaS applications, each with complex, unique security settings that drift from their secure baseline over time, often without anyone noticing.
The scope of the problem is straightforward to state. The average enterprise in 2024 uses more than 130 SaaS applications. Each application, from Salesforce and Microsoft 365 to Slack, GitHub, Workday, ServiceNow, and Zoom, has its own administrative console, its own security settings taxonomy, its own user and permission model, and its own concept of what a "secure" configuration looks like. No single administrator has expertise across all of them. No native application dashboard provides a cross-application security view. And the applications themselves are updated continuously by their vendors, sometimes introducing new settings or changing existing defaults in ways that create security gaps.
SSPM is the discipline and tooling that closes this visibility gap. It connects to each SaaS application via APIs, reads the current configuration state, compares it against a security baseline (which may be the vendor's hardening guide, a CIS benchmark, or an organization's custom policy), identifies deviations, and provides workflows to remediate them.
The distinction from related categories is worth stating precisely. CASB (Cloud Access Security Broker) controls the traffic to and from SaaS applications, providing data loss prevention, access control, and activity monitoring at the network or API level. SSPM goes deeper than CASB into the application's own configuration layer: who has admin privileges in Salesforce, is Slack's external sharing enabled, is GitHub's branch protection enforced on the main branch, are Microsoft 365's legacy authentication protocols disabled. These are settings that CASB does not evaluate and that only SSPM sees.
---
SSPM platforms connect to SaaS applications using each application's administrative API. For Microsoft 365, this means the Microsoft Graph API. For Salesforce, the Metadata API and REST API. For GitHub, the GitHub REST API and GraphQL API. For Slack, the Slack Admin API. For Workday, the Workday Web Services API.
The connection is read-heavy: SSPM reads current configuration state, reads user lists and permission assignments, reads OAuth application grants, and reads audit logs where available. Write access (for automated remediation) is optional and more sensitive; many organizations run SSPM in read-only mode and use the findings to drive human-guided remediation workflows.
After connecting, the platform runs a configuration assessment. This is not a point-in-time scan in the traditional vulnerability management sense; it is continuous. SSPM platforms poll APIs on schedules ranging from real-time event-driven updates (when the SaaS app provides webhook notifications of configuration changes) to hourly or daily polling cycles for applications with more limited API capabilities.
SSPM platforms ship with pre-built security benchmarks for major SaaS applications. These benchmarks map settings to security outcomes: if external email forwarding is enabled in Microsoft 365, that is a data exfiltration risk. If MFA is not enforced for all Salesforce users, that is a credential theft risk. If GitHub repositories allow any team member to approve their own pull requests, that is a code integrity risk.
Benchmark sources vary by application. CIS has published benchmarks for Microsoft 365 and Salesforce. Vendors like AppOmni and Adaptive Shield have developed their own benchmarks, often informed by real-world breach analysis. Regulatory frameworks like HIPAA, SOC 2, and ISO 27001 have specific requirements that SSPM platforms map to configuration settings: HIPAA's access controls requirement maps to specific Salesforce sharing settings, for example.
Custom policies allow organizations to add rules beyond the shipped benchmarks. A financial services firm might require that all Slack channels in the finance workspace have external sharing disabled. A healthcare organization might require that Workday HR records are accessible only from company-managed devices. SSPM platforms provide policy editors that let security teams encode these organization-specific requirements and monitor compliance against them continuously.
SaaS applications are plagued by privilege creep: users are granted admin access for a temporary project and the access is never revoked, service accounts accumulate permissions over time as integrations are added, and contractors retain access after their engagement ends. SSPM provides a continuous view of who has what level of access in each SaaS application, with specific attention to privileged accounts.
Key signals SSPM tracks in the user and permission layer include: users with global admin or equivalent privileges who have not logged in recently (dormant admins are high-value targets for account takeover), users who have MFA disabled (a persistent finding in most Microsoft 365 tenants), service accounts with more permissions than their documented purpose requires, and users whose access has not been reviewed within a defined review cycle.
Some SSPM platforms integrate with identity governance tools (SailPoint, Saviynt) to feed SaaS permission data into the organization's broader access certification workflow. This means that the quarterly access review in the IGA platform includes SaaS application permissions alongside Active Directory group memberships.
This is the SSPM capability that most frequently surprises security teams when they see it for the first time. Modern SaaS applications allow users to connect third-party applications via OAuth grants. In Microsoft 365, a user can grant a third-party app access to read their email, write calendar events, or access OneDrive files with a few clicks, without requiring IT approval. In Slack, users can install apps that read all messages in channels they are members of. In Salesforce, connected apps can be granted access to CRM data by any user with sufficient privileges.
The scale of this problem is underappreciated. A typical Microsoft 365 tenant of 500 users has between 200 and 2,000 distinct third-party OAuth applications connected, many of them personal productivity tools installed by individual users. Each OAuth grant is a potential data exfiltration path if the connected application is compromised, abandoned (no longer maintained but still active), or malicious.
SSPM platforms inventory all OAuth grants across connected SaaS applications, categorize them by scope (read-only vs. read-write vs. admin), by verification status (published in the application vendor's marketplace vs. unverified), and by last-use date (applications granted access that have not been used in 90+ days are candidates for revocation). They also flag applications requesting excessive permissions relative to their stated function: a note-taking app that requests access to read all email is a red flag regardless of vendor claims.
This OAuth governance function is one area where SSPM provides value that neither CASB nor native application controls deliver. CASB does not see OAuth grants at the configuration level. Native application admin consoles show OAuth grants but do not provide cross-application correlation or automated risk scoring.
The continuous monitoring capability means SSPM is primarily a drift detection system. The baseline is established (or imported from benchmark results) and the platform watches for any change that moves a setting away from the secure state.
Drift events are common and often unintentional. An administrator changes a SharePoint external sharing setting to allow a partner collaboration project and forgets to revert it. A developer disables GitHub branch protection on a repository to push a hotfix and does not re-enable it. A Slack workspace administrator grants guest access to an external user without configuring the appropriate channel restrictions.
SSPM alert workflows integrate with SIEM platforms (Splunk, Sentinel, Chronicle), ticketing systems (ServiceNow, Jira), and communication tools (Slack, Teams) to route drift alerts to the appropriate owner. Policy-based routing is important here: a drift alert in the finance team's Salesforce org should go to the finance security contact, not to the general security team queue.
---
SaaS misconfigurations have driven some of the most damaging breaches of the past five years. The 2023 Storm-0558 campaign (attributed to Chinese threat actors) compromised Microsoft Exchange Online mailboxes of US government officials through a combination of a stolen signing key and excessive OAuth application permissions. The 2022 Twilio breach began with phishing and resulted in attackers accessing Twilio's Authy-connected customer accounts because of configuration weaknesses in how Twilio's Salesforce and internal SaaS tools were segmented. In both cases, native application controls were insufficient to prevent the compromise; external posture management would have surfaced the configuration gaps beforehand.
The business case for SSPM maps to three organizational realities. First, SaaS procurement is decentralized. Shadow IT is not a failure of policy; it is a structural feature of modern organizations where business units buy and deploy SaaS tools faster than IT can evaluate them. SSPM does not require centralized SaaS procurement to be effective; it discovers connected applications through API enumeration and OAuth grant analysis, regardless of how they were acquired.
Second, SaaS security responsibility is ambiguous. SaaS vendors operate on the shared responsibility model: they secure the infrastructure and the application platform; customers are responsible for configuration security and access control. Most SaaS administrators are not security professionals. They are business users who have been granted admin access because they needed to onboard new users or configure an integration. SSPM provides the security team with visibility into those administrators' configuration decisions without requiring those administrators to become security experts.
Third, compliance requirements explicitly address SaaS configuration. SOC 2 Type II audits evaluate whether access to production systems (including SaaS production tools) is appropriately controlled and reviewed. ISO 27001 requires that access privileges are reviewed regularly. HIPAA requires audit controls for systems containing protected health information, which increasingly includes SaaS HR, communication, and collaboration tools. SSPM provides continuous evidence of compliance posture rather than requiring point-in-time evidence collection before each audit.
---
API Coverage Depth: SSPM platforms differ significantly in how deeply they integrate with each SaaS application. Coverage for Tier 1 applications (Microsoft 365, Salesforce, Google Workspace, Slack) is typically comprehensive, with hundreds of individual settings evaluated. Coverage for Tier 2 applications (Zoom, Box, Dropbox, ServiceNow, Workday) is moderate. Coverage for long-tail SaaS applications may be limited or absent. Organizations should evaluate SSPM platforms based on their specific SaaS stack, not on the vendor's application count claim.
SSPM vs. CASB Positioning: The two categories are complementary. CASB provides traffic-layer visibility (what data is being sent to which SaaS applications, from which devices, by which users). SSPM provides configuration-layer visibility (how is each SaaS application configured, who has what level of access, what third-party integrations are connected). Organizations with mature security programs run both. If forced to choose one first, organizations with decentralized SaaS procurement and high sensitive data classification in SaaS tools should prioritize SSPM; organizations with high data exfiltration risk at the network layer should prioritize CASB.
Vendor Landscape (2026): AppOmni is the category leader for enterprise deployments, with the deepest integration for Salesforce specifically. Adaptive Shield provides strong coverage across the broadest range of SaaS applications. Valence Security focuses on SaaS-to-SaaS integration governance (the third-party OAuth problem). Obsidian Security provides behavioral analytics layered on top of SSPM-style configuration monitoring. Microsoft Secure Score provides limited SSPM-like functionality natively for Microsoft 365 tenants but does not extend to non-Microsoft SaaS applications.
Remediation Models: SSPM platforms generally offer three remediation modes. Manual remediation provides a finding with step-by-step instructions for the administrator to remediate in the native application console. Guided remediation provides a one-click link that takes the administrator directly to the relevant setting in the application console. Automated remediation makes the configuration change via API without administrator involvement. Automated remediation is powerful but carries risk (an automated change to a Salesforce sharing rule could break a business process). Most organizations implement automated remediation only for the highest-severity findings with the lowest operational risk.
---
SSPM is a Security Posture and Hygiene (SPH) domain control. The SPH methodology is Autonomous Posture Command (APC): "Your posture adapts. Your hygiene never sleeps."
The SaaS stack is terrain. Just as a physical terrain has high ground worth defending and low ground that is vulnerable, the SaaS stack has high-value targets (the Salesforce CRM with all customer data, the Microsoft 365 tenant with all email and files) and low-value assets. APC applied to the SaaS stack means: assess continuously, not periodically; remediate automatically where safe, guided where not; and maintain an always-current picture of posture state across all connected SaaS applications.
The APC methodology explicitly rejects the audit-cycle model of posture management: assess at the start of the quarter, remediate before the audit, drift between audits, repeat. SSPM operationalizes APC for the SaaS layer by converting the posture question from a periodic measurement to a continuous state. The security team does not ask "what is our Microsoft 365 posture?" before an audit; they have a live answer at any moment, with full drift history.
CDA's differentiated framing for SSPM is the concept of posture ownership. In most organizations, SSPM findings are security team findings, routed to a security queue, remediated by the security team after coordinating with the SaaS application owner. This is slow and creates adversarial dynamics between security and business teams. The APC model pushes posture ownership to the application owner: the Salesforce administrator is responsible for Salesforce posture, the Microsoft 365 administrator is responsible for M365 posture, and the security team's role is to set the policy, measure against it continuously, and escalate when remediation SLAs are missed.
This is consistent with the broader CDA posture philosophy: security is not a separate department's job. Security hygiene in the SPH domain is maintained by the people closest to the systems, with the security team providing the standards, measurement, and escalation authority. SSPM tooling is the mechanism that makes this model operationally viable by translating complex per-application configuration requirements into a normalized, accessible posture dashboard that non-security administrators can understand and act on.
The OAuth governance function deserves specific PDM attention because it spans domains. OAuth grants are an IAT (Identity Access and Trust) concern when they involve third-party access to identity-linked resources. They are a DPS (Data Protection and Sovereignty) concern when they grant access to sensitive data. They are an SPH concern when they represent configuration drift from a defined policy. The ZPA (Zero Possession Architecture) methodology in the IAT domain is the governing principle: no third-party application should possess persistent access to CDA-tier data without explicit, reviewed, time-limited authorization. SSPM is the control that enforces and monitors that principle at the SaaS configuration layer.
---
---
---
CDA Theater missions that address topics covered in this article.
Written by Evan Morgan
Found an issue? Help improve this article.