Most cloud security conversations default to infrastructure — accounts, virtual machines, storage buckets, IAM roles. But for a typical organization, a larger and less-defended slice of its actual attack surface is software-as-a-service: email, CRM, HR systems, file storage, chat, dozens of specialized tools an average employee touches without IT ever provisioning a server. Securing SaaS is a genuinely different discipline from securing infrastructure you own, because the thing you’re securing is a vendor’s application, running on a vendor’s infrastructure, configured through a vendor’s admin console. You do not patch it, you do not control its code, and often you don’t even know it’s in use.
What does the shared responsibility model mean for SaaS specifically?
Every major cloud model — IaaS, PaaS, SaaS — divides security obligations between provider and customer, but the line moves sharply with each. In IaaS, the customer manages nearly everything above the physical hardware: the OS, patching, network configuration, application code. In SaaS, the provider owns the application, the underlying infrastructure, the platform’s own patching and vulnerability management — nearly the entire technical stack is theirs.
What remains with the customer in a SaaS model is narrower but is exactly where most real-world incidents originate: identity and access management (who can log in, with what privileges), data governance (what gets stored in the SaaS platform and how it’s classified), configuration (the security settings the provider exposes but does not enforce by default), and usage policy (what employees are permitted to connect, share, and integrate). A SaaS breach is rarely “the vendor got hacked” — it is far more often a compromised employee credential, an over-permissioned sharing setting, or a malicious third-party integration granted access through the customer’s own configuration choices. Misunderstanding this division — assuming the vendor “handles security” because it’s SaaS — is the single most common root cause of SaaS-related incidents.
What is SSPM and why did it become necessary?
SaaS Security Posture Management exists because the configuration surface described above is large, changes constantly, and is spread across dozens of independent admin consoles that don’t talk to each other. An SSPM tool connects to an organization’s SaaS applications via API and continuously evaluates their configuration against security best practices and compliance benchmarks — flagging things like external sharing enabled by default on a file-storage platform, MFA not enforced for all users, an admin account without appropriate monitoring, or a departed employee’s account that was never deprovisioned.
The parallel to infrastructure security is direct and useful: SSPM is functionally the SaaS-layer equivalent of Cloud Security Posture Management for infrastructure — both are continuous configuration-auditing disciplines built on the same underlying insight, that a modern environment has too many settings across too many systems for manual review to keep pace, and that most real incidents trace back to a misconfiguration rather than a zero-day. Where CSPM watches cloud infrastructure accounts, SSPM watches the constellation of SaaS applications an organization actually uses, which for many mid-size organizations now numbers in the hundreds.
What makes OAuth token grants a distinct risk?
A risk specific to the SaaS ecosystem, without a clean infrastructure-security analogue, is the proliferation of third-party OAuth integrations. Modern SaaS platforms expose OAuth as the standard mechanism for connecting other applications — a scheduling tool that reads your calendar, a productivity add-on that accesses your email, an analytics tool that reads your CRM data. Each grant an employee approves creates a standing, often long-lived credential relationship between two systems, frequently with a broader scope of access than the integration actually needs, and frequently invisible to central IT because the grant happens through a user-facing “Allow access” click rather than a provisioned account.
The risk surfaces in two ways. First, a legitimate but poorly secured third-party app can itself be compromised, and an attacker who breaches that vendor inherits every OAuth token it was granted across every customer that connected it — a supply-chain risk analogous to the SBOM problem in application security, just expressed through access grants rather than code dependencies. Second, attackers have directly weaponized OAuth consent flows themselves: a phishing-style attack that tricks a user into approving a malicious app’s OAuth request grants the attacker a durable API-level foothold that survives a subsequent password reset, because the token isn’t tied to the password at all. CISA has published guidance specifically on OAuth application abuse and consent phishing as a distinct attack pattern security teams should monitor for, separate from traditional credential theft.
How big a problem is shadow SaaS?
Shadow SaaS — SaaS applications adopted and used without IT’s knowledge or approval — is the SaaS-era version of shadow IT, and arguably worse, because the barrier to adoption is lower than it has ever been: no server to provision, no software to install, often no cost to trigger a procurement review, just a sign-up form and a credit card or a free tier. An employee frustrated with an approved tool’s limitations can be running an unsanctioned alternative within minutes, frequently storing legitimate business data in it.
The risk is not that employees are malicious; it’s that unsanctioned SaaS sits entirely outside the organization’s SSPM coverage, access reviews, and offboarding process. Data can land in a platform nobody in security knows exists, under an account that never gets included when a departing employee’s access is revoked, governed by whatever default security settings that particular vendor happens to ship with. Discovering shadow SaaS generally requires purpose-built discovery tooling — inspecting network and identity-provider logs for SaaS sign-in patterns, or SSPM/CASB platforms with a discovery capability — because it is, by definition, invisible to any inventory that depends on IT having provisioned it.
What does a practical SaaS security baseline look like?
A workable baseline starts with identity: enforce single sign-on and MFA for every SaaS application that supports it, and treat any application that can’t be brought under the organization’s identity provider as a higher-risk exception requiring compensating controls. From there, review and restrict default sharing and external-access settings on every platform — the single most common source of accidental data exposure in SaaS is a permissive default that was never tightened. Establish a review process for OAuth grants, ideally with automated alerting on new high-scope authorizations rather than relying on users to self-report what they’ve connected. Run SSPM (or an equivalent continuous configuration review) rather than a one-time audit, since SaaS configurations drift constantly as vendors change defaults and employees adjust settings. And build SaaS discovery into the security program explicitly, rather than assuming the applications in use match the applications IT has approved.
None of this is exotic; it is largely the same discipline organizations already apply to infrastructure — least privilege, continuous configuration review, visibility into what’s actually running — applied to a layer that is easier to overlook precisely because provisioning a SaaS account feels administrative rather than technical.
Frequently Asked Questions
Isn’t SaaS security the vendor’s responsibility?
Only partially. SaaS vendors are responsible for the application’s code, infrastructure, and platform-level patching, but customers remain responsible for identity and access management, data governance, configuration choices the provider exposes, and usage policy. Most SaaS incidents trace back to a compromised credential or a misconfigured setting on the customer side, not a vendor-side breach.
What is SSPM?
SaaS Security Posture Management is a category of tooling that connects to an organization’s SaaS applications via API and continuously evaluates their configuration against security best practices — flagging risks like disabled MFA, permissive external sharing defaults, or stale accounts. It plays the same continuous-configuration-auditing role for SaaS applications that CSPM plays for cloud infrastructure.
Why are OAuth grants risky if the user approved them?
An OAuth grant creates a standing, often long-lived credential relationship that survives a password reset and frequently carries broader access than the integration needs. Attackers exploit this two ways: compromising a legitimate but poorly secured third-party app to inherit its granted tokens, or tricking users into approving a malicious app’s OAuth request directly through consent phishing.
What is shadow SaaS?
Shadow SaaS refers to SaaS applications adopted and used without IT’s knowledge or approval — enabled by how easy modern SaaS sign-up has become, often requiring no procurement review at all. It’s a significant risk because unsanctioned applications sit outside SSPM coverage, access reviews, and offboarding processes, meaning departing employees’ access to them is rarely revoked.
What’s the single highest-impact SaaS security control to start with?
Enforcing single sign-on and multi-factor authentication across every SaaS application that supports it. Since most SaaS incidents originate from compromised credentials rather than vendor-side breaches, consolidating authentication through an identity provider with MFA closes the most commonly exploited path before addressing configuration review, OAuth governance, or shadow SaaS discovery.