What Is SaaS Security? Risks, SSPM & Best Practices

SaaS security is the practice of protecting an organization’s data, identities, configurations, access permissions, and connected applications within software-as-a-service environments.

It covers how SaaS applications are configured, who and what can access them, how sensitive data is stored and shared, and how integrations such as OAuth apps, APIs, and third-party services introduce risk. Common SaaS environments include Microsoft 365, Google Workspace, Salesforce, Slack, and Snowflake.

SaaS security operates under a shared responsibility model: the provider secures the underlying service and infrastructure, while the customer is responsible for securing its tenant, identities, permissions, data, configurations, and integrations.

Attackers target that customer-side layer because a valid session opens the same doors as a valid employee. CloudSEK researchers documented how infostealer malware abused an undocumented Google OAuth endpoint called MultiLogin to regenerate expired Google session cookies and keep access to accounts even after a password reset. First advertised on Telegram in October 2023, the technique had spread by late December to six infostealer families: Lumma, Rhadamanthys, RisePro, Stealc, Meduza, and WhiteSnake.

‍

SaaS Security and the Shared Responsibility Model

Every SaaS contract splits security duties between the provider and the customer, and attackers have found most of their recent openings on the customer side of that line. Providers run the data centers, patch the application, and keep the service available. Customers decide who can log in, what each account can access, which settings are enabled, and which third-party apps receive tokens.

Security Area	SaaS Provider Secures	Customer Secures
Infrastructure and application code	Data centers, servers, network, operating systems, patching of the SaaS application	Nothing directly; the customer verifies provider assurances such as SOC 2 and ISO 27001 reports
Identity and access (IAM)	Authentication features such as SSO, MFA, and conditional access	MFA enforcement, role assignment, admin rights, and account removal at offboarding
Tenant configuration	Available security settings and their defaults	Choosing, hardening, and monitoring those settings over time
Data	Storage, replication, and platform-level encryption	Classification, sharing permissions, retention, and backup against deletion or ransomware
Integrations	APIs and the OAuth framework for connected apps	Approving, scoping, reviewing, and revoking third-party app access
Devices and sessions	No coverage	Endpoint health and the browsers that store session cookies

A provider breach remains possible, but the recurring failure pattern is a customer tenant with weak MFA coverage, stale accounts, or over-permissioned integrations. SaaS security programs concentrate on those customer-owned rows, because no provider patch fixes them.

What Does SaaS Security Protect?

SaaS security safeguards five interconnected asset groups within each tenant, and if an attacker compromises any one of them, they gain access to the others.

1. Human Identities and Access Rights

Employee, contractor, and guest accounts carry the permissions that determine what data each person can access. Admin roles deserve the closest watch, since a single global administrator in Microsoft 365 or a super admin in Google Workspace controls every other account and setting in the tenant. Guest accounts and former employees who were never removed keep access that nobody reviews.

2. Non-Human Identities, API Keys, and OAuth Integrations

Service accounts, API keys, OAuth tokens, bots, and AI agents multiply with every new integration, and none of them can complete an MFA prompt. A token granted to a connected app keeps working until someone revokes it, independent of the user's password. CloudSEK's BeVigil research found hardcoded SaaS API keys for Mailgun, MailChimp, and SendGrid in about half of 600 analyzed mobile apps, putting more than 54 million app users at risk.

3. Configurations and Security Settings

Each SaaS platform exposes hundreds of settings covering sharing defaults, legacy authentication, external collaboration, mailbox forwarding, and app consent. A single change, such as allowing users to consent to any OAuth app, reshapes the tenant's risk overnight. Configuration drift happens as admins make exceptions and as vendors ship new features with permissive defaults.

4. Business Data and Sharing Links

Business data inside SaaS platforms includes files, CRM records, chat messages, source code, support tickets, and full customer databases. Anyone-with-the-link sharing, public calendars, and external guest access expose that data without any account compromise at all. Data loss prevention and data security posture tools classify sensitive content and flag where it is shared.

5. Activity and Audit Logs

Audit logs record sign-ins, permission changes, file access, and admin actions, and investigations depend on them. Retention varies by license tier: Microsoft's Purview documentation lists 180 days of retention for Audit (Standard) and one year for Audit (Premium), with 10-year retention sold as an add-on. Teams that forward logs to a SIEM keep evidence past those limits.

‍Top SaaS Security Risks and Recent Breaches

SaaS breaches in recent years follow a consistent pattern: attackers log in with stolen or abused access instead of hacking the platform.

Stolen Credentials From Infostealer Logs

Infostealer malware on a personal or unmanaged device captures saved passwords and cookies for every SaaS app the victim uses, and those logs are resold on dark web markets. The 2024 Snowflake campaign showed the scale: Mandiant's UNC5537 investigation found that at least 79.7% of the accounts the attacker used had prior credential exposure, and approximately 165 organizations were notified. The affected customer instances did not require MFA, and some credentials had gone unrotated for as long as four years.

Session Token Theft That Bypasses MFA

A stolen session cookie represents an already-completed login, so replaying it skips the password and the MFA prompt entirely. Attackers collect these tokens through infostealers and through adversary-in-the-middle phishing kits that proxy the real login page. Short session lifetimes, device-bound tokens, and revoking all sessions after an incident cut the value of a stolen cookie.

OAuth Token and Integration Abuse

Connected apps hold standing OAuth tokens into core platforms, so compromising one integration vendor exposes every customer that installed it. Between August 8 and at least August 18, 2025, the actor tracked as UNC6395 used compromised OAuth tokens for the Salesloft Drift app to pull data from Salesforce customer instances and search it for AWS keys, passwords, and Snowflake tokens, according to Google Threat Intelligence Group. This SaaS-to-SaaS path is a form of third-party data breach that no password reset touches.

Misconfiguration and Oversharing

Public sharing links, open guest access, disabled MFA for legacy protocols, and permissive app-consent settings expose data with no attacker effort at all. Misconfigurations persist because SaaS admin consoles spread these settings across many pages and each vendor names them differently.

Excessive Privileges and Orphaned Accounts

Users collect roles as they change teams, and admin rights granted for a one-time task stay in place for years. Accounts left active after offboarding, especially ones created outside SSO, give former staff and attackers a quiet way back in, a common route to account takeover.

Shadow SaaS and Shadow AI

Employees sign up for SaaS tools and AI assistants with a corporate email and upload company data without security review. These unsanctioned apps sit outside SSO, MFA policy, and logging. Shadow AI adds a newer twist, since AI features and copilots inside approved SaaS apps read whatever data the signed-in user can already reach.

How SaaS Security Tools Work: SSPM, CASB, SSE, and ITDR

SaaS security tools differ mainly in where they watch the path between the user and the data: the tenant configuration, the network route, or the identity layer.

SaaS Security Posture Management (SSPM)

SSPM tools connect to each SaaS platform through its admin APIs, read the tenant's configuration, users, and connected apps, and compare them against security baselines. Findings include disabled MFA, risky sharing defaults, over-permissioned OAuth grants, and inactive admins, with guided or automated fixes. SSPM needs no traffic inspection and no endpoint agent.

Cloud Access Security Broker (CASB)

A cloud access security broker sits between users and cloud services, either inline as a proxy or through API connections. Inline CASB discovers shadow SaaS from traffic, blocks risky uploads, and enforces data loss prevention in real time. API-mode CASB overlaps with SSPM for data scanning but focuses less on configuration posture.

Security Service Edge (SSE)

SSE platforms bundle CASB with a secure web gateway and zero trust network access, delivered from the cloud. SSE governs how users reach SaaS apps from any device or location, while SSPM governs how the apps themselves are configured.

Identity Threat Detection and Response (ITDR)

ITDR tools analyze identity provider and SaaS sign-in logs for identity threats such as impossible travel, token replay, MFA fatigue, and suspicious privilege grants. ITDR responds by revoking sessions, forcing reauthentication, or disabling accounts.

Mature programs combine these categories: SSPM hardens the tenant, CASB or SSE controls access paths, and ITDR catches account misuse that configuration alone cannot prevent.

Layers of SaaS Security

SaaS Security is best understood as a layered model, where each layer addresses a specific category of risk inherent to SaaS platforms. These layers work together to provide defense-in-depth across identity, data, and application behavior.

Here is the breakdown of Saas Security Layers:

Identity layer
This layer governs authentication, authorization, and privilege management. It controls user roles, admin access, service accounts, and session behavior to prevent account takeover and privilege abuse.
Data layer
The data layer focuses on visibility and protection of sensitive information stored in SaaS applications. It manages sharing settings, external access, and exposure paths that can lead to accidental or malicious data leakage.
Configuration layer
This layer ensures SaaS applications remain securely configured over time. It detects insecure defaults, misconfigurations, and configuration drift that can silently weaken security posture.
Integration layer
The integration layer monitors OAuth apps, APIs, and third-party connections. It limits excessive permissions and identifies risky or malicious integrations that may introduce persistent access to SaaS data.
Activity layer
This layer analyzes user and administrative behavior across SaaS platforms. Abnormal access patterns, unusual data usage, and unexpected configuration changes signal potential compromise or misuse.
Governance layer
The governance layer ties security controls to compliance and accountability. It provides audit logs, reporting, and policy enforcement to support regulatory requirements and internal risk management.

SaaS Security vs Cloud Security: What Is the Difference?

SaaS security covers applications a vendor runs, and the customer only configures, while cloud security in the IaaS and PaaS sense covers infrastructure the customer builds and operates, such as virtual machines, containers, storage buckets, and cloud IAM roles.

The tooling follows that same split between applications and infrastructure. Cloud security posture management (CSPM) and cloud workload protection scan AWS, Azure, and Google Cloud resources for exposed storage, open ports, and vulnerable workloads. SaaS security tools never touch servers or code; they work through vendor APIs on identities, settings, data sharing, and integrations. Both disciplines share identity as the primary attack surface, which is why identity provider hardening appears in both programs.

SaaS Security Best Practices

Effective SaaS security programs apply the following controls in order, starting with visibility and ending with continuous monitoring:

Inventory every SaaS app: Combine SSO logs, OAuth consent grants, browser extension data, and expense reports to find sanctioned and shadow apps, then assign an owner to each one.
Enforce phishing-resistant MFA: Require FIDO2 security keys or passkeys for admins at minimum, and block legacy authentication protocols that skip MFA entirely.
Shorten and control sessions: Set session lifetimes by risk, require reauthentication for sensitive actions, and revoke all active sessions whenever a password is reset or a device is reported compromised.
Apply least privilege to admins: Keep global admin roles to a small named group, use role-based admin rights for daily work, and review privileged accounts every quarter.
Restrict and review OAuth apps: Turn off user consent for unverified apps, require admin approval for high-scope permissions, and revoke tokens for integrations nobody uses.
Manage non-human identities: Store API keys in a secrets vault, rotate them on a schedule, and scope each key to the minimum API permissions its job requires.
Harden configurations against a baseline: CISA's Binding Operational Directive 25-01, issued in December 2024, requires federal agencies to adopt its Secure Cloud Business Applications (SCuBA) baselines, starting with Microsoft 365, and because ScubaGear is free and open source, private-sector teams run the same benchmark on their own tenants.
Limit external sharing: Default sharing to internal-only, expire external links automatically, and require approval for new guest domains.
Centralize and retain logs: Forward SaaS audit logs to a SIEM, keep them beyond the default license retention, and alert on admin role changes, mass downloads, and new OAuth grants.
Automate offboarding: Provision and deprovision through SCIM from the identity provider so access ends the same day employment does.
Assess SaaS vendors continuously: Fold SaaS providers and their integrations into third-party risk management, with a review of each vendor's breach notifications and certifications.
Govern AI features inside SaaS: Review which data copilots and AI agents reach, and apply sensitivity labels before enabling them tenant-wide.

These controls map directly onto zero trust security, which treats every session, device, and integration as untrusted until verified.

SaaS Security Beyond the Tenant: Monitoring Leaked Credentials

SSPM, CASB, and ITDR all watch activity inside or at the edge of the tenant, yet the Snowflake and MultiLogin cases began somewhere none of them look: on an infected laptop and in a dark web log listing. By the time a stolen credential appears in SaaS sign-in logs, the attacker is already logged in.

ClouSEK XVigil closes that gap by monitoring deep and dark web forums, leaked-data marketplaces, paste sites, and encrypted channels for credentials and code tied to a specific organization. Security teams receive early warning on leaked employee credentials and exposed repositories, prioritized by exploitability, so they reset passwords and revoke sessions while the exposure is still an initial access vector and not an active intrusion.

SaaS Security FAQs

Is SSPM the same as CSPM?

No. SSPM checks the configuration of SaaS applications such as Microsoft 365 and Salesforce, while CSPM checks infrastructure resources in AWS, Azure, and Google Cloud.

Is SaaS more secure than on-premises software?

It depends on the customer's configuration. Providers patch faster than most in-house teams, but misconfigured SaaS tenants expose data to the internet more easily than internal servers.

Does SaaS security require an agent on every device?

No. SSPM and API-based CASB connect directly to SaaS platforms through APIs. Only inline CASB and SSE use endpoint agents or traffic routing.

Do organizations need to back up SaaS data?

Yes. SaaS providers protect against their own failures, not against user deletion, malicious admins, or ransomware syncing encrypted files. Retention and recycle bins expire after fixed periods.

Which compliance frameworks cover SaaS security?

SOC 2, ISO/IEC 27001, ISO/IEC 27017, CSA STAR, and FedRAMP assess SaaS providers. Customers map their own tenant controls to frameworks such as NIST CSF and CIS Benchmarks.

Can SaaS vendors access customer data?

Yes, in limited cases. Vendor support staff can access customer data under contract terms, and features such as Microsoft Customer Lockbox require customer approval before that access happens.

How often should SaaS configurations be reviewed?

SaaS configurations need continuous automated checks, plus a manual review after every major vendor feature release and at least once per quarter.

Can small businesses secure SaaS without dedicated tools?

Yes. Built-in controls such as Microsoft Secure Score, Google Workspace security recommendations, and CIS Benchmarks cover MFA, sharing, and admin hardening without an SSPM license.

Is SaaS security only a concern for large enterprises?

No. Small businesses run email, finance, and customer data in SaaS apps, and attackers use the same stolen-credential methods against them as against enterprises.